Vim Language, Motions, and Modes Explained (2023)(ssp.sh)
ssp.sh
Vim Language, Motions, and Modes Explained (2023)
https://www.ssp.sh/blog/why-using-neovim-data-engineer-and-writer-2023/
103 comments
Yesterday, I used vim motions to clean up some JMH benchmark log data to a CSV. It was genuinely so useful to be able to precisely delete and replace based on regexes. I'm sure I could have done with a graphical find and replace, but it was definitely faster via vim, especially after recording macros to automate the repetitive edits.
Yes. So much this. I've also always loved combining that with the macro functionality.
Except: Yesterday, I used an LLM (4o-mini-high) to do this kind of task instead and i might never go back.
Except: Yesterday, I used an LLM (4o-mini-high) to do this kind of task instead and i might never go back.
I considered it, but there were hundreds of lines of data and I cba to verify all of them once they'd been through the LLM.
I mostly like Vim because it is available everywhere and in the terminal. In its default configuration it isn't the most powerful IDE, but it is vastly more powerful that any other default experience in any other text editor (IMO). It also makes it trivially easy to shell out to external tools for modifying the text, so even for a set up that isn't heavily riced you can still do a ton.
Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.
Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.
Helix and Kakoune motions seem to make more intuitive sense to me, but it's unfortunate that editor support in VSCode and Zed is quite poor. I am waiting on adopting Helix as my terminal editor until the motions become more universal.
I also try LunarVim and quite liked it, but for some reason the motions didn't click, perhaps it is just a matter of practice..
I also try LunarVim and quite liked it, but for some reason the motions didn't click, perhaps it is just a matter of practice..
The dudes in the https://ytch.xyz Programming channel display their vim editors with all kind of plugins that make me jealous. Pure fireworks. There is a plugin feature that enhances the line number where your cursor is located in the leftmost column for line numbers and looks super cool. I wish I knew the name of that plugin/feature since I don't want to go into the trial an error.
I also use the vim plugin for Eclipse and MS Code in my Linux boxes.
Yet, when the shit hits fan ... its vim-console time baby!
I also use the vim plugin for Eclipse and MS Code in my Linux boxes.
Yet, when the shit hits fan ... its vim-console time baby!
> There is a plugin feature that enhances the line number where your cursor is located in the leftmost column for line numbers and looks super cool.
You mean
You mean
:set relativenumberI just discovered the relative number after all this years counting lines to yank. OMG.
This guy I am talking has that feature up but the relative number in the gutter but also, as he scrolled up and down, the number showing the actual line number was a bit bigger and different color. Maybe he was using neovim? I don't like to highlight the whole line where my cursor is. Its too distracting. But if the cursor non-relative line number in the gutter was bigger or different color, it would be big difference.
I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings.
There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost. Yes, there is Ctrl+[ for single commands, but this is still an additional step compared to the key chord model of Emacs for instance.
There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost. Yes, there is Ctrl+[ for single commands, but this is still an additional step compared to the key chord model of Emacs for instance.
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point.
Take, for example, writing a for loop. I might type:
Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
Or say, I want to open a new line above and insert "xyz". Again, I think of it as a single operation in normal mode that includes the key sequence "shift+o x y z ESC".
This applies to all insert-mode operations for me. Normal mode feels like "home" and insert mode is just an editing phase I dip into when I need and exit. That's why it doesn't feel like I am constantly switching modes (even though I am).
Take, for example, writing a for loop. I might type:
for (int
Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
Or say, I want to open a new line above and insert "xyz". Again, I think of it as a single operation in normal mode that includes the key sequence "shift+o x y z ESC".
This applies to all insert-mode operations for me. Normal mode feels like "home" and insert mode is just an editing phase I dip into when I need and exit. That's why it doesn't feel like I am constantly switching modes (even though I am).
I think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice.
Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.
Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.
Indeed! Sometime between 2010 and 2015, I used to often work with Windows computers, so I wrote a tool for myself back then to remap Caps Lock to Esc on Windows machines:
https://github.com/susam/uncap
While it was certainly possible to do that by editing Windows registry (and I have noted those techniques too in the README), registry changes couldn't be enabled or disabled without a reboot. That's what motivated me to write the above tool. And indeed, having the Caps Lock work like Esc made using Vim a much better experience!
https://github.com/susam/uncap
While it was certainly possible to do that by editing Windows registry (and I have noted those techniques too in the README), registry changes couldn't be enabled or disabled without a reboot. That's what motivated me to write the above tool. And indeed, having the Caps Lock work like Esc made using Vim a much better experience!
I map 'jk' in Insert mode to <Esc>. In Insert mode, it takes me out to Normal mode. If I'm already in Normal mode, it simply moves down a line and right back up. This habit is so burned into my muscle memory that I often end up typing 'jk' into non-Vim input areas (like this HN comment box).jk
at most one y in way since Capslock is an unergonomic key in itself - it requires an unergonomic lateral movement of your weakest finger of your weaker hand
For a win, replace Caps Lock with Esc when tapped and with Control when held.
I’d recommend taking it even further and mapping capslock to escape when pressed by itself and CTRL when held in sequence with another key.
It never made any sense to me that people claim Emacs has no modes. What do you think you're doing when you hold down a modifier key? What else would it be except entering a mode in which other keys have a different meaning? Is that really different from vim's mode switching? They're just different ways of expressing modifiers.
> Because of that, I don't really treat insert mode as a separate "place" in my mind. Let's say I want to insert the text "abc". I don't think, enter insert mode, type "abc", then return to normal mode. I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
It is an action. Check out what happens if you prefix it with a repetition:
It is an action. Check out what happens if you prefix it with a repetition:
5iHello<esc>
HelloHelloHelloHelloHello
I used Vim for 5-ish years and I kinda got into that mindset, but on occasion I would fail to switch to insert mode (I think by not hitting the i or a key properly, but when in the flow I don't really pay attention to what my hands are doing) and stuff would go haywire. After 5 years of that happening intermittently I got really fed up with it and I started trying various alternatives.
I have been using Emacs for about 6 years now and when I fail to engage a modifier key properly all that happens is that I type some text in the active buffer. If I really manage to do a silly mistype, I can just hit C-h l to show my recent keystrokes to find out what I did.
I have been using Emacs for about 6 years now and when I fail to engage a modifier key properly all that happens is that I type some text in the active buffer. If I really manage to do a silly mistype, I can just hit C-h l to show my recent keystrokes to find out what I did.
I wonder if it would be possible to write some code to auto switch to insert mode if you press like 3 key in a very rapid succession, while in normal mode ?
> Take, for example, writing a for loop. I might type:
> for (int
> Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode.
I personally wouldn't but that's only because even in the case above I think in the same way as you mentioned next:
> I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
in the sense that I will ESC only after I have instered a "semantic-ish unit", which would include the variable name.
So I'd probably enter:
> for (int
> Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode.
I personally wouldn't but that's only because even in the case above I think in the same way as you mentioned next:
> I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
in the sense that I will ESC only after I have instered a "semantic-ish unit", which would include the variable name.
So I'd probably enter:
i for (int foo; foo < 42; foo++) ESC :?foo nnn cw
I don't think it's the keybindings in particular that people love about vim, you can rebind everything after all. I'm attached to vim keybindings in the same way I'm attached to qwerty keyboards - something had to be the default, it's fairly arbitrary, and there's very marginal benefits in switching to a different set of bindings.
It really is the modal editing style that's the main draw. Someone who edits frequently should find vim more convenient, not less, but it does require a lot of time to learn all the available commands and burn them into your muscle memory.
It really is the modal editing style that's the main draw. Someone who edits frequently should find vim more convenient, not less, but it does require a lot of time to learn all the available commands and burn them into your muscle memory.
Yes, the default. That's why, although I am french speaking, I switched a few years ago from azerty to qwerty keyboard just to be using the keyboard used by the people who programmed the default in editors like vim and emacs. Otherwise it is just a PITA. Should have done that from the very beginning I was programming. With Karabiner and Goku I have been able to configure some key combinations to get accented letters like righr alt+e for é, right shift+right alt+e for è, ...
I don’t know I edit a lot but I also really like vim motion. It gets really natural at some point. The mix of b and e to move around, using cw or ce to remove and start editing then getting back to moving around. Plus a lot of edit actually happens straight from normal mode (case correction, one character changes, short deletion).
You don’t really think about the modes because things flow naturally. It might also be due to the fact that I nearly never actually switch conscientiously into a mode. I always do actions which send me in insert (like c and o, very rarely I or A) and revert back to normal when done.
Plus vim has the advantage of making things like just remove everything between these symbols and set me in edit there very easy which is something I miss when I don’t have vim bindings.
You don’t really think about the modes because things flow naturally. It might also be due to the fact that I nearly never actually switch conscientiously into a mode. I always do actions which send me in insert (like c and o, very rarely I or A) and revert back to normal when done.
Plus vim has the advantage of making things like just remove everything between these symbols and set me in edit there very easy which is something I miss when I don’t have vim bindings.
> There are people like myself who edit frequently while writing (even with in a single sentence or word), so this switching between normal and insert modes to do chunks of each operation at a time incurs a heavy cost.
I edit this way too and there's no heavy cost here. Well, maybe when you're first learning and switching hasn't become second nature, but when you do it's not something you even notice.
I edit this way too and there's no heavy cost here. Well, maybe when you're first learning and switching hasn't become second nature, but when you do it's not something you even notice.
> who prefer these key bindings
Which ones? Do you mean the unergonomic defaults where one of the most popular action (quitting to normal mode) is bound to one of the most inconvenient keys (Esc)? Also for editing within a word you actually don't need to switch between modes, but instead could use something like a home row cursor with a modifier to move in insert mode.
Which ones? Do you mean the unergonomic defaults where one of the most popular action (quitting to normal mode) is bound to one of the most inconvenient keys (Esc)? Also for editing within a word you actually don't need to switch between modes, but instead could use something like a home row cursor with a modifier to move in insert mode.
Here come the "[..] anyway I'm happy with VSCode" comments
Technical moncultures are bad. The VSCode people ought to at least tolerate VSCode refuseniks as a kind of endangered species, worth keeping around out of a mixture of sentiment and insurance against memetic stagnation
I've grown up on vi and later emacs, but VSCode is no joke. It does almost everything, and most of it better, and more intuitively. There's no reason to torture yourself with counting characters, words or lines in order to get the delete command correct in one go.
The single most intuitive ah-ha moment I’ve had in Vi was the change verb. Change In <object>: ci( means “change the text within parentheses.” Change unTil <object>: ct& means “change the text until an ampersand.” And so on. It just makes sense.
VSCode never had moments like that for me. It’s fine, sure, but it wasn’t anything special.
VSCode never had moments like that for me. It’s fine, sure, but it wasn’t anything special.
You may love to learn then: Those aren't part of change.
"i(" is a selector (see ":help object-select"), and it also works with "y" or "d" or even in visual mode. Likewise "t" is a movement that can even be used on its own.
There's also a sibling to "i", "a", that includes the delimiter used, and "t" is a valid delimiter for HTML or XML tags.
"i(" is a selector (see ":help object-select"), and it also works with "y" or "d" or even in visual mode. Likewise "t" is a movement that can even be used on its own.
There's also a sibling to "i", "a", that includes the delimiter used, and "t" is a valid delimiter for HTML or XML tags.
No, it isn't, but that's perhaps the point: it's so direct. It rarely gets in the way. Sure, some things are easier done in emacs, but that's when you just copy the text to emacs, do your thing, and copy it back.
What VSCode isn't, is elegant. I think the OP likes that very much, and VSCode has forsaken that in favor of simplicity and a kind of free-for-all extension mechanism.
What VSCode isn't, is elegant. I think the OP likes that very much, and VSCode has forsaken that in favor of simplicity and a kind of free-for-all extension mechanism.
> There's no reason to torture yourself with counting characters, words or lines in order to get the delete command correct in one go
No one proficient in vim does this. Just use relative line line numbers or delete words in full with ciw.
No one proficient in vim does this. Just use relative line line numbers or delete words in full with ciw.
Vim feels equivalent to a horse carrier in comparison to vscode to a modern car.
To me, vscode feels like a huge truck with too small an engine, and vim feels like a sports car.
Also comes with all the downsides of a modern car (ads, random BS, blackboxes, etc...)
I feel like those trying to teach me Vim are the same who refused to learn to use VsCode.
Once configured, I can do the same than Vim. With more features.
Once configured, I can do the same than Vim. With more features.
I find VSCode to be sluggish and buggy, especially plugins, and also gave up on figuring out how to rebind jk to Esc. I also don't trust the telemetry flag, so I'd rather not open any proprietary projects in it.
It also can't run in a terminal, as far as I know.
It also can't run in a terminal, as far as I know.
> Once configured
is doing some heavy lifting here. "Once configured" vim can do the same you can do in VsCode. Editor wars are really the dumbest nerd fight.
is doing some heavy lifting here. "Once configured" vim can do the same you can do in VsCode. Editor wars are really the dumbest nerd fight.
Such a bad take as once configured Vim can do everything VSCode can and more.
You do you, but I'd be curious to hear what you think you can do in VS Code that you can't do in vim - what these "more features" are. Vim, and Neovim, have an expansive plugin culture. They are designed to be very configurable and customisable, so that the software fits around you and what you need to do. What features do you find missing?
Also, I get that you feel vim users are being a bit evangelical - "trying to teach", as you put it - but I can assure you that I, for one, have used VS Code plenty (including using vim keybindings), and it's just not very good for me. It doesn't fit me.
It's slow, it's not as configurable to my needs. I sometimes have nothing more than my iPad Pro (and magic keyboard), with me - I can mosh/ssh into a dev box, tmux up a session get to work easily, I never found a nice way to make VS Code work in this pattern.
What's the point in being a software engineer if you can't have software that fits you? Yes, vim has a learning curve, but then I get to make it my own and make it fit what I need. Same with tmux, my shell, and so on. In my experience, VS Code forced me a little more to fit to it rather than the other way around.
Like I say, you do you, but don't think all vim fans are talking from a place of ignorance.
Also, I get that you feel vim users are being a bit evangelical - "trying to teach", as you put it - but I can assure you that I, for one, have used VS Code plenty (including using vim keybindings), and it's just not very good for me. It doesn't fit me.
It's slow, it's not as configurable to my needs. I sometimes have nothing more than my iPad Pro (and magic keyboard), with me - I can mosh/ssh into a dev box, tmux up a session get to work easily, I never found a nice way to make VS Code work in this pattern.
What's the point in being a software engineer if you can't have software that fits you? Yes, vim has a learning curve, but then I get to make it my own and make it fit what I need. Same with tmux, my shell, and so on. In my experience, VS Code forced me a little more to fit to it rather than the other way around.
Like I say, you do you, but don't think all vim fans are talking from a place of ignorance.
don't forget to do a conversation class on speaking regex fluently.
It's funny to see Helix mentioned, without kakoune being mentioned.
Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support.
Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive.
Helix also has neat discoverability.. with pop-ups showing you what the available keybindings are.
Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support.
Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive.
Helix also has neat discoverability.. with pop-ups showing you what the available keybindings are.
I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare.
The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.
I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting.
I think this stems from a fundamental misunderstanding of the vi paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
In terms of navigating around a document, the only difference between "motion-action" and "action-motion" is that with "motion-action", the cursor is a selection which highlights the last motion. -- I don't really find that to be a significant difference in terms of navigating around.
Instead, I'd say the biggest difference between "action-motion" and "motion-action" is that the latter lets you iteratively/incrementally manipulate the selected text. -- Vim supports this with its Visual mode. -- I think the main case for this is along the lines of "it's easier to use EEE in helix, than count out & input 3E in vim".
I'd agree for basic/small edits, "action-motion" is more efficient.
I think of helix's multi-cursor functionality as a rocket-powered chainsaw, though. :o)
Instead, I'd say the biggest difference between "action-motion" and "motion-action" is that the latter lets you iteratively/incrementally manipulate the selected text. -- Vim supports this with its Visual mode. -- I think the main case for this is along the lines of "it's easier to use EEE in helix, than count out & input 3E in vim".
I'd agree for basic/small edits, "action-motion" is more efficient.
I think of helix's multi-cursor functionality as a rocket-powered chainsaw, though. :o)
As someone familiar with Helix, I’m curious. Could you elaborate on this?
Because I’m not disagreeing with your point, I’m actually not getting it in the first place. How does jumping around affect your selection count? Which motion(s) are you performing that larger quantities of text are getting "selected" in the first place?
Because I’m not disagreeing with your point, I’m actually not getting it in the first place. How does jumping around affect your selection count? Which motion(s) are you performing that larger quantities of text are getting "selected" in the first place?
I can’t speak for helix because I haven’t tried it, but I did spend a few weeks trying to get used to Kakoune before giving up and going back to vim.
The issue is that moving around would leave behind a trail of breadcrumbs. Sometimes these were visible cursors but other times they were invisible. Either way, I found myself being frequently surprised by the editor when it made changes I was not expecting.
Perhaps it’s something I could get used to with more time but it left me constantly perplexed and annoyed. I think ultimately what gets me is that in vim I can type a motion key and vim executes the motion and then returns to to a “null state” whereas with motion-action editors any time I key in a motion to jump somewhere I am now in the middle of the “motion-action” sequence and the editor is awaiting an action key to which it will eagerly respond. This to me feels very wrong, similar to the feeling I get when Siri is continuing to listen for more commands after invoking the command I asked for. Having to dismiss Siri all the time annoys the hell out of me.
Kakoune has a similar “dismiss key” which I remember pressing all the time out of habit, even when it was unnecessary, because the editor left me with this constant feeling of “unstable footing.”
The issue is that moving around would leave behind a trail of breadcrumbs. Sometimes these were visible cursors but other times they were invisible. Either way, I found myself being frequently surprised by the editor when it made changes I was not expecting.
Perhaps it’s something I could get used to with more time but it left me constantly perplexed and annoyed. I think ultimately what gets me is that in vim I can type a motion key and vim executes the motion and then returns to to a “null state” whereas with motion-action editors any time I key in a motion to jump somewhere I am now in the middle of the “motion-action” sequence and the editor is awaiting an action key to which it will eagerly respond. This to me feels very wrong, similar to the feeling I get when Siri is continuing to listen for more commands after invoking the command I asked for. Having to dismiss Siri all the time annoys the hell out of me.
Kakoune has a similar “dismiss key” which I remember pressing all the time out of habit, even when it was unnecessary, because the editor left me with this constant feeling of “unstable footing.”
I think kakoune invented motion action keybinds, but Helix is the one popularizing it.
I love helix because it is very fast, it supports everything it needs to, and the built-in help/which key. It's what I wish vim was.
Shameless self-promotion of a discussion thread I started.
https://github.com/helix-editor/helix/discussions/13399
I love helix because it is very fast, it supports everything it needs to, and the built-in help/which key. It's what I wish vim was.
Shameless self-promotion of a discussion thread I started.
https://github.com/helix-editor/helix/discussions/13399
I've been experimenting with Helix in the last month.
One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.
The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.
One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.
The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.
I found Helix much easier to get into than vim because you can see and experiment with the selection before committing to an action. It's also much more familiar to users of modern software (where you generally first select an object and then apply an action).
My problem with the "action motion" keybindings is textobjects that by necessity becomes more complex or even missing. This is a big step backwards in ny opinion.
There are also plugins that shows a pop-with with available keybindings if you want.
There are also plugins that shows a pop-with with available keybindings if you want.
Separate from the usually mentioned benefits of Vim, it cured my RSI completely.
This is such a big pro imo. Gone are those days when my hands/wrists used to be in pain from all the typing. Vim removed all that pain and made me look forward to typing as a fun activity. God bless Bram.
Ditto, I switched to vim after horrible pain from eMacs’s required multi finger contortions and it helped to the point rsi hasn’t been an issue for me for 20 years.
[deleted]
One thing I really appreciate about Vim is that it just opens. And I don't mean speed, I mean not getting bunch of pop-ups nagging me to do something about a configuration, extension, feedback or whatever.
I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.
I'm not going to claim Vim's defaults are usable for most people, but my god can these IDEs just shut up and let me see my code? I'll go to the settings if I want to.
Sorry Dave, you'll need to create a project, configure the SDK and log in with your GitHub credentials before I can let you edit README.md
> can these IDEs just shut up and let me see my code?
May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.
May I interest you in some Emacs? It’s arguably much more of an IDE than Vim, but it still “just opens”. And you can bring your muscle memory with you thanks to the Evil mode.
Yes, it’s super handy to be able to record an Emacs macro and modify large text within seconds, something that would take me half an hour. Yes, it’s super cool to navigate text at lightning speed.
But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge. These days devs using VS Code can be magnitudes more productive just because they focus on the things that matter.
Edit:
Don’t get me wrong. I love my (mechanical) keyboard. I hardly use the mouse. I have a shortcut for everything using Keyboard Maestro, Karabiner elements, and I use Emacs for text editing, and all of that makes me super fast using my computer. But all of that does not make you a better engineer (I am not an engineer anyway). So spending time on other qualities (being able to do research, to solve problems, to manage knowledge, to communicate well, to document well) is way more relevant for your success as an engineer.
But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge. These days devs using VS Code can be magnitudes more productive just because they focus on the things that matter.
Edit:
Don’t get me wrong. I love my (mechanical) keyboard. I hardly use the mouse. I have a shortcut for everything using Keyboard Maestro, Karabiner elements, and I use Emacs for text editing, and all of that makes me super fast using my computer. But all of that does not make you a better engineer (I am not an engineer anyway). So spending time on other qualities (being able to do research, to solve problems, to manage knowledge, to communicate well, to document well) is way more relevant for your success as an engineer.
Yes people who talk about vim being more efficient, are in my opinion, misguided. For me it's very little to do with efficiency, and much more to do with creating a more pleasant experience writing text, especially text with an exploitable structure (code).
I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.
I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.
> Because in the end navigating your text is not what determines engineering success. It’s convenient, yes, but that’s not the core challenge.
That's true, but it's still very helpful.
I'd argue that programming isn't the core challenge either, but it would be foolish to dismiss it entirely.
That's true, but it's still very helpful.
I'd argue that programming isn't the core challenge either, but it would be foolish to dismiss it entirely.
Vim is not about speed. It’s about efficiency (less effort) and programmability. You can do the same or more editing actions with other tools, but with Vim (and also Emacs), you can make it effortless.
I think an important part of the Vim workflow that I haven't seen mentioned is the fact that -at least for myself- it keeps the mind engaged during "menial" operations.
When switching from dealing with the information included in the text (typically thinking about code content) to operations of moving text around and other text logistics, I often find my mind "waiting" impatiently for my hands when using non-vim editors. In contrary, when using vim (I consider myself a mid-range user), I can somewhat remain closer to the flow.
At the same time, I still remember (albeit vaguely) a significant overhead of the Vim language before becoming acclimated.
When switching from dealing with the information included in the text (typically thinking about code content) to operations of moving text around and other text logistics, I often find my mind "waiting" impatiently for my hands when using non-vim editors. In contrary, when using vim (I consider myself a mid-range user), I can somewhat remain closer to the flow.
At the same time, I still remember (albeit vaguely) a significant overhead of the Vim language before becoming acclimated.
I don't understand why people say there is an overhead. Press 'I' for insert mode gives you the same behavior as non-vim, so your immediately at the same efficiency. What am I missing?
The overhead exists when a novice is trying to use Vim the way it is intended to be used in order to learn. Using insert mode to get the same behavior as non-vim and avoid normal mode is, in my opinion, bad learning practice.
I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in.
My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if I sat down to some online course I could learn a lot more about the Vim way of editing but I could never sit through one long enough to discover new things, so most of the things I learn about Vim come from me specifically looking up how to do certain things, not a bad way to learn, but I feel like I never got extremely proficient becasue I didn't go deep enough.
I find a lot of the keybinding to be unintuitive or not very ergonomic or inconsistent, but I also don't want to rebind anything because part of the reason vim is so useful is the fact that you get this tool with every linux install and changing things means you're no longer using The Vim. On the contrary it feels perfectly fine to tweak your IDE's keybindings because that IDE is already very specific to your needs.
My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if I sat down to some online course I could learn a lot more about the Vim way of editing but I could never sit through one long enough to discover new things, so most of the things I learn about Vim come from me specifically looking up how to do certain things, not a bad way to learn, but I feel like I never got extremely proficient becasue I didn't go deep enough.
I find a lot of the keybinding to be unintuitive or not very ergonomic or inconsistent, but I also don't want to rebind anything because part of the reason vim is so useful is the fact that you get this tool with every linux install and changing things means you're no longer using The Vim. On the contrary it feels perfectly fine to tweak your IDE's keybindings because that IDE is already very specific to your needs.
I don't think anyone claims vim motions are superior in absolutes with a straight face.
I like a nearby comment that essentially says "it's not superior for everyone, it's just infinitely better for me; also it doesn't magically make anyone 100x better than the next developer".
I've seen people using IDEs and flying around massive codebases at incredible speeds, all the while they're completely mystified by even the simplest vim editing.
Me? Put me in front of an IDE and painfully witness the absolute grind: I'm a sitting duck; but in Vim I feel like my brain is plugged straight into the computer: I don't even think about my hands, code is conjured just by thinking about it.
I like a nearby comment that essentially says "it's not superior for everyone, it's just infinitely better for me; also it doesn't magically make anyone 100x better than the next developer".
I've seen people using IDEs and flying around massive codebases at incredible speeds, all the while they're completely mystified by even the simplest vim editing.
Me? Put me in front of an IDE and painfully witness the absolute grind: I'm a sitting duck; but in Vim I feel like my brain is plugged straight into the computer: I don't even think about my hands, code is conjured just by thinking about it.
Yes, vim is not intuitive. It doesn’t teach itself to you. It takes hard work. I bought the O’Reilly vi/vim book [1] and read it cover to cover. I practiced a lot of things and was very deliberate about it.
To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!
I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.
I guess what I’m saying here is really just a restatement of “Worse is better” [2].
[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...
[2] https://en.wikipedia.org/wiki/Worse_is_better
To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!
I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.
I guess what I’m saying here is really just a restatement of “Worse is better” [2].
[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...
[2] https://en.wikipedia.org/wiki/Worse_is_better
This “worse is better” is very interesting. Are you suggesting vi/vim is an example of “the right thing”, vs a “New Jersey” style?
Yes, though that characterization is time-relative. I think vi would’ve been called “New Jersey Style” back at the time it was created, owing to its legacy as a minimal extension to ed for full screen interactive editing on a video terminal.
Today, the editing landscape is dominated by IDEs which have very basic (nearly minimum viable) editing functionality in support of getting the product out the door ASAP and letting plugins handle the fine details. This stands in marked contrast to a legacy tool like vim which gets editing right out of the box, allowing people to be productive even with a stock configuration (no plugins needed, though of course many are available).
We might call this an analogue of the Overton Window: the TRT vs WIB Window has shifted so far towards Worse is Better that we now consider UNIX an elegant tool. The old team at MIT must be really disappointed now!
Today, the editing landscape is dominated by IDEs which have very basic (nearly minimum viable) editing functionality in support of getting the product out the door ASAP and letting plugins handle the fine details. This stands in marked contrast to a legacy tool like vim which gets editing right out of the box, allowing people to be productive even with a stock configuration (no plugins needed, though of course many are available).
We might call this an analogue of the Overton Window: the TRT vs WIB Window has shifted so far towards Worse is Better that we now consider UNIX an elegant tool. The old team at MIT must be really disappointed now!
You can absolutely change the keybindings, vim is programmable.
Yes, but I meant that in the sense that when you change vim, it's no longer the vim that ships with Linux distros. It stops being the universal tool and starts becoming your custom text editor,and to me the biggest advantage of vim is how you're going to encounter it everywhere.
Doesn't everyone customise their editor(s), to a lesser or greater extent?
Okay, but that's true of anything? If you customize the shortcuts in an IDE, then you are also no longer running the defaults.
Exactly. See .vimrc.
I’ve been using vim-extensions on VSCode/ Zed/ SQL Editors for a few years now and always thought I had the best of both worlds with this setup. But after switching to Cursor it seems like simply hitting tab is a lot faster than performing a vim motion in most cases and so I don’t see why people would still need Vim in 10 years time.
You can integrate AI tools into Vim too if you want.
I'd wager that in 10 years people may have moved on way from Cursor while people will still thrive with (neo)vim.
I'd wager that in 10 years people may have moved on way from Cursor while people will still thrive with (neo)vim.
I like https://www.barbarianmeetscoding.com/wizards-use-vim/introdu... but it looks like it is not complete, unless I am mistaken
I have been using vim for 15 years. I disagree with the idea that it makes me more efficient than someone else. First, because I have friends who don't use vim and are very fast. Second because most of my time as a developer is not spent writing/editing text.
No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (having a vertical mouse already helped), but using vim and a tiling window manager allow me to drastically reduce my use of the mouse. It makes me more efficient than me when I use a less ergonomic setup, sure. But that's me.
It's all about ergonomics, and everyone is different. It's okay to be faster with a mouse or on an iPad.
No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (having a vertical mouse already helped), but using vim and a tiling window manager allow me to drastically reduce my use of the mouse. It makes me more efficient than me when I use a less ergonomic setup, sure. But that's me.
It's all about ergonomics, and everyone is different. It's okay to be faster with a mouse or on an iPad.
I use vim to avoid the mouse-keyboard back and forth. I also happen to edit multiple types of file, which I find useful to have / learn only 1 editor/IDE.
I am also often, if not always, in a terminal.
Some people use vim to brag, some say it's for speed, for me it's because "it's there".
I am also often, if not always, in a terminal.
Some people use vim to brag, some say it's for speed, for me it's because "it's there".
Do you modify your keyboard layout at all? I’ve tried Vim several times and many of the motions just feel awkward as hell for my fingers, but I’m on a standard wasd keyboard.
I have a qwerty keyboard also and all I have done to change my layout is remap caps lock to escape. Which is definitely vim relevant. I am a vim guy.
I don't. I like to keep it as close as possible to the defaults so that it just works everywhere. I don't want to have to import my vimrc whenever I SSH somewhere :-).
I am on a standard qwerty keyboard, nothing fancy here either!
And I almost don't use vim plugins: I enable syntax highlighting, relative line numbers and I add CtrlP as a plugin. That's all. Whenever I need more than that, I start an IDE (configured with the vim bindings of course :-)).
I am on a standard qwerty keyboard, nothing fancy here either!
And I almost don't use vim plugins: I enable syntax highlighting, relative line numbers and I add CtrlP as a plugin. That's all. Whenever I need more than that, I start an IDE (configured with the vim bindings of course :-)).
Vim is great. Several years ago I noticed the lack of books focused on the development experience, e.g. how to build an IDE-like experience in the era of language servers, and wrote a book about it[1]
A sad thing is that many people still believe that Vim is something mosty outdated and it’s hard to make it as useful as VS Code. But in fact it’s pretty much the opposite. I also think that the infamous steep curve is not so steep in reality.
[1] https://yanis-t.gumroad.com/l/vim4devs
A sad thing is that many people still believe that Vim is something mosty outdated and it’s hard to make it as useful as VS Code. But in fact it’s pretty much the opposite. I also think that the infamous steep curve is not so steep in reality.
[1] https://yanis-t.gumroad.com/l/vim4devs
I use vim & vim bindings for most editors I have (VS Code, Obsidian) and I think there's one thing always missed in this conversation (at least on HN): The changes that happens in your thinking when you start using a tool. Instead we get stuck on pros/cons of tool A vs tool B.
I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of discomfort. It was also around the same time I started to look in to QWERTY vs Colemak vs Dvorak, although I didn't go further with that, I quickly realized that the keyboard layout of my country (Sweden), while similar to US/UK QWERTY placed brackets in absolute garbage positions that caused strain in my right hand a lot. Then also the excessive pressing of left/right arrow + moving right hand between mouse & keyboard caused further strain.
Vim alleviated that with the word/Word/sentence navigation being more spread out, and "stick to home-row" philosophy.
But there was an additional "shift of thinking": editor as a (limited) programming language. Being able to store macros, navigate depending not just on line/character but chunks such as word & sentences made me realize I could do things such as:
"In this XML/URDF file, replace all elements with the name=X with the logic Y, which might including adding/removing xml elements/attribute"
without having to use some scripting (python + parsing etc). The process of figuring that out is also interactive. Try out a bunch of commands, stitch them together as "macros" and then make macros that calls macros that use copy-paste registry.
If I stuck with Sublime, or VS Code, I don't think I would've had that epiphany. It even helped me (non-CS guy) to understand programming better.
I got in to vim in college for two reasons (the real) one was just that I wanted to look cool, and the second one was to relive my hands of discomfort. It was also around the same time I started to look in to QWERTY vs Colemak vs Dvorak, although I didn't go further with that, I quickly realized that the keyboard layout of my country (Sweden), while similar to US/UK QWERTY placed brackets in absolute garbage positions that caused strain in my right hand a lot. Then also the excessive pressing of left/right arrow + moving right hand between mouse & keyboard caused further strain.
Vim alleviated that with the word/Word/sentence navigation being more spread out, and "stick to home-row" philosophy.
But there was an additional "shift of thinking": editor as a (limited) programming language. Being able to store macros, navigate depending not just on line/character but chunks such as word & sentences made me realize I could do things such as:
"In this XML/URDF file, replace all elements with the name=X with the logic Y, which might including adding/removing xml elements/attribute"
without having to use some scripting (python + parsing etc). The process of figuring that out is also interactive. Try out a bunch of commands, stitch them together as "macros" and then make macros that calls macros that use copy-paste registry.
If I stuck with Sublime, or VS Code, I don't think I would've had that epiphany. It even helped me (non-CS guy) to understand programming better.
Are you using qwerty still?
I'm still using QWERTY yes, but I use US/UK keyboard layout for coding, and others for writing messages (SWE/JP for me).
I realized that it didn't make much sense when I already have 3 QWERTY mappings in my head, and moving all of those 3 mappings to Dvorak / Colemak when those two are based on ergonomics pattern of the English language, when I type in 3 languages.
I realized that it didn't make much sense when I already have 3 QWERTY mappings in my head, and moving all of those 3 mappings to Dvorak / Colemak when those two are based on ergonomics pattern of the English language, when I type in 3 languages.
FWIW I also used the Swedish/English split before I completely changed my layout on a split keyboard. (I still use both US and SWE layout on laptops though.)
Is not vim a tool from an age of very much different terminals to what we have today, with different limitations that are no longer actual?
Yearly(!) emergence of new tutorials trying to finally explain how to navigate with vim is a consequence of this disconnect.
Yearly(!) emergence of new tutorials trying to finally explain how to navigate with vim is a consequence of this disconnect.
Well vim comes from a different age, but it is still completely viable today.
Because you can have a GUI and a mouse today does not mean that you should not use the vim bindings. I use vim a lot in terminal (both locally or over SSH), but I also use vim bindings in graphical IDEs. Actually, I struggle if the editor doesn't have vim bindings. VScode, IntelliJ, even Xcode has vim bindings.
Because you can have a GUI and a mouse today does not mean that you should not use the vim bindings. I use vim a lot in terminal (both locally or over SSH), but I also use vim bindings in graphical IDEs. Actually, I struggle if the editor doesn't have vim bindings. VScode, IntelliJ, even Xcode has vim bindings.
Funny enough, I believe that there are quite a lot of tutorials and that itself is the issue. Everyone wants to make their own since they deem the others to be bad and then a new subpar tutorial is created, making it even more difficult to find the few helpful articles. This ends up becoming a vicious cycle.
In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.
In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.
Badly titled post. "Vim Language" is usually used in reference to the "VimL" scripting engine inside Vim.
One of the problems is that vim is so entrenched with the QWERTY layout that any shortcut is too cumbersome in colemak
I've used colemak and vim (well kakoune nowadays) for over a decade. The only change I've needed is changing : to ,
... or dvorak.
I am actually trying to make a site that allows users to learn vim commands by trying to beat a bot! It’s currently half baked at the moment but live at:
https://vimgolf.ai
Feel free to give it a try. Might motivate me to finish it!
https://vimgolf.ai
Feel free to give it a try. Might motivate me to finish it!
I wonder if learning Vim is similar to learning a musical instrument - where the real benefit isn't just speed, but the way it changes how you think about text editing?
Even if you bounce off of Vim or modern implementations like Nvim, it's worth learning the bindings. Once you get used to them, you will never go back.
[deleted]