What Is Vim?

And they’re always frustratingly incomplete and/or buggy. Some motions will be unimplemented, or will behave incorrectly, especially with regards to boundaries around whitespace inclusion or exclusion in a motion. Things you added to Vim and got used to are unavailable, and so your ysa") to put parentheses around the string your cursor is on just doesn’t work. (Lack of vim-surround definitely gets me frequently.)

In VS Code, it maintains its own undo stack, and the interactions between the two undo stacks are terrible and terribly frustrating—yet doing without might be even worse, because they behave very differently.

And too often in a browser context, ^W will close your tab, losing data, rather then being inhibited and erasing the last word, as it should. That one is practically unforgivable in a Vim mode, yet common. That, more than anything else, will make me avoid a Vim mode.

This facet is typically not ported into other editors that have a Vim mode.

Vim runs natively inside virtual machines and containers, on resource-constrained embedded systems, and on remotely accessed machines.

Another aspect is that Vim can be operated entirely using a terminal emulator, and so can be running on a remote host to which the use only has a SSH or serial connection.

It should be said, though, that most implementations are simplified rewrites of Vim's core functionality. When you use a tool to achieve a sense of "flow", it can be grating for the editor to behave in subtly different ways from expectation, or discover an important feature does not work at all. Also, there tends to be limited, if any, support for Vim plugins.

In the modern era of Vim and NeoVim, it's possible for such tools to use the real version via network protocol, but integration is easier said than done. So far it's mostly been Vim GUI wrappers that leverage the capability rather than independent editors.

I still use Vim mode where I can even if it's a shadow of the real Vim experience. It makes life easier to use the same muscle memory on every shell, editor, and command-line, and not have to worry about learning every new app's idiosyncracies.

I think this is more intuitive than the "verb object" model Vim uses: if you get your selection wrong in Vim, you then need to undo the action and try again. In Helix, I can see what I am about to manipulate before I make the action.

I think at this point Vim wins out for being so ubiquitous, but I wish the Helix model took off first.

It's been 9 years since that challenge, and I'm still typing on the Filco keyboard. Good memories. Although I've since moved on to NeoVim for the LSPs. It's nice that I can freely edit files on any machine for something I picked up in a week.

Because Vi[m] is just one example of a keyboard-driven UI that has been adopted in other places, whereas in fact there's a more common one that's used by more people on more computers every day... but it's not widely known that it's a thing and it has a name.

It's IBM CUA.

https://en.wikipedia.org/wiki/IBM_Common_User_Access

It is what defines the keyboard interface of MS Windows, and tens of millions of skilled Windows users use parts of CUA every day, from Alt+F4 to close a window to Ctrl+S to save to Ctrl+F to find to F2 to edit.

For blind and visually impaired users it is the sole or primary UI for Windows.

It is also largely supported in multiple Linux and FOSS desktops, such as Xfce, Unity, LXDE, LXQt, MATE, and others.

Sadly, KDE does not implement much of it, and modern GNOME almost none of it.

But it's there and most Gtk desktop apps support some of it -- although Gtk4 is driving that out now.

CUA provides a whole set of consistent keyboard controls for DOS, Windows 3.x, 9x, NT, 2000-11, OS/2, and almost all the Linux desktops until GNOME 3 came along. It has editing keys but also far more.

A skilled person can drive all of a Windows computer, and all apps, as quickly as a skilled Vi[m] user can -- well, can edit text and nothing else.

Is it really a vim-mode, or a vi-mode? I mean, most of those are already very limited, but does any of them actually support vim-specific evolutions/changes?

And isn't the real question here: where does generic modal editing end, and when does vi(m) starts to display its specific personality?

Vim is succinct, in that what is needed often takes less commands than those less frequent.

Vim is pliable, in that can be made to do whatever you wish.

Vim is everything, vim is nothing.

Mastering vim is to find Zen made possible by an exponential command space.

imagine you what?

I live in Emacs for org, and vi for code edit. Happy mix these last 40+ years.

Sometimes it's hard to recall that ex exists, inside vi. But if you do any :command that's where you are. Inside a simpler editor landscape embedded in the visual world.

Ed is a sometimes tool. Always gratifying to use it!

If you're not convinced vimming is the best way to interact with your editor, you probably haven't seen a really proficient vimmer.

These two and "i" is all I remember about vi. Or is vi a different thing from vim and this model doesn't apply?

I never got into VIM before until I saw some Youtube personality using Lazyvim.

It may also be because the terminal view is much smaller than vscode's smaller navigation font so I can see much less of the file tree in a terminal program such as ranger.

I also never really mastered windows although I did master vim buffers.

I do use tmux.

Not Jupyter notebooks though (by default)

Something I've never learned. Not proud of it but I do not think I am missing anything either. I write native software for Linux for living at the moment.