I feel pretty conflicted about the notion that moving from touching the keyboard to the mouse is a loss of focus.
I bought the notion earlier of course when I was really getting into Vim, but then I seriously tried just using the mouse and I found that it didn’t really make that much of a difference for me. As a result, I find it hard to believe the idea that the ‘context switch’ is really that meaningful.
I think it’s all about how the editor fits your brain. If it fits, great. If not, try something else. For me, vim’s keyboard focus is really enjoyable, and I think we’re more productive with things we like.
I think I could get to the point where I reach for the mouse instinctively, but with vim I never think about vim, it’s like walking, and when I use something else, reaching for the mouse is only triggered by being snapped out of everything being pure muscle memory. I think it’s possible the mouse just becomes another motion, but it’s hard to actually imagine since it’s so far away.
I disagree pretty strongly… Vim editing is a discipline, this is not something you will intuitively be good at, it takes months of labor to even be sort of okay at it.
There’s nothing inherently wrong with touching a mouse, but the combination of gross+fine motor control it requires necessarily means you are slowing down your interaction with the machine by at least an order of magnitude, and that increases the risk of being knocked out of the flow state.
Keyboard-driven development in Vim is the only time my editor has felt like an extension of my mind.
I agree with that. Vim is a discipline, and takes a while to get proficient, with it’s rewards being cumulative over time.
My point about enjoying Vim is that I believe that is at the core of why I use it. There are many productive tools, but I stuck with Vim’s learning curve because I enjoyed it, because it fit my brain. Even though learning it was difficult, I was still enjoying the process of learning it, and I don’t think I would have continued to if I hadn’t. For example, I tried Emacs, and didn’t stick with it because it didn’t fit my brain as well, and hence I didn’t enjoy using it as much.
Doesn’t make a big difference for me either, but I think Vim is more fun and feels less like work. Even if it isn’t actually any faster (for me at least), it’s just fun and satisfying to string together editing commands in a way that clicking and dragging isn’t. Tickles the brain just right.
The keyboard feels more “deterministic” than the mouse because I don’t have to aim, I just, well, type the letters. Similarly, vim commands better reflect what I want than selecting the right number of characters with a mouse does. (E.g., if I want to delete a section of text, and I see the word “something” immediately after, I can use d/something. Lots of motions like that reflect how I think of the text I’m editing.)
When I’m at a desk, going for the mouse isn’t a terrible disruption. On a laptop? I hate fiddling with text using a trackpad. Maybe I’m just old, but it feels like working with oven mitts on. Not having to do that is invaluable. Having to use the trackpad (even the ThinkPad pointer) is a cognitive switch.
But, I’ve used Vim for decades. 20-something me, before Vim, might’ve felt differently.
I could believe that the physical context switch—moving your hand from the keyboard to the mouse—has the potential to add some delay. But that’s only if you’re very proficient with the keyboard. If you want to move the cursor somewhere else in the document, but it takes you half a second to decide how to do that using the keyboard, you probably would’ve been better off just using the mouse.
I’ve been using Vim for 20 years, and while I’m comfortable using just the keyboard (when Vim is running in a terminal), I feel like I’m faster when I can also use the mouse (in MacVim).
I agree. I HATE having to interrupt my thoughts to decide how to navigate in my editor. Whether that happens frequently is going to vary from person to person …
and I bet that almost everything mentioned in this discussion varies wildly from person to person. I don’t mean that it’s just a matter of taste. I expect there are interesting reasons for all the variation. The variation between people is the sort of thing I would expect to be very very complicated.
I don’t think it’s the movement between the keyboard and the mouse that causes a “loss of focus” or a “context switch”: it’s the mental shift from vim-command-mode to GUI-desktop-mode. These are two different ways of interacting with a computer. In another comment here, @susam describes how switching from Emacs to a different GUI application “disrupts the flow”. Again, I don’t think it’s really about keyboard versus mouse: I think it’s more about two different cohesive models for controlling a computer.
I’ve used Vim for more than twenty years now and I think I’m pretty proficient at it. I don’t really think about how to control it, I just think of the change that I want to make to the text and my fingers automatically express that as Vim commands. The Vim command language is seared into my muscle memory. This has served me really well for a large part of my career, which I have spent using Vim and other teletype-terminal programs in tmux (and Screen before that).
However, these days, I find that I have to use a lot of other GUI desktop applications too - I can’t live in tmux any more - and I find the context switches between Vim and the rest of my desktop really jarring. The same modal command language that used to keep me in the flow now disrupts my flow!
So I recently decided to give up Vim and try a text editor that obeys the same modern desktop idioms as all the other GUI applications that I have to use for work. It’s taken me a few months to get used to it but I’m now glad that I made the switch: I no longer have to suffer jarring context switches every time I change between my text editor and my other tools.
Just the other day, I found myself having to make a load of edits to a configuration file: this was just pure text editing work. I felt like I was going so slowly, constantly grabbing the mouse to select some text, then going back to the keyboard to type. It was the sort of thing that I could do in no time, almost without thinking, in Vim. So I thought I’d test that: I undid all my changes then used a screen recorder to time myself doing them all again. Then I undid them and recorded myself doing it in Vim. It wasn’t really a fair comparison - since I’d already done all the tasks twice by the time I did them again in Vim - but I thought it would be interesting to see how much faster I was in Vim anyway. To my surprise, when I checked the recordings I found that I was faster using the mouse!
Anyway, different people will have different preferences, but I think it will also depend on the type of work that you’re doing. When I used to live in tmux, Vim was great. Now that I no longer have to work over SSH but I do have to use other GUI desktop applications, I prefer something else. I also found it interesting that my perception of my editing efficiency was quite different from the empirical measurements… but maybe that’s just me.
I do find it clumsy to context switch between keyboard-driven work and mouse-based work. Let me share a very recent example. Only yesterday, I was doing source code walkthrough of a new software project for someone else using my Emacs. I could do most of the code walkthrough merely by touch-typing on my keyboard.
I could hop around to different sections of the source code (movement commands), search for files containing specific identifiers or strings (project commands), hop between files (buffer commands), start/restart Docker containers (M-x eshell), run arbitrary shell commands (M-x eshell again), create new files with experimental code to test out ideas, etc. all from within Emacs, using nothing but the keyboard with my fingers relaxed comfortably on the home row most of the time, touch-typing away as I command Emacs to assist me in navigating through the code and testing out ideas.
But every once in a while, I would be forced to move my hand away from the keyboard to the mouse nearby in order to move the mouse pointer over to another GUI application to look up something. Each time I had to make this transition, it disrupted the “flow” and felt cumbersome, highlighting the disparity between the smooth keyboard-driven workflow within Emacs and the clumsy mouse-based navigation outside of it.
While I appreciate that not everyone shares the same experience as mine, and that’s perfectly fine, for me, every time I have to take my hand off the keyboard to reach for the mouse, it feels like shifting from cruising smoothly on a wide-open motorway to suddenly navigating through a bustling, congested local road.
For me the Vim flow is very nice, however lately I’ve been coding in LispWorks and there is no Vim mode there. The lost productivity of that is not as much as I thought it would be and it’s easily offset by the added productivity of LispWorks, so maybe it was all in my head.
The disruption one feels when moving one’s hand from the keyboard to the mouse depends on the distance to the mouse.
I originally learned Vim at a workstation with a full-size keyboard and an external mouse. Moving my hand from the home row to the arrow keys already felt disruptive, and moving to the external mouse took even longer. I could clearly feel the advantage of Vim keybindings.
Now I use a laptop with a 75% (compact tenkeyless) keyboard. Its arrow keys are much closer to the home row. The Mac laptop’s large trackpad is right below the keyboard (I use it mainly for scrolling or small cursor movements), and my external mouse is only a few inches from the keyboard’s arrow keys. That hardware difference is one reason I feel okay with using VS Code instead of Vim.
I am an Emacs user rather than vim but for me a keyboard-only workflow makes a big difference. I think it has to do with the fact that I can do the keyboard operations almost automatically, as if my fingers are doing the task autonomously and without the interruption of a having to do a visual search for the right GUI element.
And this applies to more than just coding. There is a reason people go out of their way to use keyboard-only window managers and to add keyboard navigation to web browsers.
I’ve mostly had the opposite experience, but I suspect that it may be just habit forming. That is, when I use my mouse I am annoyed and slower, but I don’t know how much of that is that I am simply not practiced in doing it versus it inherently being less precise/slower.
Sometimes coming at the question from a totally different angle can be illuminating. Consider this commentary from Adam Savage about his philosophy of shop organization and how it relates to flow-state. Very similar ideas there.
I initially learned vim because it’s everywhere and it’s what the hip kids in CSE and my early career coworkers used. Thats not a good reason, but it got me far enough to see the light.
The breakthrough for me was when I learned enough to use it efficiently, and had an actual use for a macro I actually knew how to write. “Editor, do that thing I just did, but 50 times” is impossible without some recordable covering set of editing operations. Vim has this, and its UX encourages you to learn them. It’s not about shaving off handfuls of seconds a day by knowing when to use w versus W or f versus t, it’s about those few weeks a year where it turns an O(n) task that might take a miserably boring day or 3 in a naive editor into an interesting puzzle that, when solved, is an O(1) and done before lunch.
Now I use kakoune, which the vim knowledge helped with, and it’s even faster because i can see all 50 things happening at once and undo/redo works in parallel.
I once turned a 25 page PDF of generated documentation for a proprietary library into python ctypes definitions in about 15 minutes. I had to demonstrate the process again to convince coworkers I hadn’t found it online and vendored it.
Situations like this aren’t super common, and are often indicative of larger architectural issues, but that doesnt stop them from showing up a handgul of times a year. Also, normalizing code to the point that tricks like this work often aids readability and is still a net-time-gain over doing it manually. It gets me 80% of the utility of a refactor with 10% of the effort.
For me it’s reliability. Or rather availability. For any machine that I’m likely to do text editing on, Vim is already installed or is easy to install.
The other thing is heritage. I like using a tool with a lineage that goes back to the 1970s. I like the feeling of being connected to all those fellow programmers over all those years.
Why were you the stupid one? Doing things that make you feel nice is fine and can sometimes be strategic, but I don’t think it should take precedence over external reality
I used to think traditional things like rituals were stupid. I used to think my dad was too conservative. After many years in the real world I understand better the reasons for some cultural norms, especially those that are very old. I understand that my father was cautious because he had responsibilities and had been burned by reality.
I can do light editing in vi – browse around in a file, find a line of config that needs changing, add or remove a few characters, get out of there.
On any machine I’m likely to be doing serious editing on, emacs is just an apt install or brew install away.
Both vi and emacs emerged in 1976, as full-screen “visual” modes for the existing ex and TECO line editors, respectively.
When I started university in 1981, the popular editor on the PDP-11/70 at Waikato university was vted, which also was I believe built as macros on top of TECO. I think it may have been written locally, as Google can’t find anything about it.
I don’t use Vi(m) for work. We use VS Code (basically) with a lot of integrations with the rest of our developer tools including some fairly helpful code intelligence tools. I would not be nearly as productive with Vi(m) at work.
For my personal stuff (learning golang and writing fiction) I do use Vim + ALE (LSP client). I wrote this up here.
In short I love
How easy Vim is to tinker with. In a few lines of configuration I had my status bar
Customized to file types
Exactly how I wanted it
I’ve written a plugin for VS Code. It would have taken me a lot of boilerplate to do the same thing with VS Code.
How low power it is. My Thinkpad consumes 5-7W when I’m writing with Vim and running code. I’m pretty sure it was 7-10W when I was using VS Code for the same thing. I don’t have scientific study though.
How creative Vim is with just text to work with. We have
Editor tabs
Mouse support
Autocomplete
Linting
Once you memorize the keystrokes, you don’t need the mouse. This is fun and it is practical.
That it takes me back to my grad school days. I coded decently complex C++ programs with “just” Vi on a SGI O2 machine. The height of ergonomics in that time(TM) was two windows: one with the code and one with the screenful of compiler errors. I don’t think I produced code that much slower. I just made my brain work more focused.
It’s just a silly sentiment, but it feels good to use a completely open source terminal based tool. On a lark I’m trying to see how much of my daily use I can do from the console.
It’s not mandated, but the friction is a lot less if we use the in house editor because of all the integrations. It also depends on the team: a few teams have a very different toolchain, and they use different tooling, but most people use the in house editor.
I suppose I ‘get it’ but any setup where (Neo)Vim or Emacs is considered “friction” would be a hard “no” from me. Something smells funny if either of those gold standard editors can’t work.
I’ve encountered that vim introduces a hell of a lot of friction when i was at university and work. From docker dev containers being an absolute nightmare in vim, to poetry envs not registering correctly even after a couple of hours of trying to hack together a plugin, i just found that a lot of places are targeting vscode based workflows. Trying to use vim just means it’ll take more time to configure it to work in a subpar manner.
I try my best to avoid using Vim and Tmux, choosing Acme instead, but I agree that the former approach is often faster, so sometimes I switch.
It’s especially noticeable when going inside remote boxes. Luckily, SSHFS exists, so I can edit files in Acme (Acme can’t edit remote files directly).
I don’t like keyboard shortcuts, I find them unintuitive and not very discoverable for beginners, and most editing environments are full of them. The same goes for abbreviatures in general, I try to avoid them. Modern terminal emulators are incredibly complex as well.
I used vim for over a decade. I bought into this idea that all problems were just insufficient “groking” on my part. At some point I realized I just hate modal editing. I still use vim occasionally if I’m in the terminal, but nowadays my primary editor is VS Code. The modeless editing is so much more comfortable, especially with all the modifiers on my keyboard’s thumb cluster. I use a Wacom Intuos4 tablet instead of a mouse. I find it much more comfortable clicking and selecting text that way than using vim motions. Vim’s composable nouns and verbs might be ideal in theory, but in practice I don’t like using them.
For me it’s about speed as in keypress-to-stuff-happening-in-editor latency. I honestly don’t know if I’d be any slower or faster if I weren’t using Vim keybindings in my editor; the damage has been done and now I can’t use a normal code editor anymore without tripping over myself every two keystrokes.
VS Code is good but the Vim extension is really slow and has never felt very well-integrated. Why do vim commands show up in the status bar instead of a palette? Why does it mess with VS Code’s history? Why does it reimplement search/replace instead of providing a keyboard UI to VS Code’s integrated search? Why is there so much stuff in VS Code that I can’t access from the vim extension without extensive configuration?
I actually asked these questions to a developer of the extension a while ago, and they replied that their goal is to emulate everything exactly as it is in vim rather than integrating with VS Code, which seems a bit counterproductive to me.
(Note that I haven’t used VSCodeVim in a while now, do tell me if things have improved since then, or if there’s a viable alternative to that extension.)
I started out using vim, then picked up VS Code (with the vim extension, of course) because of LSP, and recently I completely moved to Helix with gitui and a terminal multiplexer.
I really tried to like Helix but my brain just couldn’t cope with the “almost vim but not quite” aspect. It’s somehow worse than just ditching modal editing altogether to my brain.
I also learned vim a long while ago, not well enough to be really productive, but good enough not to be completely hopeless when getting thrown into a foreign system from a shell. I’ve also now completely moved to Helix. Wish it had a builtin terminal.
And yes, at the start the “not quite vim” part also got to me, but it had taken me quite a while to learn vim, so surely I could invest a week or two…and that did the trick.
FYI if you want vim key bindings in vs code I would strongly recommend the neovim extension over vscodevim. I have tried both.
It’s not perfect and occasionally I hit the “reload windows” button to fix the two editors going out of sync, but the accuracy of the emulation can’t be beaten since it is indeed actual vim under the hood rather than a recreation. Macros work much more often.
I’ve seen that option in the VSCodeVim settings and thought it was pretty cool. It’s not for me however; it’s kind of the opposite of what I’m looking for!
Least annoying integration of memes in an article I’ve seen in a while, good job. They felt like part of the article, like how emojis are used to indicate emotions more explicitly, rather than non sequitur jokes awkwardly interrupting.
Maybe in some circles, but I think that’s an unfair take overall. At worst, I think you can put it down to people trying to preserve something they see as valuable - like trying to share music you grew up with. There’s a cultural aspect to it that it’s a little sad to lose. That said, I get that it’s not for everybody and there’s a lot of options - just like I realize my daughter isn’t going to get into a lot of my music no matter how much I wish otherwise.
I feel pretty conflicted about the notion that moving from touching the keyboard to the mouse is a loss of focus.
I bought the notion earlier of course when I was really getting into Vim, but then I seriously tried just using the mouse and I found that it didn’t really make that much of a difference for me. As a result, I find it hard to believe the idea that the ‘context switch’ is really that meaningful.
Has anyone else had that experience?
I think it’s all about how the editor fits your brain. If it fits, great. If not, try something else. For me, vim’s keyboard focus is really enjoyable, and I think we’re more productive with things we like.
I think I could get to the point where I reach for the mouse instinctively, but with vim I never think about vim, it’s like walking, and when I use something else, reaching for the mouse is only triggered by being snapped out of everything being pure muscle memory. I think it’s possible the mouse just becomes another motion, but it’s hard to actually imagine since it’s so far away.
Very fair!
I disagree pretty strongly… Vim editing is a discipline, this is not something you will intuitively be good at, it takes months of labor to even be sort of okay at it.
There’s nothing inherently wrong with touching a mouse, but the combination of gross+fine motor control it requires necessarily means you are slowing down your interaction with the machine by at least an order of magnitude, and that increases the risk of being knocked out of the flow state.
Keyboard-driven development in Vim is the only time my editor has felt like an extension of my mind.
I agree with that. Vim is a discipline, and takes a while to get proficient, with it’s rewards being cumulative over time.
My point about enjoying Vim is that I believe that is at the core of why I use it. There are many productive tools, but I stuck with Vim’s learning curve because I enjoyed it, because it fit my brain. Even though learning it was difficult, I was still enjoying the process of learning it, and I don’t think I would have continued to if I hadn’t. For example, I tried Emacs, and didn’t stick with it because it didn’t fit my brain as well, and hence I didn’t enjoy using it as much.
Doesn’t make a big difference for me either, but I think Vim is more fun and feels less like work. Even if it isn’t actually any faster (for me at least), it’s just fun and satisfying to string together editing commands in a way that clicking and dragging isn’t. Tickles the brain just right.
The keyboard feels more “deterministic” than the mouse because I don’t have to aim, I just, well, type the letters. Similarly, vim commands better reflect what I want than selecting the right number of characters with a mouse does. (E.g., if I want to delete a section of text, and I see the word “something” immediately after, I can use
d/something. Lots of motions like that reflect how I think of the text I’m editing.)I like that idea, keyboard is digital, mouse is analog.
When I’m at a desk, going for the mouse isn’t a terrible disruption. On a laptop? I hate fiddling with text using a trackpad. Maybe I’m just old, but it feels like working with oven mitts on. Not having to do that is invaluable. Having to use the trackpad (even the ThinkPad pointer) is a cognitive switch.
But, I’ve used Vim for decades. 20-something me, before Vim, might’ve felt differently.
I could believe that the physical context switch—moving your hand from the keyboard to the mouse—has the potential to add some delay. But that’s only if you’re very proficient with the keyboard. If you want to move the cursor somewhere else in the document, but it takes you half a second to decide how to do that using the keyboard, you probably would’ve been better off just using the mouse.
I’ve been using Vim for 20 years, and while I’m comfortable using just the keyboard (when Vim is running in a terminal), I feel like I’m faster when I can also use the mouse (in MacVim).
I agree. I HATE having to interrupt my thoughts to decide how to navigate in my editor. Whether that happens frequently is going to vary from person to person …
and I bet that almost everything mentioned in this discussion varies wildly from person to person. I don’t mean that it’s just a matter of taste. I expect there are interesting reasons for all the variation. The variation between people is the sort of thing I would expect to be very very complicated.
I use the mouse with vim pretty heavily. I think the fact that it actually works pretty well in there is forgotten in a lot of these threads.
I don’t think it’s the movement between the keyboard and the mouse that causes a “loss of focus” or a “context switch”: it’s the mental shift from vim-command-mode to GUI-desktop-mode. These are two different ways of interacting with a computer. In another comment here, @susam describes how switching from Emacs to a different GUI application “disrupts the flow”. Again, I don’t think it’s really about keyboard versus mouse: I think it’s more about two different cohesive models for controlling a computer.
I’ve used Vim for more than twenty years now and I think I’m pretty proficient at it. I don’t really think about how to control it, I just think of the change that I want to make to the text and my fingers automatically express that as Vim commands. The Vim command language is seared into my muscle memory. This has served me really well for a large part of my career, which I have spent using Vim and other teletype-terminal programs in tmux (and Screen before that).
However, these days, I find that I have to use a lot of other GUI desktop applications too - I can’t live in tmux any more - and I find the context switches between Vim and the rest of my desktop really jarring. The same modal command language that used to keep me in the flow now disrupts my flow!
So I recently decided to give up Vim and try a text editor that obeys the same modern desktop idioms as all the other GUI applications that I have to use for work. It’s taken me a few months to get used to it but I’m now glad that I made the switch: I no longer have to suffer jarring context switches every time I change between my text editor and my other tools.
Just the other day, I found myself having to make a load of edits to a configuration file: this was just pure text editing work. I felt like I was going so slowly, constantly grabbing the mouse to select some text, then going back to the keyboard to type. It was the sort of thing that I could do in no time, almost without thinking, in Vim. So I thought I’d test that: I undid all my changes then used a screen recorder to time myself doing them all again. Then I undid them and recorded myself doing it in Vim. It wasn’t really a fair comparison - since I’d already done all the tasks twice by the time I did them again in Vim - but I thought it would be interesting to see how much faster I was in Vim anyway. To my surprise, when I checked the recordings I found that I was faster using the mouse!
Anyway, different people will have different preferences, but I think it will also depend on the type of work that you’re doing. When I used to live in tmux, Vim was great. Now that I no longer have to work over SSH but I do have to use other GUI desktop applications, I prefer something else. I also found it interesting that my perception of my editing efficiency was quite different from the empirical measurements… but maybe that’s just me.
I do find it clumsy to context switch between keyboard-driven work and mouse-based work. Let me share a very recent example. Only yesterday, I was doing source code walkthrough of a new software project for someone else using my Emacs. I could do most of the code walkthrough merely by touch-typing on my keyboard.
I could hop around to different sections of the source code (movement commands), search for files containing specific identifiers or strings (project commands), hop between files (buffer commands), start/restart Docker containers (M-x eshell), run arbitrary shell commands (M-x eshell again), create new files with experimental code to test out ideas, etc. all from within Emacs, using nothing but the keyboard with my fingers relaxed comfortably on the home row most of the time, touch-typing away as I command Emacs to assist me in navigating through the code and testing out ideas.
But every once in a while, I would be forced to move my hand away from the keyboard to the mouse nearby in order to move the mouse pointer over to another GUI application to look up something. Each time I had to make this transition, it disrupted the “flow” and felt cumbersome, highlighting the disparity between the smooth keyboard-driven workflow within Emacs and the clumsy mouse-based navigation outside of it.
While I appreciate that not everyone shares the same experience as mine, and that’s perfectly fine, for me, every time I have to take my hand off the keyboard to reach for the mouse, it feels like shifting from cruising smoothly on a wide-open motorway to suddenly navigating through a bustling, congested local road.
I have the same experience. I don’t feel any loss of focus from switching.
For me the Vim flow is very nice, however lately I’ve been coding in LispWorks and there is no Vim mode there. The lost productivity of that is not as much as I thought it would be and it’s easily offset by the added productivity of LispWorks, so maybe it was all in my head.
The disruption one feels when moving one’s hand from the keyboard to the mouse depends on the distance to the mouse.
I originally learned Vim at a workstation with a full-size keyboard and an external mouse. Moving my hand from the home row to the arrow keys already felt disruptive, and moving to the external mouse took even longer. I could clearly feel the advantage of Vim keybindings.
Now I use a laptop with a 75% (compact tenkeyless) keyboard. Its arrow keys are much closer to the home row. The Mac laptop’s large trackpad is right below the keyboard (I use it mainly for scrolling or small cursor movements), and my external mouse is only a few inches from the keyboard’s arrow keys. That hardware difference is one reason I feel okay with using VS Code instead of Vim.
I am an Emacs user rather than vim but for me a keyboard-only workflow makes a big difference. I think it has to do with the fact that I can do the keyboard operations almost automatically, as if my fingers are doing the task autonomously and without the interruption of a having to do a visual search for the right GUI element.
And this applies to more than just coding. There is a reason people go out of their way to use keyboard-only window managers and to add keyboard navigation to web browsers.
I’ve mostly had the opposite experience, but I suspect that it may be just habit forming. That is, when I use my mouse I am annoyed and slower, but I don’t know how much of that is that I am simply not practiced in doing it versus it inherently being less precise/slower.
Sometimes coming at the question from a totally different angle can be illuminating. Consider this commentary from Adam Savage about his philosophy of shop organization and how it relates to flow-state. Very similar ideas there.
Never ask a man if he uses VIM.
If he does, he’ll tell you. Repeatedly and at length.
If he doesn’t … why embarrass him?
The whiplash—
Respectfully disagree.
I initially learned vim because it’s everywhere and it’s what the hip kids in CSE and my early career coworkers used. Thats not a good reason, but it got me far enough to see the light.
The breakthrough for me was when I learned enough to use it efficiently, and had an actual use for a macro I actually knew how to write. “Editor, do that thing I just did, but 50 times” is impossible without some recordable covering set of editing operations. Vim has this, and its UX encourages you to learn them. It’s not about shaving off handfuls of seconds a day by knowing when to use
wversusWorfversust, it’s about those few weeks a year where it turns an O(n) task that might take a miserably boring day or 3 in a naive editor into an interesting puzzle that, when solved, is an O(1) and done before lunch.Now I use kakoune, which the vim knowledge helped with, and it’s even faster because i can see all 50 things happening at once and undo/redo works in parallel.
I once turned a 25 page PDF of generated documentation for a proprietary library into python ctypes definitions in about 15 minutes. I had to demonstrate the process again to convince coworkers I hadn’t found it online and vendored it.
Situations like this aren’t super common, and are often indicative of larger architectural issues, but that doesnt stop them from showing up a handgul of times a year. Also, normalizing code to the point that tricks like this work often aids readability and is still a net-time-gain over doing it manually. It gets me 80% of the utility of a refactor with 10% of the effort.
For me it’s reliability. Or rather availability. For any machine that I’m likely to do text editing on, Vim is already installed or is easy to install.
The other thing is heritage. I like using a tool with a lineage that goes back to the 1970s. I like the feeling of being connected to all those fellow programmers over all those years.
I’m not tryinna start a fight but I think that’s a bad reason to do anything.
When I was younger I laughed at heritage the same way I laughed at my dad. Now I know I was the stupid one.
Why were you the stupid one? Doing things that make you feel nice is fine and can sometimes be strategic, but I don’t think it should take precedence over external reality
I used to think traditional things like rituals were stupid. I used to think my dad was too conservative. After many years in the real world I understand better the reasons for some cultural norms, especially those that are very old. I understand that my father was cautious because he had responsibilities and had been burned by reality.
I can do light editing in vi – browse around in a file, find a line of config that needs changing, add or remove a few characters, get out of there.
On any machine I’m likely to be doing serious editing on, emacs is just an
apt installorbrew installaway.Both vi and emacs emerged in 1976, as full-screen “visual” modes for the existing
exandTECOline editors, respectively.When I started university in 1981, the popular editor on the PDP-11/70 at Waikato university was
vted, which also was I believe built as macros on top of TECO. I think it may have been written locally, as Google can’t find anything about it.I’ve started installing microemacs everywhere I can get my hands on. Feels much nicer.
this might sound dumb but for me vim is about the feel. I really appreciate the movement etc. feels like game mechanics
I don’t use Vi(m) for work. We use VS Code (basically) with a lot of integrations with the rest of our developer tools including some fairly helpful code intelligence tools. I would not be nearly as productive with Vi(m) at work.
For my personal stuff (learning
golangand writing fiction) I do use Vim + ALE (LSP client). I wrote this up here.In short I love
Your workplace chooses your editor for you?
It’s not mandated, but the friction is a lot less if we use the in house editor because of all the integrations. It also depends on the team: a few teams have a very different toolchain, and they use different tooling, but most people use the in house editor.
I suppose I ‘get it’ but any setup where (Neo)Vim or Emacs is considered “friction” would be a hard “no” from me. Something smells funny if either of those gold standard editors can’t work.
Absolutely, everyone has different preferences.
I’ve encountered that vim introduces a hell of a lot of friction when i was at university and work. From docker dev containers being an absolute nightmare in vim, to poetry envs not registering correctly even after a couple of hours of trying to hack together a plugin, i just found that a lot of places are targeting vscode based workflows. Trying to use vim just means it’ll take more time to configure it to work in a subpar manner.
I try my best to avoid using Vim and Tmux, choosing Acme instead, but I agree that the former approach is often faster, so sometimes I switch.
It’s especially noticeable when going inside remote boxes. Luckily, SSHFS exists, so I can edit files in Acme (Acme can’t edit remote files directly).
I don’t like keyboard shortcuts, I find them unintuitive and not very discoverable for beginners, and most editing environments are full of them. The same goes for abbreviatures in general, I try to avoid them. Modern terminal emulators are incredibly complex as well.
Acme is the simplest environment I found for now.
I’m dreaming of the day that we see this kind of article with people arguing for using Acme.
I used vim for over a decade. I bought into this idea that all problems were just insufficient “groking” on my part. At some point I realized I just hate modal editing. I still use vim occasionally if I’m in the terminal, but nowadays my primary editor is VS Code. The modeless editing is so much more comfortable, especially with all the modifiers on my keyboard’s thumb cluster. I use a Wacom Intuos4 tablet instead of a mouse. I find it much more comfortable clicking and selecting text that way than using vim motions. Vim’s composable nouns and verbs might be ideal in theory, but in practice I don’t like using them.
For me it’s about speed as in keypress-to-stuff-happening-in-editor latency. I honestly don’t know if I’d be any slower or faster if I weren’t using Vim keybindings in my editor; the damage has been done and now I can’t use a normal code editor anymore without tripping over myself every two keystrokes.
VS Code is good but the Vim extension is really slow and has never felt very well-integrated. Why do vim commands show up in the status bar instead of a palette? Why does it mess with VS Code’s history? Why does it reimplement search/replace instead of providing a keyboard UI to VS Code’s integrated search? Why is there so much stuff in VS Code that I can’t access from the vim extension without extensive configuration?
I actually asked these questions to a developer of the extension a while ago, and they replied that their goal is to emulate everything exactly as it is in vim rather than integrating with VS Code, which seems a bit counterproductive to me.
(Note that I haven’t used VSCodeVim in a while now, do tell me if things have improved since then, or if there’s a viable alternative to that extension.)
I started out using vim, then picked up VS Code (with the vim extension, of course) because of LSP, and recently I completely moved to Helix with gitui and a terminal multiplexer.
I really tried to like Helix but my brain just couldn’t cope with the “almost vim but not quite” aspect. It’s somehow worse than just ditching modal editing altogether to my brain.
I also learned vim a long while ago, not well enough to be really productive, but good enough not to be completely hopeless when getting thrown into a foreign system from a shell. I’ve also now completely moved to Helix. Wish it had a builtin terminal.
And yes, at the start the “not quite vim” part also got to me, but it had taken me quite a while to learn vim, so surely I could invest a week or two…and that did the trick.
FYI if you want vim key bindings in vs code I would strongly recommend the neovim extension over vscodevim. I have tried both.
It’s not perfect and occasionally I hit the “reload windows” button to fix the two editors going out of sync, but the accuracy of the emulation can’t be beaten since it is indeed actual vim under the hood rather than a recreation. Macros work much more often.
I’ve seen that option in the VSCodeVim settings and thought it was pretty cool. It’s not for me however; it’s kind of the opposite of what I’m looking for!
Least annoying integration of memes in an article I’ve seen in a while, good job. They felt like part of the article, like how emojis are used to indicate emotions more explicitly, rather than non sequitur jokes awkwardly interrupting.
Hot take: yes, vim is not about speed, is about gatekeeping.
I don’t understand this statement at all. What is on the other side of the gate? Is vim the only entrance?
Maybe in some circles, but I think that’s an unfair take overall. At worst, I think you can put it down to people trying to preserve something they see as valuable - like trying to share music you grew up with. There’s a cultural aspect to it that it’s a little sad to lose. That said, I get that it’s not for everybody and there’s a lot of options - just like I realize my daughter isn’t going to get into a lot of my music no matter how much I wish otherwise.