> <i>There's a Vim mode in every single mainstream code editor out there.</i><p>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 <i>ysa")</i> to put parentheses around the string your cursor is on just doesn’t work. (Lack of vim-surround definitely gets me frequently.)<p>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 <i>might</i> be even worse, because they behave very differently.<p>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 <i>unforgivable</i> in a Vim mode, yet common. That, more than anything else, will make me avoid a Vim mode.
Vim is not only an editing language, but a fast-starting editor with a small-ish native executable, and small run-time memory use.<p>This facet is typically not ported into other editors that have a Vim mode.<p>Vim runs natively inside virtual machines and containers, on resource-constrained embedded systems, and on remotely accessed machines.<p>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.
Learning Vim early on had a high return on investment for this reason. Years later, I'm still able to benefit from the same muscle memory in modern tools, e.g. Obsidian.<p>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.<p>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.<p>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.
Helix uses a selection-first action model: you select the word/paragraph/whatever you want to perform an action on, then you change/delete/whatever on that selection.<p>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.<p>I think at this point Vim wins out for being so ubiquitous, but I wish the Helix model took off first.
Vim is this editor that a senior backend engineer told me to go try for a week, when I was still relatively junior. Like really try to remember all the shortcuts, not some half-assed attempt then laugh about not being able to remember <esc>:wq. If I were able to demonstrate fluent Vim skills at the end of the week, he'd gift me his TKL mechanical keyboard with a Vim keycap on the escape button.<p>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.
I think this is a classic example of Unix-induced tunnel vision.<p>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.<p>It's IBM CUA.<p><a href="https://en.wikipedia.org/wiki/IBM_Common_User_Access" rel="nofollow">https://en.wikipedia.org/wiki/IBM_Common_User_Access</a><p>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.<p>For blind and visually impaired users it is the sole or primary UI for Windows.<p>It is also largely supported in multiple Linux and FOSS desktops, such as Xfce, Unity, LXDE, LXQt, MATE, and others.<p>Sadly, KDE does not implement much of it, and modern GNOME almost none of it.<p>But it's there and most Gtk desktop apps support some of it -- although Gtk4 is driving that out now.<p>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.<p>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.
> There's a Vim mode in every single mainstream code editor out there.<p>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?<p>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 efficient, in that there is no need for one's hands to leave the keyboard.<p>Vim is succinct, in that what is needed often takes less commands than those less frequent.<p>Vim is pliable, in that can be made to do whatever you wish.<p>Vim is everything, vim is nothing.<p>Mastering vim is to find Zen made possible by an exponential command space.
I’ve yet to get sucked into Vim, though I’ve given it a shot on a few occasions. I just feel too much muscle memory with whatever you call normal editing. One of these days I want to really stick with it because I do love the verb/action/modifier idea. I’m even building a similar keyboard-driven editor for building UIs. It has commands like “s a i” (select all images), “a t n” (add text element as next sibling), etc.
Agree that Vim is a language to talk to your computer, but it's not necessarily efficient. Vim is famously an imperative editor: You have to tell Vim the sequence of steps to perform. Clicking your mouse on a position on the screen is declarative: You declare you want the cursor here. With Vim you have to imperatively walk the cursor to where you want to go, or god forbid use something like easymotion.
Even though I wince at mis remembered muscle memory using it, I still wish nvi had progressed a little further. I mostly turn off vim features. Default cut-paste with code indent is a giant mismatch. It's cruder, and itself a mishmash of non-joy code, but I found nvi suited me well for decades on netbsd and freebsd, and I use it still. I do run the port on osx but somehow each upgrade I find myself slipped back into vim. And on debian and the like.<p>I live in Emacs for org, and vi for code edit. Happy mix these last 40+ years.<p>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.<p>Ed is a sometimes tool. Always gratifying to use it!
I love this take. I was a die-hard Vim/Neovim zealot... but these days I absolutely love the ecosystem of tools that support normal mode. For so long hand-cramping emacs keybindings were sort-of-standard-in-a-few-places.<p>If you're not convinced vimming is the best way to interact with your editor, you probably haven't seen a really proficient vimmer.
I recently gave up on VSCode because the Vim mode is still substandard, missing keybindings, and constantly glitches out in new and fun (read: not-fun) ways. I’m just gonna use NeoVim and program the IDE myself, in a true moment of going super-saiyan as a programmer
How do you explain "w" and "wq" to save and quit the editor with "verb adjective object" model?<p>These two and "i" is all I remember about vi. Or is vi a different thing from vim and this model doesn't apply?
Is anyone here using Lazyvim? I switched to this from VS code and it feels much more productive and lightweight on my computer.<p>I never got into VIM before until I saw some Youtube personality using Lazyvim.
To me there was a distinct "aha" moment when the "vim language" suddenly made sense. Makes me think of when kids suddenly discover how to read.
I was in a PyCon presentation about the Python bytecode when I came up with the idea that vim editing commands are a bytecode for executing text manipulation.
I've been using vscode in java because of the cumbersome file navigation in bash. Is there easy full tree navigation in vim?<p>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.<p>I also never really mastered windows although I did master vim buffers.<p>I do use tmux.
My ode to why speed even matters <a href="https://h.43z.one/vimsteps/0" rel="nofollow">https://h.43z.one/vimsteps/0</a>
>"Wha Is Vim"<p>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.
Yet another article about vim that does not mention remapping Escape even though it's a dumb historical accident that the most important key is the furthest away from the home row.