Vim is touch-typing on steroids(trickster.dev)
trickster.dev
Vim is touch-typing on steroids
https://www.trickster.dev/post/vim-is-touch-typing-on-steroids/
190 comments
For some (myself included) the high speed and efficiency of proficient modal editing serves as a thinking aid, like sketching with a pencil and eraser. I tend "play" with the code: chopping it up; splitting lines and inserting a bunch of white space; duplicating lines dozens of times to act as placeholder values (e.g filling an array literal); renaming variables across a file many many times before settling on the right name; moving helpers functions to the top, then to the middle, then next to their first invocation etc.... All doable with other editing styles, but at a higher cost, and the cost of manipulation has to be very low in order to reap those meditative qualities.
Manipulation far outweighs input. And manipulation is fundamentally thinking, at least for me.
Manipulation far outweighs input. And manipulation is fundamentally thinking, at least for me.
Personally, when I find myself doing the things you mention, I realize it's time to back off and refocus on the things mentioned in p-e-w's second paragraph. In that state, I feel I am fidgeting with the code, and it is probably because some unresolved issue is blocking me.
This is a great point that I never thought of. Seems like a general example of the idea that lowering the cost of some action sufficiently low can lead to not just efficiency gains in areas where that action is currently used, but also new and surprising uses of that action.
For example, I once read an economics book that characterized computers as lowering the cost of integer arithmetic by an extreme amount. That led to things like digital music/pictures - no-one would have previously thought of using a ton of numbers to represent a song - not just efficiency gains in accounting.
For example, I once read an economics book that characterized computers as lowering the cost of integer arithmetic by an extreme amount. That led to things like digital music/pictures - no-one would have previously thought of using a ton of numbers to represent a song - not just efficiency gains in accounting.
> no-one would have previously thought of using a ton of numbers to represent a song
Music has long been represented using math and math concepts. Musical notation is a cartesian plane with time on the x-axis and pitch on the y. But that's the representation, and it's not about the representation, it's the ability to manipulate at extremely high speed.
Music has long been represented using math and math concepts. Musical notation is a cartesian plane with time on the x-axis and pitch on the y. But that's the representation, and it's not about the representation, it's the ability to manipulate at extremely high speed.
I see what you're saying, but musical notation isn't a precise representation of the audio. Given the same score, two musicians can produce very different interpretations. Perhaps I should have said 'audio' instead of 'song'. (I took classical piano exams as a kid, and at some point a group of us would perform our prepared pieces for each other as practice, and I remember always being surprised at how different everyone's pieces sounded. I'd thought mine was the One True Way!)
Claude Shannon showed that everything is just data, that's why it wasn't done previously. It seems obvious today, but wasn't always.
All of that can be done in JetBrains' IDEs with a single hotkey. Especially stuff like code extraction or variable/class/function renaming — it actually works reliably across the whole project (not just a couple of files) even if you have multiple functions with the same name. Extracting code to variables/constants/functions also works reliably (like automatically adding referenced data as function arguments).
Yes, but does it work the same way in Shell scripts, Ada, Haskell, Perl, Python, C#, screenwriting, and documentation?
The power of text-based manipulation is that you don't have to learn a different set of hotkeys for different types of material.
The power of text-based manipulation is that you don't have to learn a different set of hotkeys for different types of material.
Yes, and also in CSS, SQL, ocaml, Rust, and a million other languages. Navigation works reliably (including cross-language navigation: for example, you can easily jump from a CSS class mentioned in HTML or JSX to its definition even if it's has a very generic name and is defined in a random file far away). Even if it has a complicated definition using something like SCSS and is simply not greppable.
Or do the reverse — find all usages of a CSS class from its definition (again: do so reliably, it's not a simple grep).
Find all references to a particular database column (in SQL queries across the project, foreign keys in other database tables, and ORM models)? Same hotkey.
Stuff like code selection works reliably since IDE work with code on an AST level and you're asking it to select the current AST node (and not the "current text block"), going up the tree as needed.
And so on.
Or do the reverse — find all usages of a CSS class from its definition (again: do so reliably, it's not a simple grep).
Find all references to a particular database column (in SQL queries across the project, foreign keys in other database tables, and ORM models)? Same hotkey.
Stuff like code selection works reliably since IDE work with code on an AST level and you're asking it to select the current AST node (and not the "current text block"), going up the tree as needed.
And so on.
> The power of text-based manipulation is that you don't have to learn a different set of hotkeys for different types of material.
And the weakness of text-based manipulation is that it views code as characters rather than as semantic data.
Modern IDEs either have their own semantic code operations, or use language servers to actually understand the code rather than just work with character strings. This is vastly more reliable when doing refactoring or project-wide navigation. Text-based approaches are a crude hack by comparison.
And the weakness of text-based manipulation is that it views code as characters rather than as semantic data.
Modern IDEs either have their own semantic code operations, or use language servers to actually understand the code rather than just work with character strings. This is vastly more reliable when doing refactoring or project-wide navigation. Text-based approaches are a crude hack by comparison.
In Vim you also have plugins that provide you with semantic editing (e.g. via LSPs). You then have it both.. same as if you installed a Vim plugin in your IDE. The only difference being that the IDE is slow and has a multitude of features that I don't need whereas Vim is configured to exactly my needs and has instant response always.
Would you say that a vim plugin in your IDE of choice gives you the best of both worlds? The superior semantic manipulation of an IDE and the superior text manipulation of vim.
IDEs are incredibly slow. Even the fastest IDEs.
IntelliJ (the canonical JetBrains IDE) has plugins for the first 6 of those - so at least for those, it does work the same way. The hotkeys to perform the actions mentioned in the parent comment don't change.
TIL! There weren't so many language plugins last time I tried it, so I felt like I had to drop back into Emacs/Evil fairly often. Good to know that's not as much the case anymore!
I tend to use Vim/NeoVim regularly, and I really enjoy using IdeaVim when I use JetBrains' products. I get the fast modal editing and the IDE refactoring features. It's the best of both worlds.
Great point, /SEARCH_TERM and n is extremely useful for finding stuff and understanding. also when you screw up either because muscle memory went haywire or the logic looks bad then just uuuuu until the status bar (plugin) show no change since last save.
As opposed to other editors, which don't have shortcuts for search and undo?
Ctrl/CMD + Z vs u
Ctrl/CMD + Y vs r
There’s a significant difference in speed. But more importantly, the former requires RSI inducing finger gymnastics, whereas the latter is a tap of a fingertip.
The much faster speed but more importantly less complicated chords/key taps in VIM, leads to a qualitatively different editing/reading experience.
Ctrl/CMD + Y vs r
There’s a significant difference in speed. But more importantly, the former requires RSI inducing finger gymnastics, whereas the latter is a tap of a fingertip.
The much faster speed but more importantly less complicated chords/key taps in VIM, leads to a qualitatively different editing/reading experience.
If your goal is to return to the state where you opened the file ":earlier 10m" might be more useful than spamming u.
totally agree. Also, when developing in complex codebases, being able to shorten the time distance between thinking an action needs to be done and actually doing it means you can keep more ideas in your head rather than spend your CPU cycles on visually moving around your screen, clicking, waiting, etc.
I love vim. I've been using it for almost 20 years now.
I agree with you about code entry speed, that's not the point.
I think the easiest way to put it is that vim is 0% task loading. I never have to expend any energy dealing with it, making it do something I want, finding some button that moved around, etc. Vim just works: in almost two decades, I have never once encountered a single bug or change in behavior that I found irritating. Seriously, never. I just write code.
99% of the code I have written both personally and professionally in my lifetime was written in vim. That's the other win for me: all that muscle memory is still beneficial, now and forever. Its a much more universal tool than any IDE.
I agree with you about code entry speed, that's not the point.
I think the easiest way to put it is that vim is 0% task loading. I never have to expend any energy dealing with it, making it do something I want, finding some button that moved around, etc. Vim just works: in almost two decades, I have never once encountered a single bug or change in behavior that I found irritating. Seriously, never. I just write code.
99% of the code I have written both personally and professionally in my lifetime was written in vim. That's the other win for me: all that muscle memory is still beneficial, now and forever. Its a much more universal tool than any IDE.
> Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it.
I am very bad at keeping all that stuff in my head at once. I need to get things out of my head onto the screen as fast as possible, so that I can then think about the "next step". Then I need to be able to quickly refer back to many places quickly and switch back and forth between different places in the codebase.
For example, as soon as I think of a corner case, I'll try to handle it immediately in an if statement or something. Then it's there, in the code. Maybe it stays in the final version, maybe I end up with 10 if statements and need to refactor everything.
But it's much easier for me to do that when everything is written down in the code rather than trying to do it all in my head.
If I typed at 15 WPM, I'd probably be easier to just reason about it in my head, because by the time I finished typing, I would have forgotten what I was thinking about.
I'm sure these things cause a feedback loop of sorts. Because I know I can get stuff out of my head quickly, I don't bother training myself to get better at storing more in my head at once. So I get worse and the solution is just to edit text faster.
Similarly, I suspect since you can keep everything in your head, there's no incentive to get faster at editing text. And if a problem is "harder" the solution is to get better at keeping stuff in your head.
I don't think there is a right or wrong answer. I think exposing people to both sides is important, so they can find what works for them.
I am very bad at keeping all that stuff in my head at once. I need to get things out of my head onto the screen as fast as possible, so that I can then think about the "next step". Then I need to be able to quickly refer back to many places quickly and switch back and forth between different places in the codebase.
For example, as soon as I think of a corner case, I'll try to handle it immediately in an if statement or something. Then it's there, in the code. Maybe it stays in the final version, maybe I end up with 10 if statements and need to refactor everything.
But it's much easier for me to do that when everything is written down in the code rather than trying to do it all in my head.
If I typed at 15 WPM, I'd probably be easier to just reason about it in my head, because by the time I finished typing, I would have forgotten what I was thinking about.
I'm sure these things cause a feedback loop of sorts. Because I know I can get stuff out of my head quickly, I don't bother training myself to get better at storing more in my head at once. So I get worse and the solution is just to edit text faster.
Similarly, I suspect since you can keep everything in your head, there's no incentive to get faster at editing text. And if a problem is "harder" the solution is to get better at keeping stuff in your head.
I don't think there is a right or wrong answer. I think exposing people to both sides is important, so they can find what works for them.
> Simply put, text manipulation is not at all a productivity bottleneck for me
I once believed this and this comment could have been written by me verbatim. But I decided to seriously give vim a try and I'm still very happy 8 years later. I don't know for sure that vim makes me a better programmer, but going from vim to another editor is a bit like going from your large desktop screen to a 13" laptop working at a café. I can do the work but it's just slower and not as enjoyable.
Maybe it's not so much vim specifically, although I enjoy the modal editing part, but just 100% investing in a single editor and getting really good at navigating and editing code with it. It's always fast and responsive and always available. Before vim I used different editors for different jobs, Emacs, BlueJ, Eclipse, Visual Studio, Sublime, XCode etc and I never truly invested in any of them. Once you make a decision to just use the one editor, it's a powerful thing.
I once believed this and this comment could have been written by me verbatim. But I decided to seriously give vim a try and I'm still very happy 8 years later. I don't know for sure that vim makes me a better programmer, but going from vim to another editor is a bit like going from your large desktop screen to a 13" laptop working at a café. I can do the work but it's just slower and not as enjoyable.
Maybe it's not so much vim specifically, although I enjoy the modal editing part, but just 100% investing in a single editor and getting really good at navigating and editing code with it. It's always fast and responsive and always available. Before vim I used different editors for different jobs, Emacs, BlueJ, Eclipse, Visual Studio, Sublime, XCode etc and I never truly invested in any of them. Once you make a decision to just use the one editor, it's a powerful thing.
I think it's rarely a productivity bottleneck, but that doesn't mean that Vim keybindings and navigation aren't superior in the vast majority of cases to what most people are doing - which is scrolling, mousing about, etc. Vim keybindings significantly accelerate the editing and browsing of existing code in-editor.
It also has the convenience of being a fairly common set of keybindings in editors nowadays, as many have an extension that gives Vim keybindings without having to go all-in on a CLI-style Vim editor.
It also has the convenience of being a fairly common set of keybindings in editors nowadays, as many have an extension that gives Vim keybindings without having to go all-in on a CLI-style Vim editor.
Every modern code editor has character-, word-, subword-, line-, and page-based navigation, as well as "jump to symbol" functionality. Bookmarks, paragraph navigation, and similar are also very common.
I fail to see how Vim is supposed to be superior to that. It has essentially the same navigation features, with different keybindings. And the idea that those different keybindings are somehow "better" is a big [citation needed].
I fail to see how Vim is supposed to be superior to that. It has essentially the same navigation features, with different keybindings. And the idea that those different keybindings are somehow "better" is a big [citation needed].
Not a scientific source, but there's probably a reason behind the popularity of evil mode for emacs, and vim plugins for just about anything (yes I know emacs is often the default, but that's for practical reasons like Ctrl+a/e is easier to add than 0/$).
My pinkies love me ever since I started using vim. For me it's not the specific keybindings, but the modal editing allow more uses for the same keys depending on context and less need for modifiers.
My pinkies love me ever since I started using vim. For me it's not the specific keybindings, but the modal editing allow more uses for the same keys depending on context and less need for modifiers.
How common are the keybindings used in existing editors? I must admit I haven't ever really noticed the hotkeys/keybindings in editors - until I started using Vim bindings instead. There's likely a large crossover between people who use a lot of hotkeys and people who look into learning something like Vim. If they change often across editors, it wouldn't surprise me that they aren't often used, so don't get much evangelism compared to Vim (which has been more or less the same for decades)
I only use a small subset of Vim's shortcuts - but most text editors I've used I'd imagine don't have the breadth Vim does (or they do a really poor job of documenting it). Can you point out a doc page for some IDE with similar navigation capabilities to Vim?
I only use a small subset of Vim's shortcuts - but most text editors I've used I'd imagine don't have the breadth Vim does (or they do a really poor job of documenting it). Can you point out a doc page for some IDE with similar navigation capabilities to Vim?
> How common are the keybindings used in existing editors?
The whole point of widget toolkits is that the keybindings for input fields are the same everywhere. I use Linux and almost exclusively run GTK-based apps, and every text input across the whole system behaves the exact same way, with consistent keybindings for navigation, undo/redo, copy+paste etc. This is how good UI should work.
Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.
The whole point of widget toolkits is that the keybindings for input fields are the same everywhere. I use Linux and almost exclusively run GTK-based apps, and every text input across the whole system behaves the exact same way, with consistent keybindings for navigation, undo/redo, copy+paste etc. This is how good UI should work.
Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.
> Platform conventions are important, and it's the job of individual programs to adapt to them – not the other way round. Vim fails big time in this regard. Can you make Firefox's form inputs use Vim keybindings? If not, there's your inconsistency already.
I disagree with that. And the world doesn't have to be perfect.
If you use Vim and you like it (it takes LOT of effort), you will adapt the platform to the Vim ways whenever possible. Everytime I encounter something I cannot vim-ize, I'm pissed but I have to put up with it. It's like working with Windows.
For the browser, you can use Vim binding for navigation, and edit with Vim. But again, this is not mandatory per se to benefit from Vim as a developer.
I disagree with that. And the world doesn't have to be perfect.
If you use Vim and you like it (it takes LOT of effort), you will adapt the platform to the Vim ways whenever possible. Everytime I encounter something I cannot vim-ize, I'm pissed but I have to put up with it. It's like working with Windows.
For the browser, you can use Vim binding for navigation, and edit with Vim. But again, this is not mandatory per se to benefit from Vim as a developer.
> Can you make Firefox's form inputs use Vim keybindings?
Do you mean something like this: https://github.com/glacambre/firenvim?
Do you mean something like this: https://github.com/glacambre/firenvim?
Yes, but I mean without an ugly hack that involves spawning a process every time you want to edit a browser text field.
"Yes, but ..." is a great way to move your goalposts.
On another note, do you expect your hotkeys from your Office program to work in a Firefox form field?
On another note, do you expect your hotkeys from your Office program to work in a Firefox form field?
It's not an ugly hack, it's about not reinventing the wheel. Pure js solutions also exist but they're a subset of the features, and using native vim gives you the benefits of plugins you already have on the system.
It's a feature, and it follows the unix philosophy. But I get that not everyone needs or wants it.
It's a feature, and it follows the unix philosophy. But I get that not everyone needs or wants it.
[deleted]
> There's likely a large crossover between people who use a lot of hotkeys and people who look into learning something like Vim.
Please no. My keyboards have cursor keys. I really appreciate the freedom not to have to remember if I am in insert mode or in edit mode.
And yes, many of my shortcuts involve the cursor keys and the rest of the extended keyboard keys. Also, the function keys. These keys exist for a reason.
Please no. My keyboards have cursor keys. I really appreciate the freedom not to have to remember if I am in insert mode or in edit mode.
And yes, many of my shortcuts involve the cursor keys and the rest of the extended keyboard keys. Also, the function keys. These keys exist for a reason.
I think the reason is that in VIM, you either learn the shortcuts or you just can't do anything.
In other editors, you can learn the shortcuts, or you can just monkey around.
But it is true, and I agree, that learning how to use YOUR editor gives great dividends.
In my case, my editor is Sublime Text. I have extensions and configurations I really need, because now I am used to them. Yes, I know the commands to navigate by word, line, block of code, or even use the right side minimap (with git colors for new and edited code) to move faster through the code.
Also: some users, even here in HN, underappreciate the mouse. But every single ex-StarCraft player knows that mouse+keyboard can be ridiculously fast when being used by trained hands.
At least for me, I can select and move, or reindent, or whatever, a chunk of code much faster with the mouse than having to know how many lines it is and then typing the equivalent command.
So yes, learn touch typing, and learn how to use your editor. It matters. What doesn't matter is if your editor is vim or not.
In other editors, you can learn the shortcuts, or you can just monkey around.
But it is true, and I agree, that learning how to use YOUR editor gives great dividends.
In my case, my editor is Sublime Text. I have extensions and configurations I really need, because now I am used to them. Yes, I know the commands to navigate by word, line, block of code, or even use the right side minimap (with git colors for new and edited code) to move faster through the code.
Also: some users, even here in HN, underappreciate the mouse. But every single ex-StarCraft player knows that mouse+keyboard can be ridiculously fast when being used by trained hands.
At least for me, I can select and move, or reindent, or whatever, a chunk of code much faster with the mouse than having to know how many lines it is and then typing the equivalent command.
So yes, learn touch typing, and learn how to use your editor. It matters. What doesn't matter is if your editor is vim or not.
You aren't wrong... But the base vim keybindings and modal nature make navigation extremely efficient instead of chorded keystrokes. Then, most editors(vscode, jetbrains) have decent vim binding support via plugins. Now, you're 80% efficient since muscle memory kicks in and you can just focus on the code better
All of those keybindings are not composable, vim is. you can find with a shortcut, but vim can “dtr” to delete all text up to r. or maybe you want to delete 3 lines, 3dd will do that. Once you recognize vim is like a language for editing, you’ll get it.
vim has had these keybindings/controls as primary features for decades, and people that have these in their muscle memory the benefits have accrued over a long time and a number of different platforms.
It sometimes seems like a lot of the Vim, ew crowd think that the sole reason for using Vim is gaining some kind of god-like ability to physically pump out and manipulate characters. Sure, maybe that's possible. For me, it's about being efficient with my keystrokes. Standard shortcuts (Ctrl+_) are pretty unpleasant for my hands - saying this having already mapped CAPS_LOCK to LEFT_CONTROL (and LEFT_CONTROL to ENTER). I like running commands using sequences of letters - it just feels physically easier to me than sequences of multi-key-presses (e.g. Ctrl+Shift+T). That Vim has other smarts around that is just a perk.
Editing text using Vim, once you've built the muscle memory, really feels super natural and effortless. I really hate reaching for the mouse; it just irks me in a way that's hard to describe. Similarly, editing code without Vim feels tedious in a similar way. Imagine scrolling a long article by pressing the down arrow over and over, or clicking the down button at the bottom of the scroll bar.
Another complaint I see is that remembering the commands is too hard an ask. I moved from QWERTY to Workman at the same time that I was learning Vim and it was interesting because I learned that I -- and probably most people, but I'm speculating -- don't associate commands or actions with letters after they're initially learned. It's all muscle memory, just particular movements of select fingers. The Vim stuff you use day-in-day-out just sticks in your brain and you don't think about anymore than you think about which fingers to activate to type words.
Of course, some people probably just prefer to edit text like they do in almost all other text-editing contexts. They can already edit text; without some kind of perceived extra value, there's no motivation to change, or seemingly even try to understand an alternative. For me, it's the pleasure of feeling efficient and doing dev pain-free.
Editing text using Vim, once you've built the muscle memory, really feels super natural and effortless. I really hate reaching for the mouse; it just irks me in a way that's hard to describe. Similarly, editing code without Vim feels tedious in a similar way. Imagine scrolling a long article by pressing the down arrow over and over, or clicking the down button at the bottom of the scroll bar.
Another complaint I see is that remembering the commands is too hard an ask. I moved from QWERTY to Workman at the same time that I was learning Vim and it was interesting because I learned that I -- and probably most people, but I'm speculating -- don't associate commands or actions with letters after they're initially learned. It's all muscle memory, just particular movements of select fingers. The Vim stuff you use day-in-day-out just sticks in your brain and you don't think about anymore than you think about which fingers to activate to type words.
Of course, some people probably just prefer to edit text like they do in almost all other text-editing contexts. They can already edit text; without some kind of perceived extra value, there's no motivation to change, or seemingly even try to understand an alternative. For me, it's the pleasure of feeling efficient and doing dev pain-free.
Yep there are many more reasons than "typing fast" for using Vim. For me the main motivator to dive into Vim was to not use the mouse at all because it constantly gave me RSI. It worked great. I never again had RSI since I switched to Vim for all my coding.
I think part of the benefit of vim for RSI is that there's not much chording - pressing two keys at once.
When not using vim you often need control characters on the left hand. Ctrl-C Ctrl-V Ctrl-X Ctrl-A are all on the left. Also, for bash, Ctrl-R and Ctrl-E. I've been training myself to use the right ctrl key for all these, because for some reason I was chording with the left hand.
I've also tried to learn to use caps lock for all-caps, but with less success.
When not using vim you often need control characters on the left hand. Ctrl-C Ctrl-V Ctrl-X Ctrl-A are all on the left. Also, for bash, Ctrl-R and Ctrl-E. I've been training myself to use the right ctrl key for all these, because for some reason I was chording with the left hand.
I've also tried to learn to use caps lock for all-caps, but with less success.
I work differently. I mainly read code, and do small manipulations in different places. Reading technical documentation is maybe 5% of what I do. I mainly need to figure out code.
So basically it's jumping around, refactor some stuff, and add some stuff. For that, Vim is ideal.
Code only flows straight from brain to fingers when it's trivial and boring ;).
I use the VSVim plugin in VSCode. I wouldn't necessarily call it a "productivity boost", but more of a convenience or ergonomic solution.
The Vim keybindings make it really easy to for example copy something within () and then navigate quickly and paste it somewhere without touching your mouse.
But overall I agree, I can probably do the same amount of work without the Vim plugin, it would just make it more inconvenient: more mouse manipulations, ctrl-shift-arrow finger spreadstands to select chucks of text etc.
So basically it's jumping around, refactor some stuff, and add some stuff. For that, Vim is ideal.
Code only flows straight from brain to fingers when it's trivial and boring ;).
I use the VSVim plugin in VSCode. I wouldn't necessarily call it a "productivity boost", but more of a convenience or ergonomic solution.
The Vim keybindings make it really easy to for example copy something within () and then navigate quickly and paste it somewhere without touching your mouse.
But overall I agree, I can probably do the same amount of work without the Vim plugin, it would just make it more inconvenient: more mouse manipulations, ctrl-shift-arrow finger spreadstands to select chucks of text etc.
If I would type at 15 WPM, I would be MUCH less productive than I am today for sure.
The point of using Vim, is that you boost your keyboard interface to the maximum. Obviously, using Vim, means you touch-type. Also, you don't use the mouse. Basically, using Vim, is like having the brain hard-wired to the computer for every task, not only text edition. Everything you do goes through the keyboard, and you don't have to think about it. You scroll through text, search for it, edit it, open new files, etc.
For instance, most of the time I don't use any GUI for Git either. I do everything in the terminal, and only use the GUI for partial commit (ie. select which line to commit). I have dedicated aliases for getting history, etc.
Also, when learning Vim, you notice that many (Linux) tools have Vim shortcuts enabled. I discovered many of them by chance, out of the habits of using Vim shortcuts.
The point of using Vim, is that you boost your keyboard interface to the maximum. Obviously, using Vim, means you touch-type. Also, you don't use the mouse. Basically, using Vim, is like having the brain hard-wired to the computer for every task, not only text edition. Everything you do goes through the keyboard, and you don't have to think about it. You scroll through text, search for it, edit it, open new files, etc.
For instance, most of the time I don't use any GUI for Git either. I do everything in the terminal, and only use the GUI for partial commit (ie. select which line to commit). I have dedicated aliases for getting history, etc.
Also, when learning Vim, you notice that many (Linux) tools have Vim shortcuts enabled. I discovered many of them by chance, out of the habits of using Vim shortcuts.
> Everything you do goes through the keyboard
Except web browsing, which is a huge part of software engineering, and which is nearly impossible to do without the mouse because most websites cannot be reasonably navigated with shortcuts alone.
So the whole model falls apart, really.
Except web browsing, which is a huge part of software engineering, and which is nearly impossible to do without the mouse because most websites cannot be reasonably navigated with shortcuts alone.
So the whole model falls apart, really.
Some avid vim users will also use https://vimium.github.io/ in their browsers, so they can also browse using the keyboard and vim-like cursor movement commands.
Tridactyl does the job for most websites pretty well as for text heavy sites like documentation it’s very good.
https://github.com/tridactyl/tridactyl
https://github.com/tridactyl/tridactyl
Not really and only on a vanilla browser.
Most of my operations on a web browser involve scrolling or swapping pages, which I typically do with a keyboard. Besides every browser has keyboard extensions that allow one to select links through keyboard press. Being a neovim user I like vimium on firefox. I also like to use text based browsers for a better browsing experience and less distraction when I am coding.
Most of my operations on a web browser involve scrolling or swapping pages, which I typically do with a keyboard. Besides every browser has keyboard extensions that allow one to select links through keyboard press. Being a neovim user I like vimium on firefox. I also like to use text based browsers for a better browsing experience and less distraction when I am coding.
For what it's worth, I have no problem using the mouse, or the keyboard, but I hate having to switch between them all the time. The longer I can use one without having to switch to the other, the better. Editing text can't really be done without the keyboard, so for that activity the use of the mouse should be absolutely minimal.
I don't find myself needing the browser too much when I code. Other than to reload a page if I'm tweaking something on the FE.
Not that I know everything, but I view informational browsing as a distraction while programming. The LSP augments most of the knowledge gaps for me.
If vim isn't for you that's cool. But I find other editors for me are this-is-fine.gif.
Not that I know everything, but I view informational browsing as a distraction while programming. The LSP augments most of the knowledge gaps for me.
If vim isn't for you that's cool. But I find other editors for me are this-is-fine.gif.
I use trydactyl.
Really, the model doesn't fall apart. But you don't have to use it if you don't want to.
Really, the model doesn't fall apart. But you don't have to use it if you don't want to.
[deleted]
Only tangentially touching your points, my take on Vim or modal editing in general is the following:
When I edit existing text (program code, prose) a modal editor shines. I am mostly in command mode and re-arrange text or re-factor code from here to there.
When I am _creating_ text, for me a modal type editor is a hindrance. Agreed, I should probably be most of the time in insert mode yet in practice I find myself switching between insert mode and command mode all the time. For what reasons ever this switching never made it into "muscle memory" and disrupts my workflow.
For that reasons I am an avid user of both Vim and Emacs.
When I edit existing text (program code, prose) a modal editor shines. I am mostly in command mode and re-arrange text or re-factor code from here to there.
When I am _creating_ text, for me a modal type editor is a hindrance. Agreed, I should probably be most of the time in insert mode yet in practice I find myself switching between insert mode and command mode all the time. For what reasons ever this switching never made it into "muscle memory" and disrupts my workflow.
For that reasons I am an avid user of both Vim and Emacs.
> When I "program", 95% of what I do is read documentation and other technical resources
That's very off from my work. For me, it's the opposite: 95% is writing code, navigating code, testing code or doing stuff in the shell. Reading documentation usually makes only a small amount. And even then, writing notes makes a good part of it too.
> conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases.
I can also do that while typing. Mindgears are no reason to stop typing.
That's very off from my work. For me, it's the opposite: 95% is writing code, navigating code, testing code or doing stuff in the shell. Reading documentation usually makes only a small amount. And even then, writing notes makes a good part of it too.
> conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases.
I can also do that while typing. Mindgears are no reason to stop typing.
I agree with your point but fwiw when I worked a full time C job doing things with servers running a custom Linux kernel the biggest conveniences were Shift+k over a keyword to open the man page (most of my time was reading docs too!), having some custom scripts that read ctags and could tab-complete keywords from our large codebase and open the files at the right line, and having the same editor on our embedded servers and VMs as on dev machines (and even now that's half of why vim is still my primary).
There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime.
(but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.)
other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc
There were people at the company who were more efficient than me using Sublime + mouse, but I was less efficient using Sublime.
(but really the biggest reason I use vim as a slow and sloppy typer and not a computer person is, hotkeys make my hands hurt, I've managed to avoid any RSI or pains like this, and I like vim better than vim keybindings in other editors.)
other productivity gains not related to typing were the search/replace in vim, embedded terminal, and being in and staying in a terminal made it easier and quicker to switch to scripty things, searching or reformatting files etc
> Shift+k over a keyword to open the man page
Any widely used modern editor/IDE will have plugins to do the same thing.
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working.
> and having the same editor on our embedded servers and VMs as on dev machines
That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.
Any widely used modern editor/IDE will have plugins to do the same thing.
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working.
> and having the same editor on our embedded servers and VMs as on dev machines
That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around.
okay? you've pivoted from "not understanding" vim to having an anti-vim boner. other people in the same environement achieved as much or more than me with different tools. and those different tools didn't work for me. that's all that's going on here.
(sshfs is not a direct substitute for being able to quickly interact with a remote environment)
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.
(sshfs is not a direct substitute for being able to quickly interact with a remote environment)
> having some custom scripts that read ctags and could tab-complete keywords from our large codebase
for clarity i meant that I had a completion in the terminal when not in the editor to quickly jump to a tag in a file. `vim -t <keyword>`. i could be in a terminal, execute a remote command on a machine, know what I wanted to look at next and quickly go there without much effort. And again, other people were productive without doing this. these were just my tools and i liked them.
Any widely used modern editor/IDE will have plugins to do the same thing.
> True. But i do not want to install multiple several gigabyte sized bloatware gui behemoths apps just to develop some software.
Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working. > Also available in vim and doesnt need any home-cook solution. There are decent plugins that work out of the box for that kind of stuff
That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around. > or more easily: just edit remote files directly via scp/ssh. Vim can do that.
Contextual completion as offered by modern IDEs or language servers is vastly superior to Ctags, and you don't have to home-cook anything to get it working. > Also available in vim and doesnt need any home-cook solution. There are decent plugins that work out of the box for that kind of stuff
That's what SSHFS is for. No need to limit yourself to whatever happens to be installed on the remote machine. You don't even have to copy config files around. > or more easily: just edit remote files directly via scp/ssh. Vim can do that.
I doubt Vim helps my productivity. At least, I’m sure if I dropped vim I would be learn to be just as fast in whatever I ended up using.
It’s just the ergonomics and easy customizability. Keybindings are in all editors, but in vim I don’t have to press all buttons at once. Just: “space”. Walk to the coffee machine. “g”. Get interrupted. “c” - there opens my git commit window. This feels so infinitely much nicer than any other keybinding system I have used. I always struggle going back to anything else.
Next to that, the way the config just works. Just a file I can edit.
Vim doesn’t work wonders, it’s just a preference.
It’s just the ergonomics and easy customizability. Keybindings are in all editors, but in vim I don’t have to press all buttons at once. Just: “space”. Walk to the coffee machine. “g”. Get interrupted. “c” - there opens my git commit window. This feels so infinitely much nicer than any other keybinding system I have used. I always struggle going back to anything else.
Next to that, the way the config just works. Just a file I can edit.
Vim doesn’t work wonders, it’s just a preference.
(Sorry late to the game)
A friend suggested this to me a while back so I tried a couple IDEs, and it didn't really do it for me. Mostly I think this for three reasons:
1. IDEs don't offer features I need. I don't often need to do a big rename (and if I do, sed and grep have me covered) or generate getters/setters, or what have you.
2. Cool stuff happens outside IDEs. There are tools that generate docs for APIs or even APIs themselves. There are tools that generate clients for APIs. There are tools to build apps using formal techniques (think Jason Donenfeld's work on WireGuard here). IDEs are behind here.
3. For "reasons", I had to implement a circumspect version of DBT in a few days, roughly 1300 LOC. Doing this with Vim was hard enough, but doing this with an IDE would've been impossible because while they help with some of the drudgery of the structure, they can't implement a structure itself, and they can't help me wrangle the raw code.
> Does code just flow from their brains into their fingers? I don't get it.
It sounds ridiculous, but yeah, more or less. I learn and assess by doing, so mostly I jam things out at 140 wpm, see if it's good, if not do it again. And over a career of doing this I have to do things over less and less, and when I do I get both an implementation and a pretty good empirical defense of it at the end.
A friend suggested this to me a while back so I tried a couple IDEs, and it didn't really do it for me. Mostly I think this for three reasons:
1. IDEs don't offer features I need. I don't often need to do a big rename (and if I do, sed and grep have me covered) or generate getters/setters, or what have you.
2. Cool stuff happens outside IDEs. There are tools that generate docs for APIs or even APIs themselves. There are tools that generate clients for APIs. There are tools to build apps using formal techniques (think Jason Donenfeld's work on WireGuard here). IDEs are behind here.
3. For "reasons", I had to implement a circumspect version of DBT in a few days, roughly 1300 LOC. Doing this with Vim was hard enough, but doing this with an IDE would've been impossible because while they help with some of the drudgery of the structure, they can't implement a structure itself, and they can't help me wrangle the raw code.
> Does code just flow from their brains into their fingers? I don't get it.
It sounds ridiculous, but yeah, more or less. I learn and assess by doing, so mostly I jam things out at 140 wpm, see if it's good, if not do it again. And over a career of doing this I have to do things over less and less, and when I do I get both an implementation and a pretty good empirical defense of it at the end.
It was a huge productivity boost for me, because when text editing was tedious, I would lose my flow, get bored and annoyed, and start goofing off.
It’s flow state/reducing cognitive load, not just literal typing speed. I know that might sound insane —- I was extremely weary of such claims for a long time and thought vim was stupid —- but after getting over the “hump,” I get it and absolutely can’t go back.
Fast typing speed and efficient editor practice are transformative; when human-computer interface becomes frictionless you unlock notation as a tool of thought, and really be able to use the computer to design your programs instead of doing design first in your head/pen-and-paper/whiteboard and then transcribing near-final code to computer. Or at least that is the idea; I'm not 100% certain if it is not just pipedream for majority of us.
Do you write config files? Do you copy similar unit test structures? or perhaps have you ever found a mouse/touchpad annoying?
If purely going off programming speed, probably won't improve much. Most of the time is spent thinking. But it helps reduce annoyance in many other situations - I'm not annoyed when I think, but I'm annoyed when I have to move the cursor, drag it and do it 10 different times when in vim the same is burned into muscle memory and can be done without any thought process, over some config file that I must edit now but not that often enough that it's worth creating a script or template, and then the same apply to templates as well and all levels of abstraction.
An extremely common scenario is to copy the content from one enclosed parentheses and into another, and similar class of problems. With vim it's just a few keystrokes, but without it's lots of cursor and drag. These common scenarios are why people use vim bindings.
Oh and I can do all of that in the terminal of a remote machine, which happen to have enough memory to run a massive integration test, and build all things a lot faster.
If purely going off programming speed, probably won't improve much. Most of the time is spent thinking. But it helps reduce annoyance in many other situations - I'm not annoyed when I think, but I'm annoyed when I have to move the cursor, drag it and do it 10 different times when in vim the same is burned into muscle memory and can be done without any thought process, over some config file that I must edit now but not that often enough that it's worth creating a script or template, and then the same apply to templates as well and all levels of abstraction.
An extremely common scenario is to copy the content from one enclosed parentheses and into another, and similar class of problems. With vim it's just a few keystrokes, but without it's lots of cursor and drag. These common scenarios are why people use vim bindings.
Oh and I can do all of that in the terminal of a remote machine, which happen to have enough memory to run a massive integration test, and build all things a lot faster.
I'll tell you my motivations to switch to Vim. My wrists.
All that typing in 20s finally caught up and I have been having recurring wrist pain.
Keeping fingers near the home row as Vim keybindings encourage and avoiding jumping around on keyboard in one way to avoid wrist strains and something I'd recommend people to start doing earlier rather that later.
All that typing in 20s finally caught up and I have been having recurring wrist pain.
Keeping fingers near the home row as Vim keybindings encourage and avoiding jumping around on keyboard in one way to avoid wrist strains and something I'd recommend people to start doing earlier rather that later.
"If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity."
It's an Amdahl's law thing. Even if you drop my typing time down to zero, it wouldn't affect much. That said, multiplying my typing time by 10 would be a hit.
I consider being bottlenecked on my raw ability to type to be a huge red flag. I'm doing something wrong unless I have a very specific reason to be so bottlenecked, like I'm momentarily just doing data entry with no ability to simplify the process. (Unusual, but it does happen; for a micro example, typing out all of some enumeration's value can bottleneck on raw typing speed if there's more than a couple of them and I happen to be able to instantly and correctly name them all.) Must be missing an abstraction or something.
It's an Amdahl's law thing. Even if you drop my typing time down to zero, it wouldn't affect much. That said, multiplying my typing time by 10 would be a hit.
I consider being bottlenecked on my raw ability to type to be a huge red flag. I'm doing something wrong unless I have a very specific reason to be so bottlenecked, like I'm momentarily just doing data entry with no ability to simplify the process. (Unusual, but it does happen; for a micro example, typing out all of some enumeration's value can bottleneck on raw typing speed if there's more than a couple of them and I happen to be able to instantly and correctly name them all.) Must be missing an abstraction or something.
What you describe feels very true for constructing a green diff containing lots of new code being added to a code base.
Being able to juggle text really comes into its own when you now have to move it around from one module into many, appease the linters, search-for then factor-out a common pattern, or rewrite your idea in place without breaking it. These are all things we do to take code from the “it works” stage to the “it’s correct” stage, namely self documenting modular code that is human as well as machine readable.
Vim makes light work of the back breaking chores involved with code gardening, which indeed bears little resemblance to programming.
Being able to juggle text really comes into its own when you now have to move it around from one module into many, appease the linters, search-for then factor-out a common pattern, or rewrite your idea in place without breaking it. These are all things we do to take code from the “it works” stage to the “it’s correct” stage, namely self documenting modular code that is human as well as machine readable.
Vim makes light work of the back breaking chores involved with code gardening, which indeed bears little resemblance to programming.
I guess it might be because the nature of your work. When I started as a SE over a decade ago, my job was really just writing code according to the specs. Typing speed was important as I wrote over 100k lines of code in the very first year. But less and less code I wrote after that. Once I spent around 6 months meeting CEO daily just to figure out what was wrong with something screwed pretty badly by someone with a fancy big title. Eventually the code I changed to fix those problems were less than 30 lines. That was extreme, but on average, I hardly write more than 100 lines of code per day just like you. Typing was no more an issue for a very long time.
Vim is fantastic for reading text. There are so many good commands that make it trivial to move around your code incredibly easily, and also make it easier to read (for example, a 2 key chord to position the line under your current cursor to the top/middle/bottom of your viewport).
Even better, unlike most IDEs, the overwhelming majority of your screen is devoted to just the text. There are no toolbars, no sidebars, not even a menu bar. Vim (and similar terminal based editors) are the original focus mode text viewers/editors.
Finally, the VIM chords become natural in a way keyboard shortcuts don’t. Part of the reason is that with the VIM normal mode, you have access to significantly more keys with which to form shortcuts, whereas most other editors use number and letter keys for typing text, so shortcuts become increasingly convoluted combinations of modifier keys.
Everything about VIM is optimized for reading text, then editing text and only after that inserting text. Inserting text is a special mode in VIM, whereas the default normal mode is for reading.
So VIM is a highly optimized tool for the workflow you described.
Even better, unlike most IDEs, the overwhelming majority of your screen is devoted to just the text. There are no toolbars, no sidebars, not even a menu bar. Vim (and similar terminal based editors) are the original focus mode text viewers/editors.
Finally, the VIM chords become natural in a way keyboard shortcuts don’t. Part of the reason is that with the VIM normal mode, you have access to significantly more keys with which to form shortcuts, whereas most other editors use number and letter keys for typing text, so shortcuts become increasingly convoluted combinations of modifier keys.
Everything about VIM is optimized for reading text, then editing text and only after that inserting text. Inserting text is a special mode in VIM, whereas the default normal mode is for reading.
So VIM is a highly optimized tool for the workflow you described.
> Is this really unusual? How do people operate for whom Vim gives a productivity boost?
Don't think of vim as a magic totem of productivity. You should think of it as a largely distraction-free editor. No messing about with a mouse. No GUI to get in the way of your thoughts. Loads up immediately, and works the same way in any system, local or remote.[ß]
So it's less to do with speed of writing, and much (much!) more about maintaining focus.
ß: not really true, any long-time user will have their own customisations they rely on, but the basic commands are always the same.
Don't think of vim as a magic totem of productivity. You should think of it as a largely distraction-free editor. No messing about with a mouse. No GUI to get in the way of your thoughts. Loads up immediately, and works the same way in any system, local or remote.[ß]
So it's less to do with speed of writing, and much (much!) more about maintaining focus.
ß: not really true, any long-time user will have their own customisations they rely on, but the basic commands are always the same.
read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all.
In my case, this often creates an elegant and conceptual code that doesn’t match expectations or even reality. Reminds me these meetings when someone e.g. says “no-brainer, there’s API for that” and goes on with requirements, schedules and administrative tasks without checking first if it’s hooks, streaming, polling with a rate limiter, or a non-idempotent email-like protocol with a completely undocumented bullshit in its payload section. The correct remark is “hold your horses”.
More than half of my work (strange corners of fintech) is checking, testing, prototyping, fail-refine cycles, unrealistic expectation reports. Not only APIs, also hw, niche software, reverse engineering, a little bit of everything. 80% of it goes straight into the “Attic” repo after few hours. I have to type an unelegant and unconceptual code fast and reshape it at the speed of thought about a realtime problem, there’s no time for clever design if a business-critical decision or a paper-heavy process depend on these experiments.
Using a boring editor feels like you want to quickly visit a few places to see if they are good enough, but they are all in different cities, so you start to forget details while you drive. And relying on a documentation is like buying a house by pictures alone.
For me the structure comes from the actual code, after I can extract its true shape, after the requirements got satisfied in a fully functional prototype, which is also a sort of a knowledge base for a project. I’m able to plan it in advance, but only with 20% probability and 80% of unnecessary work.
In my case, this often creates an elegant and conceptual code that doesn’t match expectations or even reality. Reminds me these meetings when someone e.g. says “no-brainer, there’s API for that” and goes on with requirements, schedules and administrative tasks without checking first if it’s hooks, streaming, polling with a rate limiter, or a non-idempotent email-like protocol with a completely undocumented bullshit in its payload section. The correct remark is “hold your horses”.
More than half of my work (strange corners of fintech) is checking, testing, prototyping, fail-refine cycles, unrealistic expectation reports. Not only APIs, also hw, niche software, reverse engineering, a little bit of everything. 80% of it goes straight into the “Attic” repo after few hours. I have to type an unelegant and unconceptual code fast and reshape it at the speed of thought about a realtime problem, there’s no time for clever design if a business-critical decision or a paper-heavy process depend on these experiments.
Using a boring editor feels like you want to quickly visit a few places to see if they are good enough, but they are all in different cities, so you start to forget details while you drive. And relying on a documentation is like buying a house by pictures alone.
For me the structure comes from the actual code, after I can extract its true shape, after the requirements got satisfied in a fully functional prototype, which is also a sort of a knowledge base for a project. I’m able to plan it in advance, but only with 20% probability and 80% of unnecessary work.
"Does code just flow from their brains into their fingers?"
Honestly, it does feel that way sometimes. You move so much faster and with so much more efficiency and power that you can just think at a higher level while you're coding.
Honestly, it does feel that way sometimes. You move so much faster and with so much more efficiency and power that you can just think at a higher level while you're coding.
I fully agree. Yet I still learned the vi input model because pretty much every text editor on every platform supports it one way or another, and a cross-editor / cross-platform input model makes it a no-brainer to switch editors (which I do all the time, e.g. using vim for quick edits on the command line, and a 'proper' IDE for coding, where the IDE also changes (VStudio, Xcode, VSCode) depending on platform or task at hand. And while typing speed doesn't matter much for productivity, "muscle memory" does for "staying in the flow".
10k lines is still 10k lines. What I like about vim is that it mimics how i think about code, its the closest thing to a brain interface that an editor can be.
I don't think I'm more productive than non-vim users, it's just my preference. To the point where it's actually painful to use an editor that doesn't support the vim bindings.
I like not having to use the mouse, that's more ergonomic for me. Some people have an ergonomic mouse, I just avoid using it. Different solution, not necessarily better or worse.
I like not having to use the mouse, that's more ergonomic for me. Some people have an ergonomic mouse, I just avoid using it. Different solution, not necessarily better or worse.
> text manipulation is not at all a productivity bottleneck for me
No, but the benefit is in the mindset encouraged by Vim, especially around modal editing.
No, but the benefit is in the mindset encouraged by Vim, especially around modal editing.
Agree so much. It’s such a tiny fraction of the time spent for me no amount of optimization would affect the overall timeline.
Or, as Steve Yegge put it, most programmers are CPU-bound rather than I/O bound.
Same here. My productivity gain mainly comes from my brain, not how fast I can type.
> Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it.
For simple things, there's no perceived bottleneck in any editor… but not everything is simple. The productivity gains come from being able to make complex changes to documents using just normal mode and ex commands, which would normally require macros, scripts or plugins in other editors.
For example, this 12 year-old video by Derek Wyatt [1] demonstrates extracting the text from a XML representation of a mind map and turning it into a hierarchical, bulleted list using Vim’s search and replace commands which support regular expressions. Attempting to do the same thing in Notepad for example might take you 15-20 minutes.
He has a series of these videos, some of them jaw-dropping showing the power and brevity of using Vim for non-trivial editing and data extraction tasks.
And remember—this is Vim from 12 years ago with zero plugins.
> Does code just flow from their brains into their fingers? I don't get it.
There's a reason why the subtitle for Drew Neil's book Practical Vim is "Edit Text at the Speed of Thought" [2]. It's probably the best book on Vim that illuminates the power and efficiency of Vim and why it matters.
One you attain a level of proficiency with Vim, as you think about what to do next, your fingers hit the right keys and without thinking about it, the change is done.
An identifier for a constant needs to be all caps? Say the cursor is at the end of the line and the identifier is at the start of the line and I'm in insert mode.
1. Press Escape (enters normal mode)
2. Press '0' (motion for jump to first character of the line)
3. Press control-v (enter visual block mode)
4. Press 'e' (move the cursor to the end of the word while highlighting the word)
5. Press '~' (switches the case of the highlighted characters)
There's no reaching for the mouse or moving your hand towards the trackpad from the keyboard. It may not seem like much, but for experienced Vim users, an operation like this is a second nature, muscle memory thing that takes about a second to do. There's no break in focus or concentration and you're off doing the next thing.
That's where you save time and editing becomes more efficient. And while there are dozens of these types of simple edits that second nature to Vim users, doing more sophisticated changes can be just as efficient.
[1]: https://vimeo.com/user1690209
[2]: https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
For simple things, there's no perceived bottleneck in any editor… but not everything is simple. The productivity gains come from being able to make complex changes to documents using just normal mode and ex commands, which would normally require macros, scripts or plugins in other editors.
For example, this 12 year-old video by Derek Wyatt [1] demonstrates extracting the text from a XML representation of a mind map and turning it into a hierarchical, bulleted list using Vim’s search and replace commands which support regular expressions. Attempting to do the same thing in Notepad for example might take you 15-20 minutes.
He has a series of these videos, some of them jaw-dropping showing the power and brevity of using Vim for non-trivial editing and data extraction tasks.
And remember—this is Vim from 12 years ago with zero plugins.
> Does code just flow from their brains into their fingers? I don't get it.
There's a reason why the subtitle for Drew Neil's book Practical Vim is "Edit Text at the Speed of Thought" [2]. It's probably the best book on Vim that illuminates the power and efficiency of Vim and why it matters.
One you attain a level of proficiency with Vim, as you think about what to do next, your fingers hit the right keys and without thinking about it, the change is done.
An identifier for a constant needs to be all caps? Say the cursor is at the end of the line and the identifier is at the start of the line and I'm in insert mode.
1. Press Escape (enters normal mode)
2. Press '0' (motion for jump to first character of the line)
3. Press control-v (enter visual block mode)
4. Press 'e' (move the cursor to the end of the word while highlighting the word)
5. Press '~' (switches the case of the highlighted characters)
There's no reaching for the mouse or moving your hand towards the trackpad from the keyboard. It may not seem like much, but for experienced Vim users, an operation like this is a second nature, muscle memory thing that takes about a second to do. There's no break in focus or concentration and you're off doing the next thing.
That's where you save time and editing becomes more efficient. And while there are dozens of these types of simple edits that second nature to Vim users, doing more sophisticated changes can be just as efficient.
[1]: https://vimeo.com/user1690209
[2]: https://pragprog.com/titles/dnvim2/practical-vim-second-edit...
I have mapped esc+hjkl to arrow keys system-wide and moved esc to capslock, which is a already a game changer.
The respect for vim and especially vim keybindings is definitely there, I use it for editing bashrc‘s or similar or inspecting stuff in the terminal, but what do you recommend to get over the hump of learning it better such that e.g. vimbindings in vscode could replace the standard?
For code, I use vscode currently, so your example would be:
* cmd capslock h (to go to the beginning of the line)
* alt capslock l (to move right to the first word and off the whitespace)
* cmd d (to highlight the word und the cursor)
* F2 to rename the symbol codebase-wide or cmd shift g to select all occurrences in the file
* retype the word in allcaps (enter if F2 was used)
The respect for vim and especially vim keybindings is definitely there, I use it for editing bashrc‘s or similar or inspecting stuff in the terminal, but what do you recommend to get over the hump of learning it better such that e.g. vimbindings in vscode could replace the standard?
For code, I use vscode currently, so your example would be:
* cmd capslock h (to go to the beginning of the line)
* alt capslock l (to move right to the first word and off the whitespace)
* cmd d (to highlight the word und the cursor)
* F2 to rename the symbol codebase-wide or cmd shift g to select all occurrences in the file
* retype the word in allcaps (enter if F2 was used)
Touch typing is one way to put it. I would say Vim is an imperative editor. You need to tell the computer how to edit text by glueing together chains of small painful commands. IDEs are declarative editors, you say you want to refactor a variable, and the IDE handles it.
Vim is a text editor, not a code editor, and I keep forgetting how weird it is. "Ctrl-X Ctrl-D completes a C preprocessor macro by default" - there is no reason this should be in the core of any editor.
And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim. Without the knowledge of that book, you're too limited to approach efficient (imperative) editing.
Vim is a text editor, not a code editor, and I keep forgetting how weird it is. "Ctrl-X Ctrl-D completes a C preprocessor macro by default" - there is no reason this should be in the core of any editor.
And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim. Without the knowledge of that book, you're too limited to approach efficient (imperative) editing.
> And finally, whatever you think of Vim, it's not worth using unless you've read Practical Vim.
Uh, what? I find it absolutely painful to watch my coworkers click around in their IDEs. It takes them forever to get things done.
Of the handful of hard core Vim users in the office, I’m the least sophisticated. But I’m WAY faster than all the non-Vim users.
Uh, what? I find it absolutely painful to watch my coworkers click around in their IDEs. It takes them forever to get things done.
Of the handful of hard core Vim users in the office, I’m the least sophisticated. But I’m WAY faster than all the non-Vim users.
It's not so much the absence of vim as it is their apparent ignorance of the magic of hotkeys. Download a vim plugin for your IDE and you get modal editing (usually w/ vimrc binding support) too. imo that's the absolute best way to go. You get modal editing speed, modern UI, better autocomplete over a wider bank of languages, two key press project wide refactors, go to definition without needing ctags, a terminal in the ide so you can still run commands easily (typically better than vims term window does), git integration...the list goes on and on. And sure, you can download a huge set of vim plugins to get something close, but the ux will never feel as unified as it does in an ide and it takes extra work to maintain your rc+.vim...
> but the ux will never feel as unified as it does in an ide
I argue the opposite. Because vim is such a constrained environment, the UX is extremely unified.
An IDE with vim mode is the opposite. Vim mode usually only works in the text buffers and nowhere else (at least not properly). You need to memorize a combination of vim hotkeys and regular ide hotkeys OR spend a long time messing around with your IDE hotkeys (probably comparable to vim config).
In vim, since everything is a buffer and a window, you can use your regular navigation hotkeys to move between them. I just think "I want to shift my focus to the window on the left" and it doesn't matter if the window on the left is a text file or some plugin.
In something like IntelliJ, you can't "just go left". You need to know what the hotkey is for the panel on the left. The "non-modern" UI, which constrains vim actually makes a significantly more unified experience.
> terminal in the ide so you can still run commands easily (typically better than vims term window does)
This is a perfect example. How do you switch back and forth between your terminal and text file in an IDE? How do you copy paste between your terminal and text file? Can you use vim movement in your terminal that you opened in your IDE? Or your registers? In vim, that all works perfectly just like you'd expect without learning anything new, it just works like regular vim.
That being said, I still use IntelliJ if I'm writing Kotlin. The semantic analysis they can do is absolutely top notch, can't get something comparable in vim and the productivity gains out weigh my annoyance with the inconsistent UX. Something like python though? I'll probably stick with vim, jedi is good enough.
I argue the opposite. Because vim is such a constrained environment, the UX is extremely unified.
An IDE with vim mode is the opposite. Vim mode usually only works in the text buffers and nowhere else (at least not properly). You need to memorize a combination of vim hotkeys and regular ide hotkeys OR spend a long time messing around with your IDE hotkeys (probably comparable to vim config).
In vim, since everything is a buffer and a window, you can use your regular navigation hotkeys to move between them. I just think "I want to shift my focus to the window on the left" and it doesn't matter if the window on the left is a text file or some plugin.
In something like IntelliJ, you can't "just go left". You need to know what the hotkey is for the panel on the left. The "non-modern" UI, which constrains vim actually makes a significantly more unified experience.
> terminal in the ide so you can still run commands easily (typically better than vims term window does)
This is a perfect example. How do you switch back and forth between your terminal and text file in an IDE? How do you copy paste between your terminal and text file? Can you use vim movement in your terminal that you opened in your IDE? Or your registers? In vim, that all works perfectly just like you'd expect without learning anything new, it just works like regular vim.
That being said, I still use IntelliJ if I'm writing Kotlin. The semantic analysis they can do is absolutely top notch, can't get something comparable in vim and the productivity gains out weigh my annoyance with the inconsistent UX. Something like python though? I'll probably stick with vim, jedi is good enough.
Vim binding is great and I find it solves at least 90% of my usage.
It's the 5% of vim that's unavailable (i.e. norm, macros) and 5% of needing to still click the IDE UI occasionally that reminds me that it still isn't vim.
But then again, for some language families there just isn't a choice.
It's the 5% of vim that's unavailable (i.e. norm, macros) and 5% of needing to still click the IDE UI occasionally that reminds me that it still isn't vim.
But then again, for some language families there just isn't a choice.
I very much agree with this. It is very tedious to edit code without a "text editor". By the way, Vim and Emacs have all the fancy refactoring / formatting / navigation things that VS Code does; using the exact same implementation. You get a no-compromises best of both worlds, at the cost of a lot of front-loaded learning. (That is to say, I get why Intro to Python books don't suggest learning vim. One problem at a time. But someday, it will really help you with the mechanics of slinging code to have a featureful text editor around.)
Python without vscode and pylance is rough. And even then you need to keep up with the typehinting. Vim and python leaves me with all sorts of horrific runtime errors to debug.
Write unit tests.
I write unit tests for my personal projects - it might sounds ridiculous but it is the reason why I can grow these projects beyond the initial 12 hours of interest. Since personal project tend to be on the smaller side I usually uses typescript or python but I've never found it an issue where pure vim usage becomes an issue at scale.
It also strongly enforces separation of concern in terms of file organization. I found using vim for development to be a positive feedback loop.
I write unit tests for my personal projects - it might sounds ridiculous but it is the reason why I can grow these projects beyond the initial 12 hours of interest. Since personal project tend to be on the smaller side I usually uses typescript or python but I've never found it an issue where pure vim usage becomes an issue at scale.
It also strongly enforces separation of concern in terms of file organization. I found using vim for development to be a positive feedback loop.
Insisnwrite unit tests, but they often passed for reasons other than the intended ones because of the dynamic typing. I kept adding tests every time I caught something runtime, but I was at an order of magnitude more tests than I would need with a strong and static types language. Pylance kept me from making thos mistakes in the first place.
Vim has all the same language servers that vscode has, with all the same capabilities.
e: never mind, I see Microsoft closed sourced pylance and restricted it to their products. Typical. Of course there is still pyright along with a python language server, but I guess technically not pylance any more.
e: never mind, I see Microsoft closed sourced pylance and restricted it to their products. Typical. Of course there is still pyright along with a python language server, but I guess technically not pylance any more.
I use Pyright with Doom Emacs at work, and I have no need for anything more. And I work on a relatively large Python codebase.
Every few years I trot out some vim command new to me and it falls to the wayside. I don't even use buffers right, I use tabs. Which are apparently a bastardized version but I digress.
F f g G jkl; ESC i r R yy p and control A and control E probably cover 90% of my cases.
However. I use a nub on my ThinkPad so I have sort of instant mouse access for location things, I mostly use jumping for inside a line
F f g G jkl; ESC i r R yy p and control A and control E probably cover 90% of my cases.
However. I use a nub on my ThinkPad so I have sort of instant mouse access for location things, I mostly use jumping for inside a line
Buffers and tabs serve different purposes. I think a lot of people dismiss tabs because they don't understand their purpose. It's not just about switching to different buffers quickly.
Tabs are an organized collection of windows, and you can quickly switch between them. I might organize my windows so half the screen is one buffer and on the other half, is split 3 times horizontally. Then I edit some code and realize I need to edit some other part of the codebase. I make a new tab instead of changing buffer, so I can go back to the view I setup already without having to recreate it.
Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?) and I miss it constantly. Buffers aren't really a novel concept, they work the same in VS code and JetBrains IDEs.
Tabs are an organized collection of windows, and you can quickly switch between them. I might organize my windows so half the screen is one buffer and on the other half, is split 3 times horizontally. Then I edit some code and realize I need to edit some other part of the codebase. I make a new tab instead of changing buffer, so I can go back to the view I setup already without having to recreate it.
Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?) and I miss it constantly. Buffers aren't really a novel concept, they work the same in VS code and JetBrains IDEs.
> Tabs are the true power of vim, I don't have that functionality in any other editor (apart from Emacs?)
Yeah, Emacs also lets you do that! You can achieve similar workflows via tmux or a tiling window manager as well. It's my favorite way to work! For whatever reason I've never gone down the tiling WM rabbit hole, but I use this kind of thing in Emacs and tmux all the time.
Yeah, Emacs also lets you do that! You can achieve similar workflows via tmux or a tiling window manager as well. It's my favorite way to work! For whatever reason I've never gone down the tiling WM rabbit hole, but I use this kind of thing in Emacs and tmux all the time.
So I do use a tiling window manager, but the problem is that to take advantage of it, I'd need the editor to put each buffer in its own (real xorg) window. I couldn't get something working with either vscode or IntelliJ.
One editor that does support it, is kakoune. I forgot about it when writing my previous comment. Each instance can connect to a server, so they can all share registers/buffers/etc. Then you can use tmux or your window manager to create the layout you want.
It's very clever, I actually think it's superior to vim, as you aren't limited to organizing your views inside a single vim "main" window. You could do stuff like kak | browser | kak, and both kak instances share everything.
Unfortunately I can't get used to the kak commands so I'll probably never change. Perhaps neovim will one day implement something similar.
One editor that does support it, is kakoune. I forgot about it when writing my previous comment. Each instance can connect to a server, so they can all share registers/buffers/etc. Then you can use tmux or your window manager to create the layout you want.
It's very clever, I actually think it's superior to vim, as you aren't limited to organizing your views inside a single vim "main" window. You could do stuff like kak | browser | kak, and both kak instances share everything.
Unfortunately I can't get used to the kak commands so I'll probably never change. Perhaps neovim will one day implement something similar.
Ya, "tabs" are a misnomer coming from almost any other editor which is unfortunate. Vim doesn't have what most people think of as "tabs" (I guess you could think of them as "dynamic" tabs but I digress).
Vim has been my only code editor for the past 10+ years and I wish I used tabs a little better (ie, the way you describe). As it stands I have some plugins that open in a tab so they are easy to close (like gv.vim) and otherwise use my tabline as a secondary status line (it tells me my working directory and if I'm tracking a session or not).
Vim has been my only code editor for the past 10+ years and I wish I used tabs a little better (ie, the way you describe). As it stands I have some plugins that open in a tab so they are easy to close (like gv.vim) and otherwise use my tabline as a secondary status line (it tells me my working directory and if I'm tracking a session or not).
airline and bufferline plugins are great - it helps unify/bridge buffer and tabs
I never liked airline as I felt it was too busy and I like customizing my own statusline, though you've piqued my interest with how they deal with tabs. I actually like vim's tabs just as they are--I mostly need better mapping for manipulating them. I'm otherwise a dual-split-with-a-mark-or-two person.
Try :normal (:norm for short.) It can edit a set of lines given a certain set of vim commands. Sometimes simpler to reason with than regexes.
E.g., if you want to turn,
You could do it with a regex, but I just find it far more natural to list the commands: my brain is already imaging it that way: remove the bullet, add the quotes and the comma.
Good for-loop for "do this to each line". Sometimes takes a bit of back & forth to construct the command, or sometimes it's just easier to do multiple :norm's. One of the best additions to my repertoire in years.
E.g., if you want to turn,
* a
* b
* c
"a",
"b",
"c",
You could do it with a regex, but I just find it far more natural to list the commands: my brain is already imaging it that way: remove the bullet, add the quotes and the comma.
Good for-loop for "do this to each line". Sometimes takes a bit of back & forth to construct the command, or sometimes it's just easier to do multiple :norm's. One of the best additions to my repertoire in years.
[deleted]
> I would say Vim is an imperative editor.
It’s interesting you say this, since I’ve always thought of it in precisely the opposite way! A traditional editor is thoroughly imperative: all editing operations are built up by sequencing basic commands, almost exclusively ‘insert/delete a character’, ‘move to this line/column’, and ‘select from line/column position X to position Y’. By contrast, Vim gives me an entire declarative language to work with text: if I want to ‘delete a word’, or ‘change the next 10 lines’, or ‘move to the previous occurrence of the identifier under the cursor’, I can just do that, without having to mentally break it up into sequences of smaller editing operations.
I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state. Calling something ‘declarative’ without context isn’t very helpful, but it’s entirely valid to say that most text editors are less declarative than Vim, and Vim is in turn less declarative than the refactoring operations in a full-featured IDE.
It’s interesting you say this, since I’ve always thought of it in precisely the opposite way! A traditional editor is thoroughly imperative: all editing operations are built up by sequencing basic commands, almost exclusively ‘insert/delete a character’, ‘move to this line/column’, and ‘select from line/column position X to position Y’. By contrast, Vim gives me an entire declarative language to work with text: if I want to ‘delete a word’, or ‘change the next 10 lines’, or ‘move to the previous occurrence of the identifier under the cursor’, I can just do that, without having to mentally break it up into sequences of smaller editing operations.
I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state. Calling something ‘declarative’ without context isn’t very helpful, but it’s entirely valid to say that most text editors are less declarative than Vim, and Vim is in turn less declarative than the refactoring operations in a full-featured IDE.
My dream, as someone who writes text rather than code, is to move that next step along the continuum. I want a motion for "change sentence to future perfect tense."
That actually sounds somewhat reasonably attainable with recent advancements in natural language AI models.
> I suppose this all goes to reinforce a point I’ve made several times before, which is that ‘declarativity’ is more of a continuum rather than a state.
To me, it seems clear that editing an existing body of code is always imperative— you're literally manipulating the state of the text iteratively, no matter what you do! Code generation can be declarative. But you're still going to imperatively edit your declarations somewhere, in that case. :-P
To me, it seems clear that editing an existing body of code is always imperative— you're literally manipulating the state of the text iteratively, no matter what you do! Code generation can be declarative. But you're still going to imperatively edit your declarations somewhere, in that case. :-P
Pretty much. I tried using vim as my sole driver for a long time then finally saw the light that modern IDE + Vim mode plugin is the one true holy path.
Vim is wonderful but a massive waste of time and the quality of plugins is just lower jn general (obv. there are several exceptions, zig language support, for instance is much better than a lot of other vim language support plugins out of the box). The modal editing can't be beat, but frankly it's just way more painful to do sophisticated things in Vim than it is in a modern IDE. At best you need to produce a write once vimscript and hook it up to a command. Contrarily the ecosystems of modern IDEs are so large there's actually a greater chance someone already solved you problem and provides it with one click/hotkey. For me, vim is nothing but a constant distraction generator. Instead of being able to focus on what I actually intended to get done I'm ever tempted to go off writing some vimscript to solve some edge case I just encountered while editing or to automate something--much better to just make it a nonoption, at least for me. I'm sure there are vim gods out there that have an entirely different experience.
Vim is wonderful but a massive waste of time and the quality of plugins is just lower jn general (obv. there are several exceptions, zig language support, for instance is much better than a lot of other vim language support plugins out of the box). The modal editing can't be beat, but frankly it's just way more painful to do sophisticated things in Vim than it is in a modern IDE. At best you need to produce a write once vimscript and hook it up to a command. Contrarily the ecosystems of modern IDEs are so large there's actually a greater chance someone already solved you problem and provides it with one click/hotkey. For me, vim is nothing but a constant distraction generator. Instead of being able to focus on what I actually intended to get done I'm ever tempted to go off writing some vimscript to solve some edge case I just encountered while editing or to automate something--much better to just make it a nonoption, at least for me. I'm sure there are vim gods out there that have an entirely different experience.
I am no vim god but I have a different experience.
I've installed quite a few plugins (e.g. nerdtree, airline etc) but they are mostly cosmetic and I myself don't do much vimscript other than some basic .vimrc. But I do have most of the content of any vim cheatsheet burned into muscle memory and can come up with combination of them on the fly. I also use :norm extensively when I need to quickly batch edit anything.
I never really did encounter scenarios where the logic are so complex that I'd rather write vimscript to solve it - at worst, I'd do a macro, but combination of modal keys are usually enough. I think I find a sweet spot between using vim to its maximum utility and less about using vim for the sake of vim.
I have a quick install script for everything I depend on and one thing I found extremely valuable is the ability to pull, install and have the same editor customized and familiar in any computer, virtual or real, it even works on Windows (WSL).
I've installed quite a few plugins (e.g. nerdtree, airline etc) but they are mostly cosmetic and I myself don't do much vimscript other than some basic .vimrc. But I do have most of the content of any vim cheatsheet burned into muscle memory and can come up with combination of them on the fly. I also use :norm extensively when I need to quickly batch edit anything.
I never really did encounter scenarios where the logic are so complex that I'd rather write vimscript to solve it - at worst, I'd do a macro, but combination of modal keys are usually enough. I think I find a sweet spot between using vim to its maximum utility and less about using vim for the sake of vim.
I have a quick install script for everything I depend on and one thing I found extremely valuable is the ability to pull, install and have the same editor customized and familiar in any computer, virtual or real, it even works on Windows (WSL).
It’s not an either or.
In fact, any IDE (or any coding environment) lacking VIM bindings is broken.
As long as my computer is beefy enough, I’m perfectly happy using Jetbrains or VS Code or whatever IDE, but I always use VIM bindings and it’s been a key piece of my recovery from severe RSI. It’s been a nice productivity boost, too.
In fact, any IDE (or any coding environment) lacking VIM bindings is broken.
As long as my computer is beefy enough, I’m perfectly happy using Jetbrains or VS Code or whatever IDE, but I always use VIM bindings and it’s been a key piece of my recovery from severe RSI. It’s been a nice productivity boost, too.
>In fact, any IDE (or any coding environment) lacking VIM bindings is broken.
Not a fact. You just prefer vim bindings, which is fine. Other people prefer other schemes, which is also fine.
Not a fact. You just prefer vim bindings, which is fine. Other people prefer other schemes, which is also fine.
VIM bindings are a very, very common preference and were one of the first suggestions I got when dealing with repetitive stress injuries from extensive computer use and were key for my recovery. It was also key several others I know who have been through similar, albeit less extreme injuries.
I'm all for IDEs supporting many different bindings, but lacking VIM bindings is an accessibility issue and shuts out a significant % of the possible users.
I'm all for IDEs supporting many different bindings, but lacking VIM bindings is an accessibility issue and shuts out a significant % of the possible users.
You exhibit the “Vim mode paradox.” If you’re comfortable using the limited “Vim mode” in other editors, you don’t know Vim well enough to justify using it.
No vim mode is perfect, but they do make other editors bearable. I think vs code’s is the closest one I tried. Though I never really used it as my daily driver.
To me vim mode is just enough to keep me from ragequitting something like Xcode when using vim is practically not an option, but “vim” mode would never be enough to make me use another editor by choice. Vim isn’t just hjkl.
I tried Vim mode in XCode. When I move by paragraph, XCode crashes when it gets to the bottom of the screen.
I understand that XCode Vim mode is lacking a lot of the functionality of Vim, coming nowhere close to even the free XVim plugin. But you think they could at least make sure the few features they do include aren't completely broken.
I understand that XCode Vim mode is lacking a lot of the functionality of Vim, coming nowhere close to even the free XVim plugin. But you think they could at least make sure the few features they do include aren't completely broken.
Lolwut? I use Vim plugin for Visual Studio every day and although pretty limited compared to full fledged Vim, it's still extremely powerful. Besides hjkl movement, I still get splits, registers, macros, search/replace, formatting and the aforementioned features are easily 95% of Vim features I used to use Vim for. So the limited experience is still pretty great and I don't know how to use VS without this plugin anymore.
You've forgotten that nobody has to justify using the tools they like :)
But also, some Vi emulation modes are much, much more complete than others.
But also, some Vi emulation modes are much, much more complete than others.
I used vim as my primary code editor for over 15 years. Now I use IntelliJ vim mode and am happy with it.
You're saying I don't know vim well enough. What important vim features (which I'd use if I knew vim) is IntelliJ missing?
You're saying I don't know vim well enough. What important vim features (which I'd use if I knew vim) is IntelliJ missing?
> Without the knowledge of [Practical Vim], you're too limited to approach efficient (imperative) editing.
Are you the publisher or something? What a weird thing to say. I haven't read it, so I guess I'll go back to using nano--after 15 years of vim--and just suffer?
Are you the publisher or something? What a weird thing to say. I haven't read it, so I guess I'll go back to using nano--after 15 years of vim--and just suffer?
Yeah that was weird. How were we using vim for 20 years before that book ?
I have no affiliation with the book nor author. I’ve also been using Vim for about 15 years.
With LSP support VIM can do most of what you'd do in VSCode in terms of language specific refactoring. The plugin ecosystem is pretty rich.
Setting it up is still a nightmare, there are pre-made Neovim configs that I found helpful to start with (Nvchad, astrovim) but even then adding support for a new language is too much effort at times (as compared to VSCode where VSCode will suggest to download extensions the first time you open, say, a .go file and you just have to click)
VSCode with Vim bindings seems like a decent middle ground.
Setting it up is still a nightmare, there are pre-made Neovim configs that I found helpful to start with (Nvchad, astrovim) but even then adding support for a new language is too much effort at times (as compared to VSCode where VSCode will suggest to download extensions the first time you open, say, a .go file and you just have to click)
VSCode with Vim bindings seems like a decent middle ground.
I've struggled with this since basically nvim started supporting LSP and few months back switched to Helix. LSP just works the way it should in vim. Sure, I am slowly rebuilding muscle memory for the Kakoune-style bindings, but it's honestly not much of a leap for having the plugins you'd install built into the editor in a cohesive way (e.g. LSP, bufferline, git gutters, unimpaired bindings).
I'm honestly shocked at how fantastic Helix is and it makes me wonder if all the toil of inheriting vim was worth it for the neovim project.
I'm honestly shocked at how fantastic Helix is and it makes me wonder if all the toil of inheriting vim was worth it for the neovim project.
Gave Helix a try recently and liked it. Much better out of box experience.
Something like a readymade nvim config should ideally be able to provide similar experience but it's hard to not get caught up in the the quest to get it _just right_
Plus Vim keybindings are widely available in popular editors/IDEs but I think Helix bindings will take a while to get there.
Something like a readymade nvim config should ideally be able to provide similar experience but it's hard to not get caught up in the the quest to get it _just right_
Plus Vim keybindings are widely available in popular editors/IDEs but I think Helix bindings will take a while to get there.
Anyone who wants to get started with LSP in Vim8/9, I've found following plugins useful.
a. https://github.com/yegappan/lsp [this is newer plugin and hence there few issues]
b. https://github.com/prabirshrestha/vim-lsp
I recently discovered the neovim plugin for VSCode. It’s fantastic. A step up over the built in key-bindings.
What a peculiar statement. I’ve been using vim as my go-to editor for most of my 10-year career as a software developer. I am very productive. I haven’t read said book.
I haven't read it and I use Vim every day. Like any skill, just learn as you go. A couple of times a week I google for how to do something I figure is possible, then I save the link in a bookmarks folder.
I might read it at this point and learn a lot, but I'm still happy and productive with what I do know.
I might read it at this point and learn a lot, but I'm still happy and productive with what I do know.
Vim is neither a text editor nor a code editor.
Vim is a language. To speak Vim is to speak in a way with your hands that turns words into action and moves text at the speed of thought.
I have long mastered Vim after over a decade of experience. I can barely tell you what keys I’m pressing, but when I imagine some text in my head and how I’d want to change it, I feel the force at the ends of my fingers that guides my hands until the modification is done.
Much like how you can speak to express an idea without having to think about the way your mouth moves, I can easily edit blocks of code without really knowing how my hands will move, I simply trust they will do what I need and it happens. Vim has become the interface by which my mind can directly immerse itself into the conversation of code on a screen. Most will never understand the feeling of this power unless they deliberately pursue deep mastery of Vim, but once you’ve gotten a taste of it, it becomes intoxicating.
Vim is well worth investing your time in. I guarantee it is one technology that will exist for the rest of your career. The year will be 2100, and Vim will still be around and in use by the best engineers.
Vim is a language. To speak Vim is to speak in a way with your hands that turns words into action and moves text at the speed of thought.
I have long mastered Vim after over a decade of experience. I can barely tell you what keys I’m pressing, but when I imagine some text in my head and how I’d want to change it, I feel the force at the ends of my fingers that guides my hands until the modification is done.
Much like how you can speak to express an idea without having to think about the way your mouth moves, I can easily edit blocks of code without really knowing how my hands will move, I simply trust they will do what I need and it happens. Vim has become the interface by which my mind can directly immerse itself into the conversation of code on a screen. Most will never understand the feeling of this power unless they deliberately pursue deep mastery of Vim, but once you’ve gotten a taste of it, it becomes intoxicating.
Vim is well worth investing your time in. I guarantee it is one technology that will exist for the rest of your career. The year will be 2100, and Vim will still be around and in use by the best engineers.
What do you think of using vim plugins inside an IDE, such as IdeaVIM? How much of the benefits of what you describe do you think would remain?
I've been trying to spend more time in vim since last year because I can imagine a world with the benefits you describe, and I want to put in the long-run investment to get there. But at the same time, Vim naturally lacks the feature set of an IDE, and setting up a bunch of plug-ins so that they all work together is somewhat time consuming and brittle.
I've been wondering if I should stick to Jetbrains/VS Code and use Vim as a text manipulation language, and whether I'd still attain that editing fluency you describe.
I've been trying to spend more time in vim since last year because I can imagine a world with the benefits you describe, and I want to put in the long-run investment to get there. But at the same time, Vim naturally lacks the feature set of an IDE, and setting up a bunch of plug-ins so that they all work together is somewhat time consuming and brittle.
I've been wondering if I should stick to Jetbrains/VS Code and use Vim as a text manipulation language, and whether I'd still attain that editing fluency you describe.
Plug-ins are always a personal choice. For me the most essential is fuzzy finder with ctrl-P. With this I can arrive at any file or line in a massive codebase damn near instantly.
I find vim with the right plugins is as capable as any IDE, you can at least have the basics like autocomplete and various syntax highlighters and linters. Personally I think developers who lean heavily on the IDE features of more common tools are using it as a crutch for not knowing the codebase very well or language features.
Part of the journey to vim mastery is the configuration of vim until it fits you like a glove, once you’ve configured it well you rarely need to touch the config files again.
I find vim with the right plugins is as capable as any IDE, you can at least have the basics like autocomplete and various syntax highlighters and linters. Personally I think developers who lean heavily on the IDE features of more common tools are using it as a crutch for not knowing the codebase very well or language features.
Part of the journey to vim mastery is the configuration of vim until it fits you like a glove, once you’ve configured it well you rarely need to touch the config files again.
Practical Vim is worthwhile.
Unfortunately, I had to put it down to read the 695,378 word Vim manual.
Or at least, the 33,807 word core essentials.
Approachability is... not Vim.
Especially when both the manual and Practical Vim to absorb "how to use it" are a such a necessity.
Unfortunately, I had to put it down to read the 695,378 word Vim manual.
Or at least, the 33,807 word core essentials.
Approachability is... not Vim.
Especially when both the manual and Practical Vim to absorb "how to use it" are a such a necessity.
I didn’t read either Practical Vim or the docs before becoming pretty proficient with Vim.
Some good blog posts and some videos did it for me. I had enough knowledge to make diving into the docs more meaningful.
Besides once you understand the language of Vim, it’s not hard to make strives.
Some good blog posts and some videos did it for me. I had enough knowledge to make diving into the docs more meaningful.
Besides once you understand the language of Vim, it’s not hard to make strives.
You can get vim keybindings for Intellij so you get all the IDE stuff too.
If the overall "on steroid" metaphor is on how Vim will improve typing performance and give an edge over organically growing your keyboard commanding abilities but lead to early health problems...I totally agree with the title (also a good piece with good advices otherwise).
Vim was my primary editor for a bunch of years, and it's definitely fast and helps to utilize keyboard commands to the maximum extent. That's also the years I started getting RSI, changed a lot of habits, keyboards, postures etc. to come to the conclusion that the real issue was plainly doing the same movements over and over.
As a data point of n=1, optimizing workflows for maximal productivity meant doing the same optimized actions again and again, and do them fast. Which wasn't good. Reducing "productivity" and introducing more input methods that I can switch to here and there when I feel like it helped a lot. So less touch typing marathons, less shortcuts, more GUI and more variety overall.
Vim was my primary editor for a bunch of years, and it's definitely fast and helps to utilize keyboard commands to the maximum extent. That's also the years I started getting RSI, changed a lot of habits, keyboards, postures etc. to come to the conclusion that the real issue was plainly doing the same movements over and over.
As a data point of n=1, optimizing workflows for maximal productivity meant doing the same optimized actions again and again, and do them fast. Which wasn't good. Reducing "productivity" and introducing more input methods that I can switch to here and there when I feel like it helped a lot. So less touch typing marathons, less shortcuts, more GUI and more variety overall.
As a counter data point, I switched to vim precisely because constantly reaching for the mouse was causing my problems. I switched to a vertical mouse for a while and it helped, but still had problems. I switched to a connected split keyboard (Microsoft Natural Ergonomic Keyboard 4000) and now use a fully split keyboard (moonlander).
Having the keyboard tilted and each half far away so that my shoulders aren't rotated inward was a huge win for me.
But I guess when I was using the mouse, I wasn't "slow". I would "rapidly" switch from keyboard to mouse as fast as I could. The longer it takes me to get something from my head onto the screen, the more distracting and exhausting I find it.
Eventually there will probably be neural links, and you just think something and it happens. Until then, vim is as close as I can get it.
Having the keyboard tilted and each half far away so that my shoulders aren't rotated inward was a huge win for me.
But I guess when I was using the mouse, I wasn't "slow". I would "rapidly" switch from keyboard to mouse as fast as I could. The longer it takes me to get something from my head onto the screen, the more distracting and exhausting I find it.
Eventually there will probably be neural links, and you just think something and it happens. Until then, vim is as close as I can get it.
I got over the productive porn real quick when I figured out that given little more than say, line numbers and syntax highlighting, the bottleneck is already thinking speed and not editing speed.
When you're using the keyboard, are you, for lack of a better word, very "tense" when pressing the keys? Do you "peck" at them with very brief, high-force pulses?
Among those I know who've complained about RSI and the like, the common trend I've noticed is how they press the keys --- very abruptly and probably with far more force than necessary.
I've been using vi for literally decades so I don't think it's to blame. I average 140-150wpm on prose and can type all day at that speed.
Among those I know who've complained about RSI and the like, the common trend I've noticed is how they press the keys --- very abruptly and probably with far more force than necessary.
I've been using vi for literally decades so I don't think it's to blame. I average 140-150wpm on prose and can type all day at that speed.
Yes, you're spot on. I was using a mildly stiff, mechanical split keyboard while having relatively weak fingers.
Stopped using it and switch to a low profile chiclet keyboard where I was using way less strength, and could type more loosely. It also made it way easier to type on glass, as an unintended side effect.
Switching to a trackpad also helped in interesting ways, as I got rid of many keyboard shortcuts for page navigation, app switching etc. and moved to gestures instead.
To note, I still use vim a lot. Just not as my main editor. Also the changes I made are probably very personal and wouldn't have the same effect on other people with different tendencies.
Stopped using it and switch to a low profile chiclet keyboard where I was using way less strength, and could type more loosely. It also made it way easier to type on glass, as an unintended side effect.
Switching to a trackpad also helped in interesting ways, as I got rid of many keyboard shortcuts for page navigation, app switching etc. and moved to gestures instead.
To note, I still use vim a lot. Just not as my main editor. Also the changes I made are probably very personal and wouldn't have the same effect on other people with different tendencies.
Just curious, would/do you do a lot of pinkie stretch movements i.e. to hit ctrl? I've remapped using autohotkey ctrl to caps lock on my personal computer and its a godsend to bypass this. I seriously think this should've been the convention. I wish I could enable it on my locked down work laptop.
Worth noting Microsoft actually distributes an "official" (quotes cause it was made by an employee seemingly out of their own desire, but it's distributed on MS's website) program that maps ctrl to capslock. Aptly named, Ctrl2cap [1]
Thought they really ought to just let you do this out of the box already. macOS lets you map modifier keys to other functions just in the regular old system settings.
[1] https://learn.microsoft.com/en-us/sysinternals/downloads/ctr...
Thought they really ought to just let you do this out of the box already. macOS lets you map modifier keys to other functions just in the regular old system settings.
[1] https://learn.microsoft.com/en-us/sysinternals/downloads/ctr...
It was, then as usual IBM mucked it up. The only thing worse might be the Amiga layout… letter width capslock to the left of A, and then a 1.25 width ctrl directly to the left of that.
I did a lot of changes, so which one would have sufficed is hard to tell (in exchange I have absolutely no RSI left).
I use keyboards with extra keys so the esc key was always mapped pretty near. With IME languages an ESC+language switch shortcuts is absolutely needed anyway (at least for vim users)
I use keyboards with extra keys so the esc key was always mapped pretty near. With IME languages an ESC+language switch shortcuts is absolutely needed anyway (at least for vim users)
> That's also the years I started getting RSI, changed a lot of habits, keyboards, postures etc. to come to the conclusion that the real issue was plainly doing the same movements over and over.
I started getting RSI. Not really from coding, but from mouse use in games like Quake and Half-Life. My fix was actually to start riding a bicycle, and getting in general more fit, going to the gym, etc. RSI disappeared as I got more fit. The real issue is to live a sedentary life without enough bit muscles movements.
I started getting RSI. Not really from coding, but from mouse use in games like Quake and Half-Life. My fix was actually to start riding a bicycle, and getting in general more fit, going to the gym, etc. RSI disappeared as I got more fit. The real issue is to live a sedentary life without enough bit muscles movements.
For anyone not understanding why (neo)vim exists, or why some developers prefer it to IDEs, I suggest watching "PDE: A different take on editing code" [1]. It reframes (neo)vim as a "Personalized Development Environment".
I've been using (neo)vim for years, and don't want to use anything else. It isn't just about productivity (I would probably be as productive in an IDE). It's because its _mine_. It's a highly customized environment, catered to my needs.
[1] https://www.youtube.com/watch?v=QMVIJhC9Veg&
I've been using (neo)vim for years, and don't want to use anything else. It isn't just about productivity (I would probably be as productive in an IDE). It's because its _mine_. It's a highly customized environment, catered to my needs.
[1] https://www.youtube.com/watch?v=QMVIJhC9Veg&
Still complex for me, even after reading the author's tutorial and suggestions.
Between hjkl, w, l, d, dd, esc, :command, and more modes I feel like I'll never grok vim.
After how many years do I throw in the towel and just stick with VS Code? Been at it since 2008 in some form or another :(
Between hjkl, w, l, d, dd, esc, :command, and more modes I feel like I'll never grok vim.
After how many years do I throw in the towel and just stick with VS Code? Been at it since 2008 in some form or another :(
I have been using Vim since almost day 1 of learning how to code and I honestly have never used 90% of Vim's features.
For hjkl I just used arrow keys since they are nicer and I dont find much difference between them.
For modes I only learned about Normal, Insert and Visual. No more than that.
You could say my Vim editing is extremely ineffective, but it is effective enough for me.
For hjkl I just used arrow keys since they are nicer and I dont find much difference between them.
For modes I only learned about Normal, Insert and Visual. No more than that.
You could say my Vim editing is extremely ineffective, but it is effective enough for me.
I think this is the answer. I started using vi 33 years ago and initially learned just what I needed to know. As time went on I learned more commands.
If I wanted to erase a word in a sentence, which had seven letters, initially I might type x eight times (erase the word and a space). Then as I learned more vi I might type 7x. As I learned more vi I might type dw.
You can get a lot of navigation and editing done just knowing a few commands in vi. If you use it a lot, you can learn more commands and have an easier time.
About 7-8 years ago the standard IDE for my programming niche changed, and I had to learn a new IDE and what I knew of the old IDE I have almost never used since. The vi stuff I learned 30 years ago I am still using.
If I wanted to erase a word in a sentence, which had seven letters, initially I might type x eight times (erase the word and a space). Then as I learned more vi I might type 7x. As I learned more vi I might type dw.
You can get a lot of navigation and editing done just knowing a few commands in vi. If you use it a lot, you can learn more commands and have an easier time.
About 7-8 years ago the standard IDE for my programming niche changed, and I had to learn a new IDE and what I knew of the old IDE I have almost never used since. The vi stuff I learned 30 years ago I am still using.
> For hjkl I just used arrow keys since they are nicer and I dont find much difference between them.
The point of hjkl is to keep your fingers in the home row of your keyboard. This is generally accepted to be good typing practice as it improves speed.
The point of hjkl is to keep your fingers in the home row of your keyboard. This is generally accepted to be good typing practice as it improves speed.
>> The point of hjkl is to keep your fingers in the home row of your keyboard. This is generally accepted to be good typing practice as it improves speed.
You might get some benefit to speed if you keep your hands on the home row, or you might not. This is mostly something people have been repeating as gospel, but I'm not aware of anyone testing it.
Intuitively, using the arrow keys to move the cursor without inserting a character should be faster. Assuming one is moving around the text while editing, it takes at least three keypresses to use hjkl to move the cursor without inserting a character: one to switch to command mode, one to move the cursor, and one to switch back to insert mode. That's because hjkl in insert mode simply insert their respective letters. By contrast, using the arrow keys to move the cursor without inserting a character needs one keypress: to press an arrow key.
Even if you count moving your hand to the arrow keys and back as two distinct "operations", and each keypress as a single operation, it takes at least three operations to use the arrow keys (i.e. as many as using hjkl): one to move a hand to the arrow keys, one to press a key, and one to move the hand back. Assuming that each operation takes constant time, that means that, at best, there is no advantage over keeping your hands at the home row and moving the cursor with hjkl, than using the arrow keys.
So that idea, that it's faster to keep one's hands in the home row, must be a superstition.
Incidentally, I've been using vim continuously since 2011. These days at work I use a Spanish QWERTY keyboard, but with an English Euro layout. I got the Spanish keyboard by mistake and it was simpler to keep using it with the layout I know, and benefit from more than a decade of muscle memory, than to try and learn the new key positions (and combinations). This is another reason why I am skeptical of the claim about the home row: muscle memory is faster than any spatial optimisation you may think of, or, rather, if you've already learned to move your hands one way and can do it fast, changing to a new way will slow you down, first. And then we're talking about long-term gains of maybe a few milliseconds in the long term in this case. That sounds pointless.
You might get some benefit to speed if you keep your hands on the home row, or you might not. This is mostly something people have been repeating as gospel, but I'm not aware of anyone testing it.
Intuitively, using the arrow keys to move the cursor without inserting a character should be faster. Assuming one is moving around the text while editing, it takes at least three keypresses to use hjkl to move the cursor without inserting a character: one to switch to command mode, one to move the cursor, and one to switch back to insert mode. That's because hjkl in insert mode simply insert their respective letters. By contrast, using the arrow keys to move the cursor without inserting a character needs one keypress: to press an arrow key.
Even if you count moving your hand to the arrow keys and back as two distinct "operations", and each keypress as a single operation, it takes at least three operations to use the arrow keys (i.e. as many as using hjkl): one to move a hand to the arrow keys, one to press a key, and one to move the hand back. Assuming that each operation takes constant time, that means that, at best, there is no advantage over keeping your hands at the home row and moving the cursor with hjkl, than using the arrow keys.
So that idea, that it's faster to keep one's hands in the home row, must be a superstition.
Incidentally, I've been using vim continuously since 2011. These days at work I use a Spanish QWERTY keyboard, but with an English Euro layout. I got the Spanish keyboard by mistake and it was simpler to keep using it with the layout I know, and benefit from more than a decade of muscle memory, than to try and learn the new key positions (and combinations). This is another reason why I am skeptical of the claim about the home row: muscle memory is faster than any spatial optimisation you may think of, or, rather, if you've already learned to move your hands one way and can do it fast, changing to a new way will slow you down, first. And then we're talking about long-term gains of maybe a few milliseconds in the long term in this case. That sounds pointless.
I tried to use the hjkl key bindings, I hated them, and since I remember, I also use the arrow keys.
The keys are positioned differently, and that helps me with muscle memory.
The fact they are not in a row is a feature.
Of course, I am also a touch typist and I wrote this entire comment without looking at the keyboard or making a single mistake.
The keys are positioned differently, and that helps me with muscle memory.
The fact they are not in a row is a feature.
Of course, I am also a touch typist and I wrote this entire comment without looking at the keyboard or making a single mistake.
> but I'm not aware of anyone testing it.
It definitely worked for me. YMMV
Don't toss it till you try it.
It definitely worked for me. YMMV
Don't toss it till you try it.
Not only that, it is more ergonomic -- if you can get the same thing done without moving your arm so much, it reduces the strain.
It is for this exact reason I am using vim in VSCode. I get some speed up in vim vs mastering VSCode shortcuts, but not enough that would make me switch. However, with vim I hardly need to move my arm over to use arrow keys or mouse, which makes it much easier on my hands and my arm.
It is for this exact reason I am using vim in VSCode. I get some speed up in vim vs mastering VSCode shortcuts, but not enough that would make me switch. However, with vim I hardly need to move my arm over to use arrow keys or mouse, which makes it much easier on my hands and my arm.
I remap to jkl; to be even more home-row efficient (and less RSI-inducing). I wish I did that decades ago.
I found this extremely useful to learn Vim https://github.com/iggredible/Learn-Vim
I first tried the wrong way to learn Vim: memorizing keybindings. That's not helpful at all.
Write way to learn Vim: understanding Vim "grammar" as this repo teaches.
I first tried the wrong way to learn Vim: memorizing keybindings. That's not helpful at all.
Write way to learn Vim: understanding Vim "grammar" as this repo teaches.
I remember for the first two weeks (maybe a month? it was so long ago) learning vim was painful as hell. I had to fight the urge to just stick with non-vim mode typing like in default vscode.
Despite that I willed myself to continue using vim because of the plethora of praise it had, and the promised eternal benefits I will be blessed with, so say the evangelists.
After that it was a breath of fresh air to be able to type at the speed of thought. I would never dream of going back to non-modal editing again.
Now I'm using evil/emacs and couldn't be happier. There's another modal editing that's gaining traction called meow, and maybe other variants that I want to learn. But for now I'll stick with evil/vim-mode.
Despite that I willed myself to continue using vim because of the plethora of praise it had, and the promised eternal benefits I will be blessed with, so say the evangelists.
After that it was a breath of fresh air to be able to type at the speed of thought. I would never dream of going back to non-modal editing again.
Now I'm using evil/emacs and couldn't be happier. There's another modal editing that's gaining traction called meow, and maybe other variants that I want to learn. But for now I'll stick with evil/vim-mode.
Using both when it makes sense should be the best ?
I've seen many coworkers(me included) switch from vim to IDEs, but still use it here and there. I think vim alone makes less sense in our current environments where we're constantly interfacing with many different systems: In my case I need SCM status, a command prompt at any time, docker container status and commands, quick local to remote file transfer, local and remote linting (don't use the same rules) and image previewing.
I could probably make a vim + terminal setup that brings me 99% there, but it just doesn't make sense as a time investment TBH. And buttons to click are nice, really.
I've seen many coworkers(me included) switch from vim to IDEs, but still use it here and there. I think vim alone makes less sense in our current environments where we're constantly interfacing with many different systems: In my case I need SCM status, a command prompt at any time, docker container status and commands, quick local to remote file transfer, local and remote linting (don't use the same rules) and image previewing.
I could probably make a vim + terminal setup that brings me 99% there, but it just doesn't make sense as a time investment TBH. And buttons to click are nice, really.
I was like that, then for 2 months I decided I would use vim to do everything and use absolutely nothing else to edit text, this is when I had joined a new company and ramping up.
About 5 weeks in I ceased trying to make Java work with vim and have been using intellij (with vim binding) for Java and Kotlin. But kept using vim for everything else, which is roughly 50% of work load and stretches several different language and config formats.
Have been using vim ever since, the cliff is the hardest part, but it was totally worth it.
About 5 weeks in I ceased trying to make Java work with vim and have been using intellij (with vim binding) for Java and Kotlin. But kept using vim for everything else, which is roughly 50% of work load and stretches several different language and config formats.
Have been using vim ever since, the cliff is the hardest part, but it was totally worth it.
I think it’s common to get overwhelmed with all of vims features. For me, focusing on one thing at a time helped. For example, spend a day where instead of repeatedly doing: A,<esc>j to add commas to the end of lines, learn to do it in visual block mode. It’ll be annoying and fiddly the first 5 times. But it quickly becomes muscle memory.
That said, if you’ve been trying vim seriously for ~15 years, maybe it just isn’t your thing.
That said, if you’ve been trying vim seriously for ~15 years, maybe it just isn’t your thing.
> if you’ve been trying vim seriously for ~15 years
To clarify and to be fair to vim, it's a few days to a little over a week of effort every 8 months to two years or so. I'll get the bug to ascend in my coding speed after reading an article like this one, check to see if I still have .vimrc from the last time I tried to configure it for things like syntax highlighting, spaces instead of tabs, etc., then give it a roll.
To clarify and to be fair to vim, it's a few days to a little over a week of effort every 8 months to two years or so. I'll get the bug to ascend in my coding speed after reading an article like this one, check to see if I still have .vimrc from the last time I tried to configure it for things like syntax highlighting, spaces instead of tabs, etc., then give it a roll.
I tried from 2013 to 2018, even going so far as to change zsh to using vim bindings and then I threw in the towel and switched to Emacs. While Elisp isn't the nicest Lisp around it's a lot nicer than vimscript, lua, or javascript.
Check out spacemacs or doom emacs!
Vim has the best interface, but it's built on a pretty awful program. Emacs is a pretty awful interface built on a pretty great program. Combine the two!
Vim has the best interface, but it's built on a pretty awful program. Emacs is a pretty awful interface built on a pretty great program. Combine the two!
I use vim in VS Code - best of both worlds :)
I'm one of those that knows a good deal of Vim and Emacs, and moved to VSCode and felt things just work better there.
The pattern nowadays for me always goes like this:
The pattern nowadays for me always goes like this:
1. Let me try Vim again. I do miss that kind of efficiency
2. This is so fun, I really missed it (for a few minutes or hours)
3. And then *one little comfort* from VSCode is missing... and I'm back on VSCode for months.
Naah. I gave up on Vim years ago. I think I’d rather like to do other things than dealing with ikljhploxty :g or whatever those commands are et cetera. I realised for my use-case and the work I do, and for the time I actually spent writing/typing code, those trillions of IDEs and gui text editors are not only enough, they are absolutely better.
I am sure it would be some revolutionary tool, but I have no use for it other than using vi when I ssh into somewhere for few minutes once in a blue moon. This realisation has been very useful. In the past I kept trying to “get” vim. On the other hand a lot of people I know like vim as a “hobby”. Yes, liking vim and doing vim thingies is the hobby.
I am sure it would be some revolutionary tool, but I have no use for it other than using vi when I ssh into somewhere for few minutes once in a blue moon. This realisation has been very useful. In the past I kept trying to “get” vim. On the other hand a lot of people I know like vim as a “hobby”. Yes, liking vim and doing vim thingies is the hobby.
[deleted]
My Vim experience got much better when I added this to my config:
I also added the following to remove the highlights that appear (e.g., when pressing *):
vim.keymap.set("n", "<leader>sr", ":%s//")
I also added the following to remove the highlights that appear (e.g., when pressing *):
vim.cmd("nnoremap <silent> <c-c> :nohl<CR><C-l>")Try mapping it to `:set hlsearch!`. That way you can use the same mapping to toggle it on and off as you wish.
EDIT: Also, you can use vim.keymap.set, no need for a vim command, just `vim.keymap.set("n", "<c-c>", "<cmd>set hlsearch!<CR>", {silent = true})`
EDIT: Also, you can use vim.keymap.set, no need for a vim command, just `vim.keymap.set("n", "<c-c>", "<cmd>set hlsearch!<CR>", {silent = true})`
This is a timely post as I've been trying to use Vim more since last year, and recently started a new project with the aim of working exclusively in Vim. And I'm torn.
On the one hand I want to significantly increase how fast I can manipulate and edit text without reaching for my mouse, a state which many commentors here seem to have attained.
On the other, I miss the way that a Jetbrains IDE cohesively integrates a lot of features with non-conflicting hotkeys, without requiring me to fiddle around with a vimrc - great code analysis, Git, database schemas, etc.
I'm tempted by the promise of a plugin like IdeaVIM, which seems like it's 90% of the experience - but that'd still sacrifice the easy integration with my terminal setup, fzf, being able to switch between panes with my keyboard, etc. Does getting 90% of the way to being keyboard-free really give you 90% of the benefits?
Any tips appreciated :)
On the one hand I want to significantly increase how fast I can manipulate and edit text without reaching for my mouse, a state which many commentors here seem to have attained.
On the other, I miss the way that a Jetbrains IDE cohesively integrates a lot of features with non-conflicting hotkeys, without requiring me to fiddle around with a vimrc - great code analysis, Git, database schemas, etc.
I'm tempted by the promise of a plugin like IdeaVIM, which seems like it's 90% of the experience - but that'd still sacrifice the easy integration with my terminal setup, fzf, being able to switch between panes with my keyboard, etc. Does getting 90% of the way to being keyboard-free really give you 90% of the benefits?
Any tips appreciated :)
Vim use can cause increased irritability and aggression? Yes, that makes sense. https://nida.nih.gov/publications/research-reports/steroids-...
Vim isn't a CLI based editor. An editor like ed is.
Vim isn't the only editor with shortcuts. Many of the IDEs listed come with pretty of shortcuts and you can configure more if you want. Those editors also let you use shortcuts without having to switch through different modes making you more efficient.
Vim isn't the only editor with shortcuts. Many of the IDEs listed come with pretty of shortcuts and you can configure more if you want. Those editors also let you use shortcuts without having to switch through different modes making you more efficient.
The advantage of vim isn't just shortcuts. It's the ability to compose movements with editing commands. For example, da" cuts text enclosed in quotes. ct; changes text up to but not including the next semicolon. Every movement command works this way with every editing command.
For me, the other big advantages are staying on the home row as much as possible and reducing chord shortcuts. I used to use Emacs but pain in my left wrist led me to search for a way of editing code without Mod+Key on one hand. I have some custom keymaps in vim that allow me to move to the start/end of a line with Shift+H and Shift+L, move up/down code blocks with Shift+K and Shift+J, and page up/down with Ctrl+K and Ctrl+J. In most standard editors, I find moving my right hand to the arrow keys and home/end to be unreasonably slow and error-prone in comparison.
That said, I'm not an evangelist. I don't care what editor other people use and I'm not sentimental about vim. It's a dinosaur with a lot of legacy cruft and I would switch to something else if I could reproduce a similar setup.
For me, the other big advantages are staying on the home row as much as possible and reducing chord shortcuts. I used to use Emacs but pain in my left wrist led me to search for a way of editing code without Mod+Key on one hand. I have some custom keymaps in vim that allow me to move to the start/end of a line with Shift+H and Shift+L, move up/down code blocks with Shift+K and Shift+J, and page up/down with Ctrl+K and Ctrl+J. In most standard editors, I find moving my right hand to the arrow keys and home/end to be unreasonably slow and error-prone in comparison.
That said, I'm not an evangelist. I don't care what editor other people use and I'm not sentimental about vim. It's a dinosaur with a lot of legacy cruft and I would switch to something else if I could reproduce a similar setup.
Without wanting to sound condescending, you don’t understand modal editing. Working in different modes accelerates rather than retards efficiency. It’s worth knowing about for intellectual curiosity, even if you don’t care to use it. Google “you don’t grok vi” for a quick and interesting read.
>Google “you don’t grok vi” for a quick and interesting read.
None of this requires a separate mode to do. Modifier keys have been shown to be enough to give commands for doing operations other than inserting characters.
None of this requires a separate mode to do. Modifier keys have been shown to be enough to give commands for doing operations other than inserting characters.
>Those editors also let you use shortcuts without having to switch through different modes making you more efficient.
The modes are what makes editing in Vim efficient.. you don't think Vim users are out here swapping through modes looking for the one that lets them paste a line do you?
The modes are what makes editing in Vim efficient.. you don't think Vim users are out here swapping through modes looking for the one that lets them paste a line do you?
Yes. Instead of just control + v they have to switch out of insert mode and into normal mode, then do a command to paste their clipboard, then have to do a command to go back to insert mode. It's overcomplicated.
They just press ctrl+alt+v in insert mode or if they are in normal mode they will press p.
See. There is to point to have normal mode if you can just do it in insert mode.
You do not seem to have a grasp on Vim which qualifies you to assert that it is overcomplicated.
I do have a grasp on Vim. Even if I didn't the fact you used the term grasp shows that it is overcomplicated. A text editor should have such good ui that one instantly grasps it.
I've been using vim for the last 6 years because most of my early projects at my job involved PuTTY-ing directly to Solaris and RHEL servers to do dev work (mostly shell scripting and PHP).
I don't do anything particularly sophisticated with it; recording macros to repeat the same transformation on multiple lines is about my limit. But I love being able to work with my hands permanently on the home row of the keyboard, and having to switch between keyboard and mouse with other software feels like a chore now.
Sadly these days I mostly make Mulesoft applications using Anypoint Studio. I still use it for most of my text editing at home at least.
I don't do anything particularly sophisticated with it; recording macros to repeat the same transformation on multiple lines is about my limit. But I love being able to work with my hands permanently on the home row of the keyboard, and having to switch between keyboard and mouse with other software feels like a chore now.
Sadly these days I mostly make Mulesoft applications using Anypoint Studio. I still use it for most of my text editing at home at least.
Vim is an REPL stacked on a real time database that is a buffer.
Vim keybindings are like a Huffman encoding for expressing text manipulation operations.
die hard vim user here, can't live without it, keyboard is all I need these days, I only use my mouse every 1 minute per hour these days, on ubuntu, productivity is higher than IDE for sure. and yes vimium for browering.
When I "program", 95% of what I do is read documentation and other technical resources, conceptualize what I want to happen, and construct the corresponding logic flow, while trying to anticipate potential problems and corner cases. In other words, most of what I do doesn't involve touching the keyboard at all.
If Vim magically tripled the speed at which I'm able to edit text, I doubt it would have a noticeable impact on my overall productivity. In fact, even if you gave me a brain-computer interface that allowed me to manipulate text at the speed of thought, it wouldn't matter much. I touch-type at around 70 WPM, which is very average, but if I two-finger typed at 15 WPM instead I would still be able to produce exactly as much code as I do today.
Simply put, text manipulation is not at all a productivity bottleneck for me. I need much more time for thinking about code than I need for writing it.
Is this really unusual? How do people operate for whom Vim gives a productivity boost? Does code just flow from their brains into their fingers? I don't get it.