[gen220]

From my perspective there are two sticky elements to vim, where once you’re accustomed to exploiting them, you find it very difficult to leave.

The first (chronologically speaking, for most people) is modal editing. Most popular editors today support vim bindings. So this bulwark is gradually eroding.

The second is the automation. Any piece of your workflow can be captured and remapped to a couple keystrokes.

Some other editor might innovate a new feature that vanilla vim doesn’t have (in fact this occurs regularly).

The (not unique in idea, but in implementation) power of vim is not any superficial feature, it’s the meta feature of extensibility, and how this is interwoven with the modal editor idea.

I think many people who come to vim and then leave it for another editor get the first idea, but never got used to the second idea, or never got around to integrating the two.

[greggman3]

> Any piece of your workflow can be captured and remapped to a couple keystrokes

How is different than recordable macros in 90% of the other editors out there? (vs programmable macros).

Can you give me an example you use regularly

[gen220]

Sure! One example is vim-dispatch, which provides a convenient interface for executing arbitrary shell commands asynchronously.

It works wonderfully with make, so you can run “make $file” in a couple strokes. I use this when writing markdown (to generate html with pandoc), editing test files, etc.

Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times. You could do the same thing with a regex sometimes, but for really complicated files this is easier.

A final, simpler one: I have <Leader>f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

But I think this example demonstrates how vim embodies UNIX ideas, as a modal text editor that depends on other binaries for complex behavior. People levy this as a complaint, that it doesn’t come feature complete, but it’s in reality a strength. Because while other editors wax and wane in terms of features and performance, vim only ever gets faster, as the binaries you depend on are swall out for better replacements every couple years.

[greggman3]

Unfortunately I'm not understanding what makes vim special here

> It works wonderfully with make, so you can run “make $file” in a couple strokes

I can do this in any editor I've ever used

> Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times.

I can do this in most editors I used (VSC being an exception). I use recordable macros all the time to clean up lines in emas or slickedit or any other editor that has recordable macros

> A final, simpler one: I have <Leader>f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

Can do this in every editor I've ever used too.

Any actual vim only examples?

[gen220]

To clarify, I don't think these (or any) features are "vim-only".

I was intending to say that it's the meta-feature of vim that vim-users find so sticky, that you can trivially write your own features: composing arbitrary executables and modal editing.

I think most editors nowadays are taking a page out of vim's book, by exposing increasingly lower-level interfaces to extension authors and users.

In these ways, I think editors are converging with vim, over time. Vim (and emacs) has been this way forever.

You don't have to wait for the editor-making company to accept that your strange request is valid, you can just hack it on yourself.

[greggman3]

I've had all those features in every editor I've used since the late 80s so no, no one is taking a page from vim or emacs.

[sergius]

And don't forget regex uses!