[Izkata]

I don't think it's even so much about keystroke count as it is the "commands" are more like a language that you can keep getting better in. For example, from above:

> d), d{

That's not two different commands, it's one action (delete) and two different motions (forwards one sentence, backwards one paragraph). Motions work on their own for moving the cursor, but can be combined with different actions and repetitions to multiply the sentences (commands) you can make. As you increase your vocabulary over time (there are a lot of motions and selectors (which are slightly different but used similarly)) you can keep reducing that friction between thought and screen.

[kryptiskt]

Yes, I'd say the composability of commands is vi's key feature. I can't remember any but the most common shortcuts in other editors. In vi I get so much more bang for the buck since I have easy access to all the commands I remember multiplied by the motions I remember.

[homebrewer]

And these commands are useless for programming unless you format source code in a very specific way, adding white space such that everything is split into "paragraphs" that can be thought of and operated on as a single unit.

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

[chongli]

As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST. Proper IDEs (not VSCode) in a hands of a power user who knows what his "hammer" can do (and how to invoke the necessary behaviour) are much more efficient at it compared to any text editor.

That's assuming you're spending all day editing files written in the language(s) supported by your IDE. That assumes a great deal about your programming environment, toolchain, plugins, and configuration. Switch to a different language with different syntax, different idiomatic style, different IDE plugins, and you may be faced with a totally different editing paradigm.

This is where vi shines: the tool is excellent at editing text and is therefore 100% language-agnostic. It can easily handle jumping between files written in different languages, including plaintext files, configuration files, domain-specific language files, and otherwise many other files with syntax that may not be supported by your favourite IDE. Furthermore, it is equally happy working on files that combine different sections written in different languages. Sure, some other editors (such as emacs) and IDEs (such as RStudio) also support this sort of editing, but vi doesn't need any special support for it.

This philosophy, of making text the first-class citizen, in many ways mirrors the Unix philosophy. It also happens to be the case that vi (as well as its ex command line) provides a very convenient command for piping lines, paragraphs, and any other motion you desire through a shell command (or pipeline) of your choosing. This makes it very easy to format text using commands such as `fmt` or `column`, or apply line-numbers using `nl`. This, I believe, makes vi the ideal text editor for developers working on Unix or Linux software.

[doix]

Yeah, vim was invaluable when I worked in the semiconductor industry. Lots of perl, TCL, SKILL (a lisp dialect) and giant verilog netlists. Languages which don't really have proper IDEs or great all in one tooling.

Now I'm a webdev with everything written in typescript and just use Cursor (basically vscode) with the vim plugin. i miss the tab model from vim a lot, but apart from that the vim plugin is close enough.

[mikojan]

> As someone down below mentioned, programming is not as much editing text as it is massaging the underlying AST.

Then why does your IDE not look like Scratch?

It is because nobody has found a better representation then text when it comes to editing concrete syntax trees.

Yes, you will rarely reach for d) or d} when editing Java or JavaScript. But the Vi paradigm does not stop at prose. And it does not stop at modern IDE capabilities either.

The Vi paradigm just enables people to do it faster. With less friction.

[sudahtigabulan]

> I don't think it's even so much about keystroke count as it is the "commands" are more like a language

It was about minimizing the number of redraws, but this indirectly might have led to fewer keystrokes too.

As you mention later in your comment, there are a lot of motions (which could be combined with deletion too). This is probably related to performance too, because they make it possible to achieve something quite specific like c3), with only a single redraw, and three keystrokes.

The "language" is undoubtedly a very good choice on part of Bill Joy. It wasn't necessitated by the hardware constraints, I believe. The separate modes neither. It's just that he would have wound up with less ergonomic key mappings.

Without the modes we would have to suffer using chorded shortcuts with modifiers, but they could still form a language. Think "M-3 C-d C-)" instead of d3).

Without neither modes nor composition (the "language"), it would have been even worse. A large number of single-purpose shortcuts, likely with multiple modifiers; he would have run out of (memorizable) single modifier combinations.