What Is Vim?
blog.jonas.foo
blog.jonas.foo
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.
The only vim mode I've met that wasn't infuriatingly incomplete was emacs evil mode.
I refer to this as the Vim Uncanny Valley
My favorite is all the applications which have a vim mode and are clearly done by people who think that just means making hjkl act like arrow keys and adding in a few single key commands. I wish more people would take the time to understand what modal editing actually is.
In a project of mine which has an editor that is pretty much vim with a few modifications to suit my purposes and slimmed down to just the needed features, I added an optional emacs mode which can be enabled with C-M-e M-S-m, it enables emacs in evil mode.
This then allowed me to golf a one line vim macro that shells out a selection to nc which connects to a clojure socket repl
I don't think many "vim modes" would allow that. The most earnest of vim modes is probably evil mode. Of course, only your true mortal enemy could ever understand you...
And quick integration with external tooling. Creating an extension for vscode is cumbersome.
In Vim I can have test and implementation side-by-side in tab0, and then two splits of the one file in tab1, a header file, impl and test in tab2, etc.
With another editor, I have to switch tabs in split 1, then switch tabs in split 2, rearranging or adding more splits as needed when moving between different groups of files.
Setting up custom hotkeys is an exercise in patience, and you are constantly fighting with native hotkeys that try to do the same thing.
I tried making vim mode work for years and I always go back to the original because it's where I'm at home
That’s because Vim has a more sophisticated undo stack than VS Code.
Vim keeps its history as a tree where you can jump between branches.
Look through https://github.com/VSCodeVim/Vim/issues?q=undo, there’s a lot. VSCodeVim tries to make it behave more like Vim, and because it’s independent of the native undo stack, it’s frequently a miserable experience. Pretty sure I disabled it, when I tried using VS Code for a short while and with Vim mode.
https://github.com/vscode-neovim/vscode-neovim
This yields a better experience than the old half baked VSCode vim emulation.
I am sure that with more configuration, the experience could be made more NeoVim like but I don't know whether I should spend time doing this or invest my time learning/adapting to a terminal based flow for the few tasks for which I am used to the VS Code GUI (browsing Git history, diffs for pull requests, git stash operations, debugging).
I started with a base config (kickstart.nvim) after trying out LazyVim sometime back, but kept going back to VS Code for some of the tasks. So what I have now is not significantly better but I like it.
1. https://marketplace.visualstudio.com/items?itemName=vscodevi...
However, when I tried VS Code vim mode, I found far better than Vrapper or Kate vim mode.
Have you tried evil-mode (Emacs VI Layer - E.V.I.L.), an implementation of the vim-bindings in Emacs? I've heard it works very well.
Or, at least, the Emacs subreddit seems to get a pretty steady flow of people who come from vim and get into Doom Emacs, which has evil-mode (and lots of other stuff) pre-configured and ready to go.
They seem very happy, from reading their reports, anyway.
Setting up Emacs from scratch is quite the project though if you want all the bells and whistles
Using Emacs with no bells and whistles just for writing is very enjoyable too, though! That's how I started. Within an hour or two I'd removed any visual clutter from the screen, and put on some dark theme (just clicking around the menu bar).
M-x help-with-tutorial (which came up when I first ran it, and I said oh, what's that), and that was me gone!
For weeks and weeks all I did was pump out text files with no formatting, being amazed that I could jump forward and backwards over words, sentences, and lines. It was an absolute joy, with a warm feeling of clarity and clean-ness to it.
I’ve heard someone say that Emacs with Evil is a better vim than vim. I’m inclined to agree.
"And they - vim implementations - are always frustratingly incomplete and/or buggy...
Except perhaps Emacs' evil-mode, with some users going so far as to claim that it's an even better implementation of vim-bindings than vim!"
:=D
P.S., off the back of your comment, I downloaded and started playing with Doom Emacs last night, as this thread reminded me of how great some people claim Doom and the vim bindings are. My Emacs has been stable for a while, with a basic enough configuration (only a thousand lines hah), so I'm in the mood for playing with some alternatives.
Being able to test very different configs now with "--init-directory" is really a nifty quality of life improvement which I had yet to fully appreciate!
I think Doom is a fantastic way to get started and know what's out there. I do suggest folks to eventually dive into building their own config. Having that much control over your work surface is where Emacs and its users can really shine, I think. It's a commitment though.
Sadly, because of the unchecked proliferation of apps added to the software enterprise, this is not really true. A "modern" software organization probably has something like: Notion, Gdocs, Paper, Slack, Figma, Jira, and Github. If they have vim mode at all, (most don't) they require learning entirely new UI patterns for each app - the sheer waste is astounding. I'd love to be able to say "I've got a professional editing environment set up that's highly efficient for me to write both code and prose. Can I, like, use my tools and edit text?". But the answer is always "No - we must scatter our thoughts as far and wide using as many tools as possible!" The lack of a workable vim mode makes the problem worse.
Confluence is especially stupid to me when everything happens on GitHub anyway, and most companies do GitOps in one form or another. We can literally colocate documentation next to the same code files it applies to, using a nice terminal friendly markup language. Most programming languages these days allow us to write Markdown documentation inline next to the declaration it applies to. But no, let’s use Atlassian’s bespoke proprietary Enterprise Offering of a rich text editor. Disgusting.
But hey, suits need to sell their enterprise software to somebody.
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.
Likewise, vim lets me do local editing on any system I connect to as there's rarely ever a Unix left that doesn't have vim installed. (Back when vim was the new kid on the block, I said the same thing about stock ex/vi - I made sure I was comfortable editing in vi, and then I never felt uncomfortable when I had to do work on a remote system.)
Another benefit with vim or nvim is how easy it is to copy someone else's full-featured setup: one of the programmers I work with is really into nvim, and he figured out an ideal setup for both working on Go and Python code. Then he just shared his setup with me. Copying someone's VSCode setup with plugins and all and getting it all to work would be a multi-hour ordeal.
- `blink.lua` (auto complete drop-down) - `dap.lua` (debugger) - `lsp.lua` (language server ruff and pyright setup)
https://github.com/samuellwn/myconfig
The relevant stuff is under "nvim". If you do a lot of Python development, the rest of his "myconfig" might be useful to you too.
Chrome and youtube also support some of the common vi/vim navigation keys.
After using both I settled on Nano years ago and still don't see how my workflow would improve with Vim.
To me nano is just a basic text editor (open, edit, save). Vim is a way to 'jack in' and be able to manipulate text with my mind. I don't 'think' anout how to accomplish something, I just think about what I want done and my hands just do it.
This comes from the modal nature of the editor and text objects, mostly, but there are so many other little things (like macros, ex commands, filters) that you pick up over time that all add up to a great text manipulation toolkit.
That said, editors are a personal thing. Pico was certainly a better choice for most people. In most cases, their needs are basic. Pico also displayed the relevant keyboard shortcuts on the bottom of the screen. Why would they want to complicate things, and vi would complicate things for people who did not have a need for a text editor outside of composing emails.
(source: vim user for twenty years, Emacs ten)
In spite of these so-called "flaws", I still prefer Emacs!
It's not as widely preinstalled, and has a poor editing language. If you can breathe with your mouth closed, you want something else.
And you don't have to suffer latency when working on machines with 300ms latency
I still use vim when I need to quickly edit some file on some remote host once, but for see no reason to use it over zed in other cases
Habitual adopters tend to jump from editor to editor, for myiad reasons. Entrenched users tend to dig in and try to learn their editor when they hit snags.
Vim amd Neovim are great for the entrenched type of user. There is so much depth to the editor, but it is not immediately obvious. Habitual adopters tend to discard Vim when a new editor gets a little traction.
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.
But the vi keybindings are directly from the LSI ADM 3A terminal, which is what Bill Joy wrote vi on.
It had overloaded hjkl for the arrow keys compared to it's predecessors like the 7700A and successor 3A+ that had dedicated arrow keys.
The fact that Home/~ were the same key thus ~ being your home directory and that esc was where the tab key is on modern keyboards explains a lot about the vi keybindings.
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.
I'm still stuck on neovim for now, but progressively I'll make my way to helix I think.
The typical vim model is a bit weird, but once I got practised with it it was actually quite surprising how much complicated stuff I could do purely by sight. But while the muscle memory aspect got me further than I'd have expected, it did only get me so far. Selecting the region first always seemed like it'd be the better way in general, being no worse when your fingers can do it automatically, while being better in the case where you're having to think about what you're doing.
You wouldn’t design English as the international language but that’s what it has evolved to be.
You can still learn Esperanto as a hobby but it’s not going to be as useful day to day as English.
But then I stopped abruptly when realized Helix misses a key feature of Vim: swap files. I can just start editing and have not have to worry about losing my work, may whichever of computer panic, computer running off charge, environment (desktop env or tmux) crash, etc. occur.
So edit semantics is cool, but fundamentals like recovery should be got right before being a serious contender.
(I did a quick search to see if there is any news on this front, but what I found is all about "recovery hooks for panic", which is far more less than what's needed - it's about an emergency saving of the work if something goes awry with the editor. I need to be protected from loss if something goes awry with the environment too...)
Perhaps helix has something similar?
Which one is more intuitive is probably subjective, but personally, I find "dip -> delete inside parenthesis" far more intuitive (and closer to my line of thinking) than "select inside parenthesis. delete selection".
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.
You end up the same with Vim eventually. After almost 13 years of using it, I sometimes have to actually type the things I do to articulate what command it is. I also had a moment where someone said, “it’s just like the ‘p’ command in normal mode” and I had to really think about what they meant—in my head I’m just like “put line” and it just happens.
and setting aside the "declarative" vs "imperative" nomenclature debate --
vim is pretty dang efficient. Typing `gg` to go to the beginning of a file, or `G` to go the end. Or all the other variety of motions. There are a lot.
Also, there is not necessarily any need to move the cursor anywhere. For example, if I'm in the middle of writing some string and I've decided to change the whole thing, `<ESC>ci"` does that, with no cursor movement required.
Now use / (+ n or N) + Enter to move around
Done
This even works as a motion (e.g. d / foo, then ctrl G until you hit the right foo, then enter to delete until there).
If you prefer to use a mouse you can do that in Vim too.
It even works over SSH.
I used to use vscode with mouse. Then vscode + vim with mouse. Then I forced myself to actually learn how to "properly" use vim, including all the motions plus enabling smart line numbers.
As a result, my right hand switches between keyboard and mouse much less than they used to, and I can do development work with my hands stay on the keyboard for minutes or longer. It made me more efficient, and RSI was much less of a problem.
imagine you what?
They mean
> imagine if you remove the functionality that Vim mode in VSCode gives you from Neovim.
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.
I always remap caps to ctrl because ctrl-[ is an acceptable escape key for me as I like to use other insert mode shortcuts. Eg ctrl-h, ctrl-m, ctrl-k etc.
I know some people map to escape/ctrl when held but that usually means installing something like Karabiner.
And even though you are probably used to your solution having the most important key in your program be a weird combo is not great imho. And you are missing out on bash/zsh/gdb and other command line vim modes.
I'm not at all, ctrl-[ is a terminal thing. It's available everywhere as are the the other ctrl shortcuts I mentioned.
I change mine to Ctrl. This way escape for me is Ctrl + [. Ctrl is too useful to be in an awkward position.
These two and "i" is all I remember about vi. Or is vi a different thing from vim and this model doesn't apply?
vim is vi "IMproved." Just a more featureful version.
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.
Don’t be intimidated by the huge feature set. I’ve been using it practically daily for 25 years and I still only use a small fraction of the available commands.
I have. Not my cup of tea. Small file I edit in nano / whatever else. Anything serious is remote editing using some IDE. The terminal I use also has SSH file browser where you can click on file and edit it locally using any editor. It will be saved back to where it came from.
How could you possibility know that unless you're familiar with Vim?
…but, I learned vi somewhere between less running on MSDOS and an embedded programming course at uni in the 90s.
I’ve used the those shortcuts in database clients, shells and web browsers, etc. ever since.
That’s a long time and a lot of value. It’s payed off so much that I don’t really remember if it was difficult to learn; I just use the keyboard and get the edits I want without much thought.
Being able to know something like that and bring it with you across operating systems has been useful.
I’m pretty sure it will still be useful in twenty years time.
I did not say it is not useful for people who use it. I imagine for them it gets the job done perfectly. We do not have to be all the same.
We most definitely do not need to all use the same tools for the job. Vive la différence.
https://danluu.com/productivity-velocity/
Is also funny to phrase it in terms of bottlenecks because bottleneck optimization is an 80/20 approach to performance. People who are serious about perf don’t practice it.
80/20 is good for once a month tasks. When it comes to the primary work I do everyday I don’t want to leave 20% on the table.
Even then, learning Vim could improve your computer interactions easily by 10%. That's 40 min a week or ~34 hours in a year.
In my personal life I try not to program. I do other things.
At the end of work I am so physically and mentally exhausted that I couldn't give two hoots whether I used Vim, VS Code, or the trendy modal AI-augmented editor written in Rust. I just want to get dinner, flop onto my bed, text some friends and get sleep. I have a couple of blog-posts that I've been sitting on for months because I haven't had the time nor energy to sit and write them, even at weekends.
Given all this, learning to use Vim is just another drag. Oh, and I should mention—I am exceptionally lazy. I'm not the so-called 'smart lazy' type of person. I'm lazier than that. I simply don't do stuff if I can afford not to.
The author suggests I now profile my own typing to speed it up? I frankly couldn't be bothered. I type reasonably fast anyway and Vim isn't going to speed things up at all.
Sorry, I was using the assumption you were looking to improve your craft and make great contributions.
;-)