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.
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.
> 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.
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).