Agreed. I used to enjoy vim macros, but ever since switching to Helix I reach for its multiple cursors all the time and barely use its macros. But that doesn’t mean multiple cursors don’t have a learning curve, I still need to think of he method to place the cursors in the right places.

What I find especially weird is that I'm not sure I've ever heard anyone describe vim as a puzzle that's fun to solve. The most common sentiment is that it has a learning curve, but ends up being worth it.

That's not what I was saying. I used vim macros specifically as an example, not Vim as a whole.

> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.

and

> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.

From the article:

> multiple cursors really are better than macros 99.999% of the time (since they give direct visual feedback)

I don't know what he means, vim macros also give direct visual feedback while writing them. You just edit as normal while recording, and replay those edits later. I think it is technically possible to write a macro without seeing the live effect on the text as you write it, but I've never done that.

I looked up multiple cursors out of interest, I guess the advantage is that it's one interface that is easy to explain. I would use multiple vim commands to replace it in practice.

I'll agree that multiple cursors are maybe better than macros for most of the things that someone would use multiple cursors for, but usually I wouldn't use macro's.

But I think most of the things I do with macro's cannot be done with multiple cursors.

I would be very interested in being proven wrong, if someone has some examples of "this is where multiple cursors are great, and vim doesn't have a good alternative".

> In the long run, every piece of software tends towards mediocrity.

Alternative view: Maybe that's okay, and greybeards know that.

Mediocre: "something of only moderate or ordinary quality"

Maybe we don't need the latest and greatest extraordinary technology when coding our next CRUD app.

I think I noticed halfway through reading that most of this is AI nonsense.

I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build script

    cat packages.json | jq .scripts

And that's useful if I'm in the terminal, but if I'm in VSCode I'll just do

    ctrl-p -> packages.json <enter> -> ctrl-f -> scr

It's actually fewer keystrokes.

I dunno, I've learned that people's workflows are really personal so I'd never tell someone to switch their's, but for me I prefer tools that understand the structure of my project instead of just treating it like text, so IDEs are a preference for me.

Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient.

That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.

I've been working with the command line for just under two decades. A couple of years of those were spent with vim as my primary editor, but eventually I moved to Sublime and never looked back.

But I still use the command line heavily in all my work. I usually have a konsole window that I alt+tab into whenever I need to build or run tests, instead of using Sublime's "build system" support. The only time I use vim is when I need to ssh, or am using Termux on my phone.

> The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases,

Extensible GUI tools (Sublime, VSCode, etc) cover infinitely many use cases too, except they offer more reliable and reproducible runtime environments.

I think the reason these types of discussions never die is because people in general tend towards closed mindedness. It's hard to put yourself in other people's shoes, and even harder to entertain the possibility that you're wrong.

But at the end of the day this only matters for novices. After enough experience with them, no matter what you use, your productivity bottleneck isn't going to be your tools (unless its ed...).

The article was not against a tool but a way of thinking. He didn't say anywhere that Sublime was better than Vim. He did say that he disagrees with the idea that a tools friction is a feature.

I can take his entire thesis and use it to show that vim is the perfect editor for me precisely because vim is invisible to me when I use it. In part this is because I turned vim into the tool I wanted. He turned sublime into the tool he wanted. His basic point however still stands. If you are making something for someone else to use then making that tool invisible to them is a powerful property.

> I am afraid the author confuses familiarity with proof that his tools are better.

Literally NOT what I was implying or even said anywhere. Quote me where I said anything like that.

To quote myself:

> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

This has nothing to do with why I or another person one tool over another, but rather treating the flaws as if they are things to have a puzzle game to work around.

If we make a distinction between CLI apps and TUI apps, my interpretation is that the article was specifically talking about the latter.

By a CLI app (with the emphasis on command line) I mean something like grep, sort, cp, git, ls, tar, etc. The normal way of interacting with these is by writing commands on the shell, which means that if you know how to use it normally, you can also use it in a script. Which means that you can combine these into pipelines.

By a TUI app I mean (and I think the article means) something like Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, etc. - an interactive app that takes over your terminal while you're using it. You're not going to compose those into a pipeline. Or to be more precise, you're not going to use them in pipeline by using them the way you normally use them. If you can use them, it's probably because the app decided to provide a command-line interface in addition to the TUI.

It has a pretty profound impact on me, since the only way I can use a computer is using a screen reader, which works primarily using a keyboard. It can read things under the mouse, but it is not at all a comfortable way of working.

I don't think of vim as a puzzle, but I do use it because I find it fun to use in some ineffable way. Note that I also don't claim that it makes me more productive; I use it because it sparks joy, regardless of however productive it makes me.

> I'm not sure I've ever heard anyone describe vim as a puzzle that's fun to solve.

Search for “vim puzzle” and you’ll find entire websites dedicated to it. Here’s a random one: https://vimventure.dev/

I think configurability depends on how important your tool is to the core job function or role being performed, where it becomes very valuable for helping them directly perform the tasks they and their employer value, vs how much it allows you make problems they don’t value as much get out of the way of the ones they do.

For example, I am a HUGE fan of the way Gusto handles payroll and all the different taxes and form filing for me, because I basically do not even have to think about the problem or fiddle with it at all. But to someone whose job is doing payroll/accounting/taxes or working within giant enterprise HR/legal/finance departments that does more harm than good, because it’s something they have to fight (or less charitably it makes their job too simple).

The other big problem is who is actually making the decision to pay or spend money on a thing, and whether it serves more of a defensive (eg auditability, security, constraints against undesirable behavior) or creative purpose. The creative stuff is sexier but hard to quantify, and end-users won’t actually be willing to pay that much for it relative to how much it helps them or how critical it is to their role.

Getting out of the way is important because people use dozen of tools each day for n and out.

Unfortunately there is still a thing to balance against, which is forcing people to do the right thing.

There always will be bunch of people who nag about being impeded by doing something correctly, because they feel it is waste of time.

Recently revamped my terminal setup after all IDEs have just gotten painfully slow to work with (the debugger + git integration in intellij was my last moat, but spend some time to learn nvim-dap + lazygit and it's excellent). AI has been immensely helpful here too to figure out the long tail of weird config gotchas.

Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.

it really depends on the framing, some work, especially fun work that develops skills is more valuable than people realize.

From an org perspective the goal is to create the highest curve of performance over the lifetime engagement of the employee or from the employee perspective their career.

And a lot of that depends on teh relationship of the people involved. From my perspective its a net negative when if my movers worked out the day before, their muscles will be sore and they'll do a worse or slower job. From the moving companies perspective its good, they'll be stronger for more jobs. Unless they quit or are fired that day, in which case we're back to bad.

The real evaluation isn't the macro vs the sublime edit. its does the thought process of making them macro improve them in other things, and what were they doing before that. In my experience no one is going use the time they spent writing a macro or a learning vim to do real meaningful work, they're doing that because they're bored or burned out and want to think about something else they find fun at the time.

your problem isn't your employees choose to write random scripts, its that they dont have a sense of urgency or care about their current task.

> You just edit as normal while recording, and replay those edits later.

And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.

Some time ago I made an abstraction "hey, most people in our company who use CloudFront don't care about all the implementation details, they just want some paths to be somewhat cached". I explained this idea to a coworker. It took a while, but he understood it. Two months later someone merged a PR that replaced my interface "I want this and this path cached" with a simple passthrough that exposes raw AWS interface. Same thing happened to S3 buckets where I noticed that most people just want "auto-delete files after X days either on or off".

I spent entire year trying to explain to my manager "most devs who create services want a simple deploy button". Instead, we tried to teach devs how our "infrastructure as a code" works so that they'd contribute. The effect was that only one guy engaged with us this way, and he always sent us AI-generated PRs, and every time he saw an error, he just copy-pasted it to ChatGPT without reading and then the answer back to me.

The project eventually shifted towards my original idea, but in an extremely painful way without any design at all. It's just a toolbox of completely random features glued together because one day manager says "no we don't need to support X" and two months later a Jira ticket "add support of X".

The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a different mindset.

And the other thing is that vim has the “dot” command to repeat your last edit. Similar to macros, you think about your local edit first, then about where to repeat it (usually tied to the next item in the search list).

Edit (after reading the article).

Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.

> make the users fall into a pit of success

I don't have anything else to add but I thought this was a wonderfully evocative phrase.

I think if you need to measure this kind of thing, you're missing the point in the first place. I don't want to be chasing some absolute productivity metric, I want a setup that doesn't break my flow. For many people, reaching for the mouse breaks their flow and feels wrong, which is oftentimes worse than being a second slower, because it takes you out of the mental frame you were in.

For me, using my mouse while I'm working feels natural, so trying to change my workflow to learn how to navigate everything by keyboard would be a huge amount of extra effort just to maybe possibly save a little bit of time in some situations.

>He turned sublime into the tool he wanted.

I think this also misses the point. Sublime just is the tool I want. I install it and I use it.

Eventually I may install a handful of add-ons via the baked in package control. But primarily it just is the text editor I want.

Agreed about the difference between CLI and TUI; at the same time, I do indeed prefer TUI over the “normal” (window) GUI apps for the exact reason why I would prefer vim (or emacs for the other half) over a GUI editor: when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me, or even, what is your default starting point: is it a desktop with icons or menus, or a command line with a prompt? For me it's a terminal, so I prefer TUI apps.

...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.

I think this is really insightful. Every "good and invisible" tool I thought of fit neatly into one of those two categories. Examples:

Powerful and specialized: automatic transmission, display/monitors

Simple and limited: syntax highlighting, deterministic autocomplete

The closest ones imo that bridge the gap: ssh, google search

That's just it though isn't it. Good tools that are invisible to you won't easily come to mind because they tend to be, well, invisible.

It's not until you randomly end up on a system which doesn't have that tool that its usefulness becomes visible; and I mean really visible.

A tilling window manager is a fantastic tool that is close to invisible.

Though I don’t agree with the author. Visibility isn’t what matters, if you get comfortable with a specialized tool like a CAD software, or a game engine studio like Unreal, it’s not invisible at all but your brain will stop focusing on all the noise on your screen and you become pretty focused and productive. I live emacs, but Rider is also a fantastic editor.

Though I would love for things like LLMs to be way more out of your way, more “invisible”, more tool like. I hate the current UX of having to tame a patronizing, annoying fake human just to get things done the way I want them to be done

Thanks for explaining the context. It makes sense in your case where using mouse is a hard constraint. My reaction is more towards people who optimise for productivity.

> Sublime is invisible to him because he's been at it for fifteen years.

It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.

> But the escape hatch is the whole problem with his thesis

I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).

> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.

I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.

I am not sure how to summarize the entire article other than what I already wrote in the conclusion.

People don't use vim because they enjoy puzzle solving. I don't even know how you got this conception. People use vim because they are effective at editing with vim, period, just like you are effective with Sublime Text.

People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that. That's a silly misconception and veiled attempt at feeling superior at those time-wasters.

> rather treating the flaws as if they are things to have a puzzle game to work around

Case in point.

Good tools are indeed invisible, but the arguments the article is built on are very shaky and honestly just sound from someone that didn't spend much time with other tools, but still has strong opinions about them.

The eye.

I think that's a pretty reductive stance to take. Keyboard nagivation is more productive _if_ the primary use of the tool is text-based. In a word processor, an IDE, a file manager, or anything else where the primary mode of interaction is reading, typing, and processing the things you've read and typed, keyboard navigation can be demonstrated to be faster and more natural _only if_ the user has taken the time to learn the shortcuts.

For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.

I think you hit on a point with git and sql I made in a different context.

Removing friction from the context and flow. For what git and sql do, they arguably have the most efficient and effective work flows for their purposes.

Managing complexity becomes unavoidable for certain problems, so for challenges of the tool, sometimes, it's simple the challenge of the problem.

I would say his point is not articulated well. Tools should be less toilsome and provide faster feedback loops.

Specific enthusiasts enjoying something is different from telling beginners that "vim is a fun puzzle to solve".

Here's some additional context on the phrase, for today's lucky ten thousand[0]: https://blog.codinghorror.com/falling-into-the-pit-of-succes...

[0]: https://xkcd.com/1053/

> The things about multiple cursors is that you think about the processing while doing it

That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.

If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.

Exactly. And I'm no purist - I'm happy to use "dot" with a mouse if I want to easily repeat an edit in tens of places if they're not nicely aligned or searchable.

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.

All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?

I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.

I think this is unhealthy self-handicapping. Your "flow" is just habits, things you've taught yourself to do. You weren't born with the ability to use either a keyboard or a mouse, there is no "natural" or "intuitive" way to operate a computer. It's all 100% learned behaviors that can be altered.

Reaching for the mouse doesn't break my flow. It makes the thing I was doing invisible in the flow. Keyboard shortcuts require me to think, which makes it FEEL like I'm doing something, and that something is in the flow so it feels like I'm productive. However the mouse doesn't even enter into the flow at all, I just do the thing and get on with the real work without breaking flow.

Again, there is no universal correct answer. Sometimes the keyboard really is better. However sometimes the mouse really is better and because I'm proficient in it I don't break my flow to use it.

> People don't use vim because they enjoy puzzle solving.

I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!

> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.

A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.

I am not sure how much clearer I can be in the article or in my replies to comments.

I do know quite a few people who use vim because they do enjoy the puzzle. So there are absolutely people as he describes. Saying that there aren't people like that just undermines your point.

Drawing/Painting and Cad modeling is very much like games. One hand on the keyboard and the other on the mouse. This mixture can be also done well in other programs. I only bother learning shortcuts for daily tools, not something I use every blue moon.

What I take issue is with tools that make them hard to use with low contrast between widgets or shortcuts that does not work if a text input is focused. Also tools that forget they have a primary usage and wants me to know everything at once (notifications, big action buttons, guided tours and what not).

Many definitions of tool explicitly exclude body organs to draw a line between innate mechanisms that are inestricably linked to the body and objects used to extend one's innate physical or mental influence on the environment. The eye is not a tool, according to these definitions, but eyeglasses are.

> That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it

I do not disagree with that

> When you do a macro, you have to try and get it right, and then try again from the start each time to get it right.

But you are wrong in that, because you assume that visual feedbacks are necessary. They are useful. Using vim and the likes is very much like playing the piano or driving a car. You’re always one step ahead of your actions because translating intent into operations is effortless as they are ingrained in muscle memories. I don’t even look at the cursor much of the time because it will be where I need it. I don’t care for mistakes because they are easily corrected.

Even then, I rarely use macros because they are at the high end of the power spectrum. Only writing your own commands is higher on the list. Easy macros are easy to create, powerful macros are created only when necessary and are worth the carefulness. I don’t think there’s nothing similar to named registers and emacs counters with multiple cursors solutions. Or the ability to have multiple macros ready to go at anytime (very useful for data cleanup).

One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressing). In emacs, you have the point, the mark, and the arguments (including the universal one) (the advanced ones are which modes are currently active). That’s mostly the internal state that matters when you think about an edit which changes A to B.

You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.

> there is "natural" or "intuitive"

Your argument is sound but this overstates your case a bit. There's a reason we don't type with our toes.

>Your "flow" is just habits, things you've taught yourself to do

By this logic a person who were comfortable with mouse should never grow to like VIM.

> there is no "natural" or "intuitive" way to operate a computer.

Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.

Geez, I’m not saying there are none. I’m saying it’s silly to characterise it as an editor for puzzle lovers. You knowing ‘quite a few people’ can’t be generalised to the millions that use vim daily.

The article discuses that specific subset of users who are into puzzle solving, so we should ground this discussion around that point and not fall into the “tool x is good/bad” pointless debate.

> By this logic a person who were comfortable with mouse should never grow to like VIM.

Quite the opposite, my argument is that habits are changeable.

> Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. That is a pretty poor interface.

You continue to argue for my point. OP was claiming that measured efficiency does not matter because it's about "flow". I argue that one can teach oneself to flow differently, the commands can be learned.