[jt2190]

> … discretionary friction; designers or product folks adding features or complexity.

This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.

[skydhash]

> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

With Vim, Emacs, Git,... there's a core concept that all those extras get backs to. The issue with normal editor is that their concept of a text file is an array of lines of characters. Some goes further with providing some parsing to further isolate things like strings or symbols.

With Vim, there's the buffer (aka the content), the window (where user view the content), the cursor (which is the point of origin of many actions) and various commands that moves the cursor according to what's in the buffer. Like with the hand, you can draw, write, make dough, play the piano,..., you use the same hand, you don't have to replace it to do any other actions, you only taught yourself how to do it.

Same with git. It has a core concept that encapsulate everything to do with versioning text files, you just have to compose them to do what you want.

This kind of conceptual simplicity, even though the interfacing may be rough, is good because you are solving classes of problems instead of solving them one at time. For a particular problem, you only need to switch configurations, not to learn a new tool.

The issue is when you tackle a bunch of features not related to each other, or simplify the model so much that it's a toy instead of a tool.

[zahlman]

> a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.

I don't think this was actually established. The author may have a point about the UX of multiple cursors in Sublime, but comparing that to Vim macros is missing the point of the macro system — i.e. that you can create something that persists between editing sessions, and encapsulate a sequence of steps even of fundamentally different kinds. (For example, do multiple cursors allow you to implement a new command to transpose elements of a comma-separated list?) More importantly, though, this is not addressing the general principle about "extra features".

I haven't known other Vim users to speak of such "games".

[bccdee]

Yeah I think this is all coming from someone who never got good at vim.

Multi-cursors can be nice, but a sufficiently powerful implementation of that looks like helix or kakoune, and those are at least as complex as vim, if not more.

When you're good at vim, it is invisible. Once you're good at writing macros, you can do stuff which is impossible with Sublime-style multi cursors.

I assume those are situations where the author would have "just written a quick script," but vim macros are an interactive scripting language specifically designed to tersely express text transformations. Your script is never going to be quicker than that.

I'm not saying this as a vim partisan or anything. You could easily argue that vim over-optimizes and saves little time in the grand scheme—that's a fair critique. But it's strange to insist that complex tools are complex only for the sake of complexity. It's a weirdly conspiracist mindset.

[zahlman]

> but vim macros are an interactive scripting language specifically designed to tersely express text transformations

Yes, I think this is important here. Although it's still hard for me to imagine a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?) as opposed to recording them. Perhaps it's within my grasp to optimize them later, but.

All that said, there are quite a few things I don't like about Vim even though the overall editing model clicks with me, and ideas I've had for something I'd like better. Although I guess I really should check out alternatives before running my mouth about that…

[bccdee]

> a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?)

Oh it's so simple you'll kick yourself. If you save the macro to the q register, just paste from the q register and it'll print out the corresponding inputs. Copy the inputs into the w register and now you have that macro saved in a second place.

Some people probably do save macros in their vimrc this way, but I use it to correct typos I made when recording the macro. BIG help.

[zahlman]

> but I use it to correct typos I made when recording the macro.

Oh you mean like, now that you have the keystrokes inserted into the current document temporarily, edit and move back to a register?

[bccdee]

Exactly. Modifier sequences and escape presses show up as special characters and can be inserted with `C-v Esc` or whathaveyou. It works seamlessly.