Screenshots from developers: 2002 vs. 2015 (2015)

> But terminals and editors is sticky in a way that tells me it's probably close to optimal.

Optimal for those users, at any rate. IMO using a terminal editor is so painful compared to a decent GUI (Sublime or even VSCode) that I have a difficult time understanding why anyone would choose such a tool. I just try to repeat the mantra of "everyone likes different things" and stop trying to understand something where I likely never will get it.

It’s funny. I thought the same thing before taking the time to become familiar with VIM keybindings and now I find VS Code tedious and painfully slow.

I guess once one gets used to it or anything it’s going to be more productive than the rest of the tools.

Take about anything from a standard GUI editor. In a terminal editor, they are also easily accessible. And more easily accessible (if not discoverable). But one of the major gain is how close your shell is. A lot of editors allows to start a cli tool and optionally send a portion of the current buffer as input to it. You may also be able to include the output in some buffer too. Some GUI editors allows that, but it's almost always a config maze and you're never sure of the environment in which it does run the commands.

Also in a terminal environment, all you enter are keyboard keys. If you know how to touch-type, your cognitive load can be greatly reduced (personal feeling). You can also navigate something like sublime with keyboard only. But it's way more tiresome.

For me its how easy it is to extend. Kakoune makes it so easy to integrate with the rest of my system. I can often create any kind of integration I need with just 1-10 lines of code. In vscode I need to just hope that someone else built the integration I need as a plugin, because writing plugins is really painful.

what's difficult about it?

I have auto complete, LSP, format on save for may languages, fuzzy finding. my neovim config file is 355 lines, with comments and line breaks.

Normal, good editors are great already with 0 line config. That's the whole point.

Terminal editors generally do support the mouse, and there are occasions where even a fairly skilled user of a good terminal editor will find it easier to click to set an insertion point than use commands to reach it. But having those key-command options greatly enhances the experience. You need to watch the screen while a skilled user edits text to get it. It's like magic.

I haven't picked up nearly as much as I'd like, but even basics (requiring zero config) are way beyond what I could easily do in any GUI editor I ever experienced. For example, in vim, if you are on a bracket or parenthesis (open or close) in edit mode, it is three keystrokes to delete the entire bracketed portion, precisely, regardless of size (even if the matching bracket is off screen). Finding the matching bracket with the mouse is often hell.

And it's not as hard to learn as you may expect, because those keystrokes are not magic codes; they're part of a consistent, thoughtfully designed command language. You choose a mode for selecting text (character based, with lowercase v), use "motions" to select the text in that mode (in this case, a single "go to the matching bracket" motion, which is the percent sign), and take an action with that selection (delete it, with d).

I wonder if there's a worthwhile time-saving in aggregate? To me it seems like overall the bottleneck is always thinking what code to write/edit, not the actual edition. So I'm not convinced shaving a couple seconds here and there outweighs the benefit of a modern IDE or offsets the time spent ricing such a setup.

Seems like the opposite to me. IDE fashion changes like the wind. "Normal developers" are constantly starting over with new tools and new paradigms every time they start work on a new project. Gotta have the right vscode extensions to flash your firmware, IT only supports IntelliJ on the new job, ad infinitum. It's been this way for decades.

My .emacs file gets updated regularly, sure, but it's thirty years old, and my basic flow hasn't changed.

> To me it seems like overall the bottleneck is always thinking what code to write/edit

I feel the same way. But small advantages compound to at least some extent (see e.g. https://danluu.com/productivity-velocity/); and I find that noticing that it takes more time than I'd like to write/edit something, risks breaking my flow.

It's not mainly about speed (although the ceiling is much higher), but about ergonomics, and, plainly, enjoyability. The other benefit of making your own environment is mastery and control; only you can decide when and how the environment changes.