
Carmack on not being a power editor user - tosh
https://twitter.com/id_aa_carmack/status/1302651878065475584
======
Barrin92
I think arguments about productivity miss the point and Carmack is actually
right that typing speed isn't the bottleneck.

I think the reason programmers love to tinker with their vim or emacs configs
is because it's simply satisfying. Just like a blacksmith has their very own
set of valued tools, there's something extremely rewarding about configuring
your setup just the way you want it. You work your entire life with it, so you
might just as well make it your own, I think that's what people get out of it,
just a subjective sense of making things fit right.

It's like my barber who has some cool vintage scissors he got from someone.
Could he cut my hair with some high grade scissors he bought on the internet?
Sure, but he likes his ones better. At the end of the day programming is more
like a craft than a science and it shows when it comes to topics like this.

~~~
Reelin
For me at least it's more than "simply satisfying". It gets the UI _out of the
way_. It's removing a number of mild distractions and nuisances that are
otherwise there _all the time_.

It's not about typing speed at all (for me). It's about having a clean and
orderly working environment where the number of frustrations have been
minimized.

~~~
blub
On the other hand it's typically quite easy to customize the UI of IDEs and
hide menus and such to the point that it's possible to tune out whatever is
left.

Therefore I'm tempted to look at this problem not from a technical but rather
from a social perspective: I consider this preoccupation with editors as a
kind of fixation and way of exercising power in a straightforward way as a
part of an increasingly complex and unfriendly environment. We can't customize
the stupid Scrum processes guiding our lives, can't customize the management
which often is rather clueless about what we're doing, can't avoid that most
software projects are ultimately pointless even if they claim they're changing
the world and empowering users. But we can certainly customize our editors.

And then there's the social pressure from the typical hacker circles which
would happily dictate what programming languages, tools and paradigms are good
and which are bad. Of course this scaffolding all comes crashing down when one
looks at the results and there's no discernible difference between the quality
or success of projects where various editors or processes or languages are
used. So the focus moves to personal benefits, personal preferences and
programming as craft and so on.

But it's all just a game programmers play, isn't it?

~~~
Reelin
> customize the UI of IDEs and hide menus and such

That's not even half of it. TUI programs are designed to be keyboard driven
from the start, not as an afterthought. All the IDEs I'm aware of are
hopelessly outclassed here. There's also things like registers, column
editing, and the buffer abstraction which make common tasks less cumbersome.
The list continues.

It's not that one tool can be used for a task that the other can't; rather
it's just _better_ at it from my perspective (given my particular workflow and
toolchain). For me, there's a significant ergonomic difference which makes for
a more pleasant process overall.

Is keeping a clean and orderly workspace "just a game"? What about using the
best (from your perspective) tool for the job? I imagine different people will
care about these things to different degrees.

As you point out, perhaps for some there's primarily another motive (exercise
control, irritate a coworker, maintain an appearance, ...). That's not
mutually exclusive though and it's hardly unique to programming.

------
robenkleene
Responding to one of Carmack's follow-up tweets
([https://twitter.com/ID_AA_Carmack/status/1302652989610618882](https://twitter.com/ID_AA_Carmack/status/1302652989610618882)):

> Yes, it can be very impressive watching people using the power tools to
> maximum advantage, and sometimes is can be a dramatic win, but I usually
> think that it adds up to... a few minutes saved a day?

I think measuring the gains of text editing features in terms of time is a
distraction. Expressive editing features take something tedious and make it
effortless. It makes it easy to do something that I'd normally put off.

But the reason text editing features end up not being that important is that
if the task is mission critical, you'll end up just soldiering through, even
if it's tedious. Therefore it's an incremental benefit not a revolutionary
one.

I like text editing features because I personally like being organized, not
because I feel like it makes me a more effective programmer. It lets me
indulge myself in keeping code organized without that becoming a time sink.

~~~
majkinetor
Few minutes gain is simply not true. Its IMO closer to an hour. Having ability
to jump asap to any letter on the screen and any file in the project in few
keypresses without browsing trough the tree and son on, is massive speed up.
It doesn't just save time, it saves focus.

~~~
brandonmenc
These are not "power user" features.

Every single IDE and text editor for programmers can do this stuff, and they
are often the only features that 90% of users learn.

~~~
majkinetor
Some of them are, most of them are not - you cant really jump to ANY letter on
screen without vim plugin (AFAIK).

Having quick access to options is paramount - like vscode F1.

Besides, huge majority of IDE users do not use keyboard shortcuts but browser
trough its GUIs, even if the feature exists. Its the IDE mindset (personal
experience).

~~~
brandonmenc
> you cant really jump to ANY letter on screen without vim plugin

There are Ace Jump [0] plugins for most IDEs. imo, easier to use and more
powerful than stock vi navigation commands.

> huge majority of IDE users do not use keyboard shortcuts but browser trough
> its GUIs

Does it count if you "browse the GUI" without ever touching the mouse?

I use the "search everywhere" [1] dialog in JetBrains by pressing double-shift
all the time. When I used emacs, I would M-x tab-complete commands all the
time. Same thing.

Which requires more effort: pressing 4-ish keys to spell out an editor command
you use only a few times a day or trying to memorize every arcane key
combination?

Also, does tabbing in the emacs command buffer count as "browsing the GUI?" I
think so.

I say it all the time, but I think a lot of power vi/emacs users have not
touched a modern IDE in a long time. Everything is keyboard accessible
nowadays, and I would argue vastly more discoverable compared to vi/emacs.

I also think that there is a strange magical thinking-esque hang-up against
any UI that can't be drawn in a terminal.

[0] [https://github.com/acejump/AceJump](https://github.com/acejump/AceJump)

[1] [https://www.jetbrains.com/help/idea/searching-
everywhere.htm...](https://www.jetbrains.com/help/idea/searching-
everywhere.html)

~~~
RandoHolmes
> I say it all the time, but I think a lot of power vi/emacs users have not
> touched a modern IDE in a long time.

Watch as my eyes roll out of my head, onto the floor, and then out the door.

Why is it that you believe the only reason why a vi/emacs user could believe
those environments are faster to edit in is because they don't use IDE's?

The worst part is that most vi/emacs users actually DO have experience in both
environments, whereas most of the people who want to claim vi/emacs isn't any
faster don't. Yet they want to present themselves as an authority.

And I'm one of the people who refuse to use vim emulators in IDE's because
they're never quite right (and never integrate well with the IDE).

~~~
brandonmenc
> Why is it that you believe the only reason why a vi/emacs user could believe
> those environments are faster to edit in is because they don't use IDE's?

Anecdotal, personal experience, including seeing constant outright incorrect
claims about graphical IDEs in threads like these.

The claims usually take the form of: "I use vi/emacs because I can do xyz
using only the keyboard" \- where xyz is something that most IDEs maybe
couldn't do 15+ years ago, but which they all can do today.

~~~
RandoHolmes
I see this a lot from those who prefer IDE's.

It's not generally that people are saying it's impossible to do in an IDE,
just that it's slower to do, and generally more awkward.

Just the other day on reddit I was having this "discussion" with someone, in
which they claimed that because they have "find in files" in their IDE it's
equivalent to vim `grep -iRl whatever`.

In reality I'm going to do what you're trying to do in a fraction of the time.
IDE's have their advantages, but speed is not one of them.

------
JoelMcCracken
So, I agree, somewhat.

I am a long-time Emacs user. Occasionally, editing/macros/etc can save a LOT
of time, and makes it much easier to make some changes which I might not
decide to do.

What I find more important however is the effective window/buffer management.
Being able to manage my screen real-estate is killer; being able to do
everything within one "world" is really valuable. One of the things I find
most valuable is that I run my shell within Emacs. This lets me keep my flow
going instead of switching context and perhaps getting distracted. I can watch
the output of tests etc in one corner of my screen and edit files etc in the
other ones. And because its quick to switch buffers, I can more easily
reference various files for what I am doing.

Basically, the literal time it takes to type is not the big benefit, but that
it allows me to reduce my cognitive overhead of doing everyday, boring things
like resizing windows, looking up symbols/finding definitions etc. This makes
it easier to focus on my task at hand and not get distracted by all of the
mundane tasks I would need to do otherwise.

~~~
dj_mc_merlin
> What I find more important however is the effective window/buffer
> management.

Yes! I cannot imagine how my life looked before `C-x b` (switch buffers in
helm).

However, I still have an actual terminal emulator open the entire time for
serious stuff. Eshell is not compatible with a lot of programs, term/ansiterm
are ok but not quite as good as a dedicated terminal.

I get around having to context switch by using virtual desktops (KDE). I have
Shift-F1 bound to the desktop with only emacs, and Shift-F3 to my terminal.
Works beautifully.

Rather than try to use a terminal in emacs I've found it more useful to use an
solution designed for emacs, i.e git vs magit.

~~~
smabie
Eshell is a really great shell and a lot of full screen nurses apps can be
replaced with an Emacs equivalent. The ability to use elisp in pipes and stuff
is a game changer

~~~
JoelMcCracken
I’ve never been able to make eshell part of my workflow. I wonder if you would
share more info

~~~
smabie
Sure, so basically I keep a small eshell window at the bottom of my current
frame at all times. Full screen commands like man, info, or less will
automatically open a new Emacs buffer. You can seamlessly mix and match shell
constructs and elisp, allowing you to leverage elisp and traditional shell
scripting together. It also makes it really easy to open a file from eshell
since you're already in Emacs. Instead of things like top, I just use Emacs
process viewer.

For full screen apps that absolutely have no Emacs equivalent (quite rare), I
have a term buffer that I occasionally use.

You should check out a list of eshell features, its much more powerful than
even zsh.

Also I use company-mode for command and file completion, which is a lot nicer
than zsh 's completion method, for example. Once you get used eshell, it's
hard to go back.

I think you should be able to use eshell+Emacs for almost everything, and for
me at least, I find the experience quite nice.

------
neilv
Having to use Xcode on MacOS recently reminded me how very much more
productive my custom setup of Linux, Emacs, and Xmonad is.

Just one of reasons is the ease of code navigation, such as bringing some
parts of code into view while keeping other parts visible, or not visible. I
have it rigged up so well in Emacs that it doesn't distract me from my
thinking of the actual problem.

A somewhat relevant story: One time, I was sitting on a park bench in my
neighborhood, with a battered old laptop, doing some heavy semi-mechanical
high-volume editing that didn't require much thinking. I was throwing a lot of
rapid Emacs window management, isearch, ad hoc keyboard macros, etc. at it,
and the task didn't require much second-guessing, which I suppose resulted in
a lot of almost Hollywood-like "programming/hacking" rapidly changing windows
of computer-y text on my screen, extend highlights flashing, syntax coloring
updating, etc. At some point, some of the people who were arriving for a
pickup soccer game in the park gathered round, and were just watching, and
when I got to a stopping point, were kinda cheering and congratulating me (I
think I didn't speak any of their languages), and one gave me a high-five.
That brief moment of being nerdy-cool totally wouldn't have happened in
notepad.exe, and, also, my task wouldn't have been tractable in that. (If I
was using a lesser editor, I would've died of dehydration, as it took 10x to
1,000x as long, or blown out my hands from stupid mouse&keyboard RSI.)

(BTW, finding certain tools much more productive isn't due to an unwillingness
to try new tools. I try new tools recreationally, and am also doing a
complicated startup in which I have to do All The Things. But there are some
tools I end up keeping going back to, after trying other things, because they
really do seem to pay off in productivity.)

That said, apparently, the way Carmack personally uses editors, and what he
gets from them, any old editor will work about as well as any other. And I'm
not a snob about what works for me: I'd still hire Carmack, even if I saw him
hunt&peck typing one-handed into notepad.exe in the interview. :) I'd guess
there are other classes of tools in which he finds big wins in the details.
Also, I know Carmack experiments with other tools, since he was even working
with Racket/Scheme on Oculus for a while.

~~~
notjustanymike
> I'd still hire Carmack...

Ya think?

------
pmoriarty
Carmack would be far more convincing if he could have said something like _" I
was once a power user of vim/emacs but I went back to programming in nano
because I didn't need all those features."_

Somehow I never hear anybody say that.

As a long time user of both vim and emacs, I find it intensely painful to
watch some seasoned programmers tediously mouse their way through mountains of
text.

I often think to myself, _" ok, you've just taken half an hour to do what I
could have done in less than a minute."_

Honestly, I have better things to do with my time than edit text, and when I
do edit text I want to get the maximum accomplished in the minimum amount of
time so I can get on to the thousands of other things I want to do with my
life.

Using a crippled editor or not taking advantage of editor features that could
save you massive amounts of time, errors, and headaches runs directly contrary
to that intention.

It's great that Carmack is satisfied with his own setup but in my case you'd
have to pry my vim and emacs from my cold, dead fingers.

~~~
OneGuy123
Give example of this "half an hour that could be done in less than a minute"
thingy, because as a programmer in 12 years and NOT being a power user I agree
with Carmack: typing and using basic text editor functionality of Visual
Studio never was a bottleneck in programming.

Slowdowns are ALWAYS programming related, never text editor related.

~~~
em-bee
if you are doing refactoring then good editor assistance can save you a lot of
effort

~~~
TinkersW
You don't need power editing for refactoring.. VS has perfectly capable
refactoring abilities(especially with plugins like VAX).

~~~
em-bee
but that is power editing. so VS may have some of it builtin, but then
installing a plugin is no different then installing an extension in vim. but
all that is what we mean by configuring the editor for more powerful editing.

------
danenania
Something people often forget to consider when they talk about all the
benefits of being an editor power user: how often they get distracted or go
down rabbit holes when tweaking editor config or using advanced features. I've
worked with people who seem to spend half their day on this stuff.

So while it can certainly be impressive to watch someone who has mastered
their editor, I always secretly kind of doubt that it's really much of a
productivity win for this reason.

I think there are huge wins for getting _proficient_ with your editor
(refactoring commands, debugger, etc. as John Carmack mentions), but sharply
diminishing returns beyond that.

~~~
jorams
> how often they get distracted or go down rabbit holes when tweaking editor
> config or using advanced features. I've worked with people who seem to spend
> half their day on this stuff.

> So while it can certainly be impressive to watch someone who has mastered
> their editor

I'd say anyone who spends a significant amount of time tweaking their editor
while they should be working, outside of (infrequent) setup periods, has not
mastered their editor (or is just slacking off). The entire point of setting
this up is to make you more efficient.

~~~
daemin
So should you write a short script, or build a tool, or write a macro for your
editor to do some repetitive thing or just do it manually for now (and
therefore always in future).

Same thing goes with having a pipeline of transforming data from one format to
another. Do you use a simple ad-hoc method where you just use features in the
tools (Text filtering + Import to Excel + Manually creating graphs), or do you
write scripts to automate part or all of the process?

When should you stop doing things manually and automate them instead?

~~~
Reelin
> When should you stop doing things manually and automate them instead?

When your best estimate is that spending the time to automate it will be a net
benefit in the long run. ([https://xkcd.com/1205/](https://xkcd.com/1205/))
This is hardly unique to configuring an editor or IDE though.

If someone is repeatedly and consistently spending "half their day"
configuring their editor then either they don't really know how to use it, or
they're slacking off, or they consistently make bad time estimates
([https://xkcd.com/1319/](https://xkcd.com/1319/)), or you don't actually
understand what it is they're doing and why.

------
panpanna
When people tell me stories about $EDITOR significantly improving their
productivity, I wonder what kind of sweatshop coding they do where typing
speed is a bottleneck...

I used to have a pretty nice emacs setup but this year I have been coding
python in gedit (notepad.exe of Linux) and I've done just fine.

~~~
infradig
Agree. But I use geany as step up from gedit, just feels nicer to me.

------
GuB-42
Btw, Carmack mention the debugger as an essential tool. That's my main issue
developing C/C++ on Linux. I prefer working on Linux for many reasons but if
there is a negative, that's it.

I found every debugger-editor integration to be terrible, at least compared to
Visual Studio on Windows. gdb is very powerful, but its UI is primitive, and
that includes tui. And most integration basically just assigns shortcuts to
commands and show you the current line in the source file. Something as simple
as stepping inside a function and watching local variables change can be a
problem. Also, no "edit and continue". Someone will probably tell me that I am
doing it wrong but if you do, please tell me what I can do to get a Visual
Studio 6 level of experience.

Of course, I can get around it, the answer fits in one word: "printf". But I
don't want it to be like that, it doesn't have to be, most good IDEs do it
right. Note that I use gdb, but for me, it is the big gun, when other weapons
have failed. Even for crashes, I tend to go with valgrind first if I can.

~~~
brundolf
I recommend giving VSCode a try. It's at the same level of polish as Visual
Studio (it has fewer years of refinement, but also fewer years of feature-
bloat) and because it's Electron, it works equally well on all three OSes. I
haven't used it for C(++) but I've used its debugger integration with both
Node and Rust and been pretty happy, at least with the basic debugging
features that I end up using.

------
WJW
Typing for a programmer is like brake pedal technique for an F1 driver. Yes,
it is important to be able to type effectively. No, it is not sufficient for
being a good programmer.

It's easy to get lost in fancy editing techniques that get you a win of
minutes per day (as Carmack mentions), while learning to come up with a better
design will save you weeks in overall development time. Learning more editor
shortcuts is much easier and more flashy, of course.

~~~
saberdancer
I don't think the comparison fits. You can be a slow typist and still a great
programmer but you probably can't be a good driver if you are bad at brake
technique.

~~~
panpanna
Here is a better analogy:

I knows a famous movie composer who plays the piano with his two index
fingers.

~~~
marvin
Ditto I'm aware of a famous composer (leading productions involving tens of
musicians on stage at once) who doesn't know how to read sheet music.

~~~
zimpenfish
As Deadmau5 says in his Masterclass trailer, "If I could play it, I would, but
I can't, instead I have to draw it."

------
fit2rule
I've been using vim/vi for decades, and am constantly referred to as the 'vim
guru' in my dev sphere - but I only know like, 5 basic things -
editing/navigation, search/replace, window management, cscope integration and
.. Termdebug. The magic, though, is knowing how to access the command history
window .. for some reason this always gets oohs and aahs.

For me, Termdebug is the killer feature. There's something about being able to
debug things faster than the other IDE-using folks, who are usually just
waiting for the spin-up of their IDE into debug mode to stop by the time I've
already stepped through the code in focus ..

I think a lot of people would be in the vim camp if they could just master the
5 basic operations they'd need to use vim. Its pretty interesting to discover
the whole world of stuff in help.txt that I just never, ever touch, for
whatever reason ..

~~~
matwood
I know enough vim to get around, edit, and search/replace. I put in the
original effort so I could edit files on any unix server I ended up on. I also
like the modal editing concept.

But, even though I bring vim keybindings to all my local editors, my day to
day is still a mix of vim + mouse navigation (and cmd+t obviously). I have
never felt hindered by not being all vim.

I do touch type though, and have known programmers who hunt and peck with
their index fingers. Not being able to type nowadays always seemed odd to me
since, I just assumed people would learn to type better by being at the
computer all day.

~~~
bmayor
You don't get strain injuries if you hunt and peck. Being on the home row all
the time is very un-ergonomic, depending on the size and shape of the hands.

If you have broad shoulders and long arms, finding a good posture is even more
difficult.

~~~
voldacar
If you have broad shoulders, it's worth investing in a split keyboard

------
hevelvarik
I’ve tried to force myself to pick up vim a few times but after getting a bit
older I realized that I don’t want to become one with my machine as a fighter
pilot might be with their plane. I like the distance the mouse move and click
provides me. I do more thinking and reading than typing anyways

~~~
ztjio
The reason to pick up vim is ubiquity, not efficiency. And you REALLY don't
need to know much. Maybe half of what's in the vimtutor tutorial is enough.
Personally, I'd also suggest at least learning how to do search/search &
replace with regex which is easy too (and bonus, has high affinity with sed.)

That seems like the most any modern developer/*nix user should need to concern
themselves with vim and wholly for the reason I mention above: it's the most
likely text editor to be there on unix-like systems.

~~~
bitwize
It's 2020, dude. No one sysadmins individual boxes anymore, it's all
infrastructure-as-code. Which means if you have a problem with your server
infrastructure, you shoot those cattle and provision new cattle with the CFT
you wrote in Visual Studio Code.

------
GhostVII
I find being good at vim makes exploration much easier though. Being able to
use Ag to populate a quick fix list is way faster for me than ctrl-f plus
clicking through every option. And being able to go up and down the movement
stack let's me retrace how I navigated to where I am right now, in a way that
isn't possible in many editors. Tools like just searching through open buffers
let me use search in large codebases without having to wait forever for
results. So for me being good at an editor is more than just being able to
make fast edits (although that's definitely a benefit too).

And even if I only saved a few minutes a day, over several years that is a lot
of time saved, without much investment. It's really easy to get started with
vim, get comfortable with the basics in an hour or two, and then just get
better by using it every day. Then you can slowly introduce features that save
you time. Just setting up fzf and ag has probably saved me several minutes a
day vs. using vscode search.

~~~
brandonmenc
> Tools like just searching through open buffers let me use search in large
> codebases without having to wait forever for results.

Is there an IDE that does _not_ have this feature?

~~~
plorkyeran
If Xcode has an option to search only in open files I've never found it.

------
TeaDude
To be honest, learning power editors is mostly just an excuse to fiddle about
at work without getting in trouble. The work's still visibly getting done and
the bosses don't care if the UI keeps changing so it's a win for me.

In my experience; they DO come in handy! Some programming languages or file
formats get very arsey about formatting and line endings. Sometimes you need
to compare files in hexadecimal. Sometimes you need to mass find/replace.
Maybe not everyday but it's good to have these tools on demand with the know-
how to operate them.

One other BIG benefit of editors like vim and emacs or even notepad++ is that
they start immediately, never lag and don't gobble all the ram. It has
significantly improved my coding performance now that I can just open it on a
whim without having to factor in if it'll slow my system to a crawl with the
other current running programs.

------
nouveaux
This is such an odd perspective. Everyone here would say that the copy and
paste shortcut keys are worth learning. Also alt-tab to cycle through windows.

So why is it so hard to believe that other shortcut keys are useful?

I have deep respect for Carmack. If he would rather spin his cycles to solve
difficult problems, I respect that. To say that learning time saving shortcuts
doesn't save time is shortsighted. If a woodworker chooses to work only with
chisels, it doesn't make him less of an artist. However, to say using power
tools doesn't make you more efficient is a tad disingenuous.

~~~
em500
Powerlaw and diminishing returns. It's worth learning the 20% most used
shortcuts to save you 80% time. It may not be worth learning another 70% to
save 10% more.

The actual thresholds and sets of shortcuts are different for everyone. That's
why discussions like this never end.

~~~
nouveaux
I disagree that its as subjective as you put it. No one would say that a
manual hand drill is comparable to an automatic drill in speed.

Going from normal text editor to vi is like going from assembly to Python. Or
using `find -exec` to delete files using a pattern vs deleting files one by
one. You are that much more productive when editing text in vi.

~~~
phist_mcgee
I have used both an IDE and vim for years, and in my personal experience,
editing text speed is overstated in vim purely due to the kind of text you are
writing, namely a program. Just because I can replace all text inside a tag
90% faster than an IDE does not mean my next thought will be ready to go when
that task is complete. I just don't see where the savings come from in terms
of actual finger presses to outcomes per day.

------
tambourine_man
I’m always amazed how genuinely humble Carmack sounds.

One of the best programmers in his generation, yet he is always sharing what
he’s learned, struggled with and is not particularly good at.

------
xupybd
I use these features more when doing non programming tasks. Often I could use
find/replace and some regex. However I enjoy the experience of having the
editor do some of the lifting. I don't think I'm faster or better for it, just
a little happier.

~~~
nyx_
Agree. Getting good at vim isn't something I do for my boss or my company,
it's something I do for me.

Using something like "ci(" to blank the parentheses under my cursor and
immediately start typing a replacement saves me, like... a couple of seconds.
But it gives me a little dopamine hit that I think helps with job
satisfaction.

------
wruza
If by programming you make a computer do some work for you, it is strange to
not program your programming tools, cause using them is work as well. For me,
unautomated, repetitive editing and a lot of arrow key navigation is like
walking in a swamp. I suspect it must be something with a thinking process,
cause I can think without code, but cannot see much detail where the devil
lives. If it is working code (or a sound data scheme, whatever) then there is
something to discuss. Until that it is just an unpainted picture that is worth
nothing. Also, maybe the amount of "no, you cannot do that this way here"
plays a role in that. Or a fluidity of requirements. If you learned your area
and requirements well, or you are the creator of these, then you know where
the limits are in advance and just do the routine, no matter how hard it seems
from the outside. But when you work with something new, on something unclear,
the speed of a big change and the depth of concentration on it are crucial.
Unimplemented idea is a tree of all possible, very similar code structures, of
which most will fail, and if it is not write-only/write-once, you either have
proper tools to transform it or slow down x10 or more. If you're a long time
developer, then you know that feel "oh there it fails, but now it is so much
keystroke to refactor this, so I will hack it here instead or just leave as is
and pretend it's not a big deal". You know, and be honest, you did it many
times.

That said, I'm not fiddling much with my configs, it's usually just vim and a
lot of snippets like try<tab> -> try { } catch (error) { }, <F3> on an
identifier for log.debug("varname:", varname) on the next line, gr for
grepping it with default excludes, v%<action> to comment/copy/move a block, ma
mA markers to not spoil my stm with file:lines and so on and so on + basic
movement and regex. Nothing fancy or christmas like in these vscode plugins
these days.

------
clircle
Emacs isn't better than Rstudio, Pycharm, TexMaker, and the other programs I
would be using otherwise, but it is more comfortable and keeps me happy.

~~~
panpanna
My first real editor was microemacs on Amiga. Just thinking about it puts a
smile on my face :) I learned C and became really good at it with that editor
and didn't need to change a single setting or learn a complex keyboard
shortcut.

Well not until HN introduced me to dotfiles...

------
baby
This distinction is important imo:
[https://twitter.com/danielhoffmann_/status/13026995532385280...](https://twitter.com/danielhoffmann_/status/1302699553238528000?s=21)

Carmack spends more time in algorithmic and less in churning code.

I personally spend a lot of time reviewing code and looking for bugs, and I
wouldn’t be able to live without a feature to click through function
definition. When I use Xcode to review objective C I feel like have super
powers due to their caller hierarchy feature (which lets you quickly go
through any of the callers up the stack). When I review other code with other
IDE I feel disabled. Unfortunately I spent very little time using Xcode in my
career.

~~~
dzhiurgis
IntelliJ / Webstorm, etc support quite lot of languages. I was reluctant to
switch but oh boy how powerful it is. Absolute delight. Even spell checker is
better than macOSs’ itself.

~~~
baby
To my knowledge they don't have a caller hierarchy thing, or at least not for
the languages I use (go/rust). I'd be happy to be proven wrong :p

(rust-analyzer is working towards one[1], but it never worked for me)

[1] [https://github.com/rust-analyzer/rust-
analyzer/pull/2698](https://github.com/rust-analyzer/rust-analyzer/pull/2698)

------
Skinney
I started using Emacs simply because there was no other editor or IDE which
had good Clojure (my language of choice at the time) support.

After a while, I started noticing how sluggish IDE’s and electron-based
editors are.

I’m now a vim user, but my most used features are «intellisense», go to
definition, find references and ctrl-p. I guess these are the things Carmack
refers to being of value? I also appriciate spending less time moving my right
hand between my keyboard and trackpad for ergonomic reasons.

In addition, I have a more snappy editor than most of my colleagues.

What I don’t have is a good integrated debugger or refactoring support. The
latter i never made much use of anyway and the former i’ve never minded being
a seperate tool.

------
ArtWomb
Flip side of this is that being a power cli user in 2020 is more powerful than
ever before! Recently saw an interactive quantum circuit visualizer in 100%
text mode. And its getting me personally back into old school favs like lynx,
irssi ;)

~~~
srtjstjsj
Text mode is not the same as command-line. A full screen text UI is a low
resolution GUI.

~~~
Reelin
How many GUIs are keyboard driven though? Vim isn't CLI, but it's
significantly more pleasant to use than a GUI for me.

Honestly if someone showed up with a keyboard driven GUI that completely
lacked mouse input and had a modal paradigm I might actually use it over vim.

------
thanatos519
I'm probably a vim power user, but I stopped adding to my knowledge years ago
because nothing seemed to be adding to my productivity. It sounds like Carmack
just hit that point earlier.

I feel this way about version control systems. More trouble than they are
worth to me, even when working in the same tree with many others. If I make a
branch, it's only because that's the only way to submit a PR. Merge conflict?
I'll look at my diff and apply it manually to the other side. Merkle trees are
great, but the only useful history to me is a straight line!

------
m0zg
Yeah, if you amortize your coding output over a significant period of time,
it'll be like a couple hundred lines a day at most. In fact, even as few as
200 lines would likely put your in the upper decile of programmers as measured
in LOCs/day. I didn't believe this actually, but at Google there's a dashboard
where you can look at your (and everyone else's) stats wrt lines
added/deleted/changed, and it doesn't lie.

The point being, you could easily type this many lines per day using Morse
code.

That said, I think Carmack is being overly dismissive here. Sometimes you end
up in a situation where not knowing (or having) certain editor features
results in a ton of tedious manual editing. I know a few tricks to avoid those
situations in my work, and have a few bookmarks to help with the rest. I think
this is the right balance to have - do know features which you find use for at
least once a month, even if they are obscure, and know where to find the rest.

~~~
dzhiurgis
I was able to macro Webstorm to go thru each method in JS module and remove
first param in like minutes. Saved me hours of tedious work.

------
flocial
I suspect the majority of programmers who say this have internalized the core
api features they depend on (function calls, syntax, common algorithms, etc.)
that make them super productive. Whereas average programmers and below need
all the help they can get from their editor to tame the wild goose chase of
looking up common functions, scouring StackOverflow, and even looking for
random snippets on long abandoned blogs, etc.

In other words his mastery greatly reduces his dependence on IDE/editor
features so this makes perfect sense.

Watching Carmack live coding, he types with conviction and gets things done:

[https://www.youtube.com/watch?v=ydyztGZnbNs](https://www.youtube.com/watch?v=ydyztGZnbNs)

Sitting down with OpenBSD during a cabin retreat:

[https://www.phoronix.com/scan.php?page=news_item&px=Carmack-...](https://www.phoronix.com/scan.php?page=news_item&px=Carmack-
OpenBSD-Programming)

~~~
cma
>have internalized the core api features they depend on

He says he still uses intellisense type features to aid discovery and memory.
Just not the advanced stuff for editing.

------
lgessler
I think the best case to be made for learning how to use a "power editor" is
that editing text "manually" can sometimes be seriously disruptive to your
flow. If I can do a regex replace-all with vim, I get to go back to thinking
about my real problems much more quickly than I would if I had to hand-edit.

------
knowyourleadcom
The tons of time multi line editing saved me so I don’t have to look like a
moron adding a chat to each line doing a lord of dance finger tap on the
keyboard.

The basics will certainly double your speed and I say this as I train a junior
person. Quick tab switching, all the copy and paste stuff, etc. The rest in my
opinion of over engineering half the time and preparing for moments that might
not even happen. Certainly evaluate any movement or motion you do all day and
look into optimizing. I mostly learned vim And vim keys for sublime because I
wanted to be more enjoyable to be watched when I code and not have so many
staggering mouse moments. I’ll probably forget everything in 3 years and go
back to the the basics and a mouse.

------
pengaru
Typing isn't the bottleneck for coding sure. But time wasted on text editing,
especially mechanical/repetitious nonsense, is valuable keyboard time stolen
from any more productive computing chores of which I have a seemingly endless
supply of.

~~~
kmc059000
This is my opinion as well. Many of the power user commands I've learned were
to avoid annoying and fiddly things. It is less about saving time and more
about saving effort for me. With occasional RSI, if I can use a couple hot
keys to save 50-100 typed characters, it is very worth it to me, both for time
and effort and to minimize the annoyance-factor of doing the same thing yet
again.

------
Waterluvian
That’s always how I felt. Like 20% of my job is writing code. The rest is
social and design work and documentation.

But I think there are people whose job involves cranking out code all the time
and I can see why it matters to them.

~~~
srtjstjsj
Typing is 2/10 of your job? If your typing is half as efficient, then it would
be 4/12 of your job. Twice as efficient makes it 1/9 of your job.

------
vonwoodson
“I laugh out loud when my kids get giddy about little features of their car
like turn signals and breaks.” -somebody who thinks that it’s not worth the
effort to learn how to use the tools they use every day

------
karmakaze
I learned a similar lesson about typing speed. I learned, then developed and
practiced a custom keyboard layout to make my typing faster and with less
strain. In the process I realized that the amount of typing I do while
developing software wasn't even enough to relearn to type and I had to
practice separately just for the volume. For the strain part, also learned
that the way the keys are hit/pressed is for more a factor than actual key
positions.

------
jnsie
I agree, in general, with his point. But multiline editing was a real game
changer for me. Things I once did manually that can be achieved with
significantly less tedium.

~~~
meheleventyone
How do you use it? I’m terrible at using these sorts of features. I
occasionally try again but often find it awkward and not much of a win over my
normal method that doesn’t involve multiple cursors. I figure either I’m doing
something wrong or just not coming up against the right cases.

~~~
jnsie
Definitely courses for horses, and all that. Whichever way works quickly and
accurately for you is the best way...

I've used multiple cursors for many purposes, initially as a dev it worked
very well as a poor man's ETL - take a spreadsheet and perform a bunch of
transformations (reverse first name and last name, trim these fields, add
leading zeros to this field, concatenate these fields, delete this field, use
some sublime plugins to generate incrementing IDs, etc.), wrap it in a SQL
insert statement, etc. etc. I used it a ridiculous amount and at times it made
me look far more efficient than I really am.

I'm on the business side now but even today I found myself cleaning some data
with multiple cursors, sorting alphabetically, and then using a 'count
duplicates' command I found on GitHub to remove duplicates and prefix each
line with the number of times it was duplicated. I could have done it in
excel, but it took me literally 20 seconds to do it in Sublime.

------
redisman
I find Sublimes "power" features really useful for the tangential stuff.
Getting a good look at a JSON object, preparing some mock data, preparing one-
off data. Basically everything that falls before the threshold of being worth
automating or writing a script for. With multi-line edit and a couple of
plugins you can do some "excel" like stuff without the overhead and with the
simplicity that plain text brings.

------
InfiniteRand
There’s an age factor here, or maybe a certain phase in programmers’ growth
(which sometimes they can cycle back into).

I am not that old, but I am old enough to remember a time when I was really
into those power features. Over time you get burned by having to change
platforms during career evolution, you get other things taking up your spare
bandwidth, and you get slower.

Now learning the power user features just doesn’t have the same appeal

~~~
plorkyeran
Having to move on and relearn editors isn't a given. I learned how to use vim
20 years ago, and have used vim or vim modes in IDEs ever since.

------
nix23
I was never a Fan of Shooters...but i really love that guy. He is THE example
of a decent "superstar" developer without BS.

------
bitwize
I've used Emacs since forever ago. I don't bling it out with Spacemacs, Doom,
or any of the other things people install these days. I sound/feel like a
boomer railing against kids with their Minecrafting and Roblocks and social
medias. But the point is, my Emacs workflow is reflective of the fact that I
don't use Emacs because it gives me some huge needed leverage over the _act of
writing code_. That is relatively straightforward, and the plain Emacs
bindings, once learned, are more than suitable to the task.

Rather, I use Emacs because of a combination of pain points that it simply
handles better than other editors, that add up to a significant advantage:

* Emacs does electric indent "right". Other editors will attempt to indent automatically, but the tab key always means "insert tab", not "indent this line to its computed indent level". This alone makes it more pleasant to use than most "modern" code editors.

* By default, Emacs will help you match paired delimiters (parens, brackets, quotes, etc.) but will not insert closing delimiters. This saves me that awkward experience of typing out a code block, parameter list, or string constant, only to find that I now have mismatched delimiters because I didn't realize I was supposed to cursor over the closing delimiter my editor oh-so-helpfully provided rather than type it myself. Except some editors just cursor over the closing delimiter if it senses that you're typing the delimiter at point. Some don't, though, and it's hard to remember which is which!

* I work a lot in Lisp, and Emacs is better suited to handling Lisp code than most other editors.

* Emacs is an immensely useful _programming environment_. There are _applications_ like Magit and Org-mode built on top of Emacs that are just stupid useful workflow grease. On top of that, if there are pain points in my workflow, coding something up in Emacs Lisp to handle them is incredibly easy and straightforward, and I can evaluate and test my code right in my running Emacs session. Contrary to popular belief, Emacs integrates well with Unix tooling; Unix tools can be easily plumbed together with Emacs buffers, enabling you to use Emacs as a kind of "super-shell" to capture, move, examine, and massage data.

------
melling
I just signed up for [https://repl.it/](https://repl.it/)

I’d like to kick back on my couch and code for an hour using my iPad and Apple
Pencil.

I’m anxiously awaiting for someone to image a better mobile experience rather
than attaching a hardware keyboard.

~~~
knubie
I hear you. One of these days I’d like to make a nice drag and drop editor
experience for Clojure.

------
Const-me
Not sure I agree. I've been paying for a personal license of Visual Assist for
a few years now. The power editing features I'm getting from it are really
good, save me a lot of time. The "rename identifier" feature alone justifies
the cost for me.

~~~
rowanG077
Did you read his post? He is not talking about IDE-like features, just about
pure text editing ones.

~~~
dzhiurgis
There’s some overlap - like option + up/down in intellij. Wouldn’t work
without some parsing, yet basically editing text. Super powerful and
personally probably most used feature.

------
FpUser
I am slow typist and really lazy at exploring all the possibilities of modern
text editors/IDEs. Well except of intellisense which I consider absolutely
invaluable. Still I do not feel it ever held me back when programming.

------
gentleman11
In JavaScript, I often had to solve bugs and traced logic through 40+ source
files. The reason I learned some editor power features was just to be able to
navigate files quickly. For continuity of thought, I found it valuable

------
pmoriarty
Could someone paste Carmack's twit here?

I can't seem to see it without enabling javascript.

~~~
skytreader
Tip: You can replace twitter.com with nitter.net and read tweets outside of
Twitter's awful web UI.

[https://nitter.net/id_aa_carmack/status/1302651878065475584](https://nitter.net/id_aa_carmack/status/1302651878065475584)

There are browser extensions to automate this too but I haven't tried any yet.

------
kobe_bryant
tbh the main use I have for a text editor is comparing files

------
eddhead
I hope HN will shut up about Vim and Emacs now

------
sebringj
IMO, That kind of crushes any argument about the tool you use, other than your
brain.

------
benreesman
Carmack is...a special case.

The reason why being blindingly fast in tmux/emacs/vim/shell/etc. is a
difference in kind rather than degree is because it lowers the activation
energy on trying radically different things. If you can move massive amounts
of code around quickly and accurately you can try a different design on a
whim, and throw it all away without a second thought if it doesn’t work out.

When manipulating code is time consuming there is a tendency to “make it work”
with the design you’ve got. So much code looks like someone “made it work”.

