Hacker News Reader

Comment by thealienthing | Hacker News Reader

I personally find vin to be a good tool for editing text without leaving the terminal. But when I’m writing a lot of code, I’ve found the vim ide concept to be far more trouble than its worth.

Modern IDEs like VSCode + Vim bindings is my preferred platform

View on HN

One thing I never understood is why Vim bindings are a big gain when you have a mouse. I see a single edit, it takes me all of one second to click for a large jump, even less for cursor key combos in case of a small jump. For mass edits there is find/replace and find+multi cursor. 80% of my time in the editor I spend thinking about the code anyways - I have zero interest to optimize deciseconds of my time, or worse, optimize my perceived productivity vs. my actual productivity (e.g. forcing myself away from the mouse by ways of pattern matching that increases both mental overhead and time required).

Mouse takes far longer than a second for a selection. Switching between keyboard and mouse already takes longer than typing the usual vim-commands for a simple action.

And casual keyboard-commands just don't scale well. Moving cursor x chars means you must type the movement-key x times. With vi you just type the number x and the movement, and usually save big time.

Aditionally, vi has more knowledge about textual objects, which are all interchangable. So whether you move 3 chars, words, paragraphs, pages or functions, it's all the same, just with different letters.

Vi's command-language is highly composable and thus very dense, so it will alwys be faster than mouse and casual editor-commands. Of course as long as you habit them.

I have exclusively used vim keys for years now, but even after that time I find some of this just doesn’t ring true. Anything in vi that involves counting some number is usually faster with normal keys or the mouse. For example moving down 20 lines is way faster with the mouse, you just click. With vi you have to count the lines in your head - better hope you don’t lose count half way because two lines blur together. With lines you can use line numbers and mental arithmetic, but not really for any other number+noun combo.

I recognise there are other better ways to move around but they too often have drawbacks, like moving somewhere with ‘/‘. You have to parse the line you want to move to for a unique string that’s close to where you’re going. Then you have to scan over all the text in between to make sure it doesn’t occur too much there.

Maybe I’m still just doing it wrong.

> For example moving down 20 lines is way faster with the mouse, you just click.

Correction - you must move your mouse hand from the keyboard, move the mouse to the desired location, _then_ click.

Ergonomic concern often goes side-by-side with editors like vim.

I'm also not convinced that comparing the simple editor things is demonstrating the value of vim much. It's how easy vim handles the _not_ simple things, and also how easy it is to motion the often unique or rarely used edits, combined with drop-of-the hat programmability, that makes vim a good choice.

Yes, it's certainly more ergonomic and comfortable. Still, I find the mouse pretty fast overall. But I'm pretty good at aiming at things with it after playing FPS games for a while.

>how easy vim handles the _not_ simple things

Agreed, despite any minor differences in movement speed, even '.' by itself is useful enough to never switch back.

You don't have to count. I typically make a rough estimation and go from there. For me that still is faster than putting hand on mouse, searching current cursor position, aim, click, and back to proper keyboard position. Of course ymmv

I remember in grade school where we practised turing to an approximate page in a book. I always think of it like this.

H/M/L is your friend (move to the top/middle/bottom of current screen). Getting to the wanted position usually takes me less time than just moving my right hand to the mouse and back.

Relative number lines solved the counting issue for me in most scenarios.

Vim bindings operate on commands that can automate many of the daily work you do in a text editor besides inputting text and search & replace. Deleting or copying text inside delimiters or by lines, changing words in place, recording and replaying macros, etc. are all possible with a few keystrokes. Since commands are generic and composable, once you learn the few basic ones you'll be able to come up with combinations of your own that make you more productive over using a mouse and a traditional graphical IDE. If you've ever seen a Vim master at work you'll notice how quickly they manipulate text on screen. It looks almost magical, which certainly makes it difficult to follow for anyone else watching, but to them it's the most efficient use of their time and brain power, since the binding-to-command mapping has become muscle memory. Using a foreign IDE would cripple their productivity.

While it's true that most programming is spent thinking about the problem rather than manipulating text, the benefit of modal editing and Vim bindings is not only in the saved time, but also in removing the barrier from thinking about how you want to change the code to actually changing it. That leaves you more time to think about the problem, but also doesn't interrupt "the flow" by having to think about moving and positioning a mouse cursor in a GUI, which is always a more mentally draining action than typing a few keystrokes.

Your examples of automation are all possible with multi-cursor edits as well. To me it's exactly the right mental model - I can do mass edits with the same commands I've learned in single cursor edits, and, maybe more importantly, I have immediate visual feedback between the edits I compose this way. I'd recommend anyone thinking about learning Vim to give this a try first and then evaluate whether there is any additional benefit from spending a lot of time learning Vim commands.

It's not about optimizing for speed; it's about optimizing for comfortability. Not having to move your hands at all from the keyboard is highly underrated. If you pair it with a windows manager like i3 and use something like vimium on chrome or zathura for pdf, you always have your hands on your keyboard. You don't realize how great that is until you try it. You can't go back to the mouse.

And if your my kind of programmer, you start to move to programs that have VI keybindings, swap out for ones that do, and hack into the ones that don't to make them do!

The whole point of vim binding is to reduce context-switching to the mouse, better maintaining flow.

Once you get good at Vim + a tiling window manager, constantly swapping to a mouse to do things interrupts your flow. It’s akin to forced context-switching, which programmers hate because that also interrupts flow and concentration.

But it does take practice to master enough Vim commands to be able to use it without referring to help docs (which also interrupts flow). You won’t really understand this flow advantage until you’ve done that.

Fwiw, Wall Street culture has something similar around Excel. The best, most proficient Excel masters can use Excel with keyboard only, no mouse, b/c they’ve mastered all the keyboard shortcuts for navigation, data entry, and calculation. They judge each other based on this ability. It’s not unprecedented in the software development community only.

IMHO Vim's strength come from the ability to operate on any logical chunks of text in a unified manner. Being able to jump around text with the keyboard is hardly a big deal compare to that. For example, to delete the entire body of a function in C, you can type "da{", where "d" means delete and "a{" points to text surrounded by braces. To delete a single sentence, I can do "das", etc etc. Of course, you could do the same using the mouse by selecting text manually, but it's way more tedious than Vim commands.

> I have zero interest to optimize deciseconds of my time, or worse, optimize my perceived productivity vs. my actual productivity (e.g. forcing myself away from the mouse by ways of pattern matching that increases both mental overhead and time required).

I think you just said it. Its not interesting/nor a priority for you to optimize things to that level. Those using vim properly and trying to move away from the mouse consider it better for efficiency and ergonomics (debatable).

Its not that you fail to understand. Its more so that you don't care that much.

Not sure if you over read the second part of that phrase, but I have serious doubts whether the efficiency gains touted by Vim users are real or only perceived. I'd like to see some good hard data on that, comparing users of similar proficiency level at various editing styles.

Honestly, I use vim too, and I have learnt the "language" of vim i.e. the grammar and consider myself an advanced beginner.

I have doubts whether the efficiency gains are that useful in every day life. There will some days where I make some pretty widespread refactoring changes over files or the yanking/register stuff can be quite useful, but in general, every day programming, I don't see the efficiency gains.

I have another theory for why people like Vim so much.

Using vim makes you feel like the old-school, crazy powerful, very smart programmers shown in Hollywood. It makes you realize the dream that the little child had when he saw programmers on TV. ( at least for me ) and honestly, its more fun to be doing that so I do it. :)

Maybe I am not that good at vim. But at my level, i don't see great efficiency gains. I simply see more fun gains, and that's good enough for me.

Thank you. The main gain I see in vim is being able to edit configs on any server through SSH. In an environment with IaC policy this gain basically falls away however. What's left is being able to do small edits where launching e.g. VS Code would take too long. That's where I still use it.

I'd think the ergonomics argument is just wrong wrt. repetitive stress. Isn't more variation in movement pretty much always better in that regard?

> One thing I never understood is why Vim bindings are a big gain when you have a mouse.

Vim bindings are a gain because you don’t have to use the mouse.

I've yet to find a study that would validate that claim.

The gains from vim over using the mouse is mainly muscle memory for me.

I can comment out a function/block/line from anywhere in the function without looking at either the screen or the keyboard. And I do it without consious effort.

You probably use keyboard shortcuts to go to the end/start of the line anyway, if you expand that to all the vim movements that's what you gain. Adding composition and macros are just the icing on the cake.

I think this can largely be attributed to preference. I have my hands on the keyboard anyways when I write code, so I find it easier to just move with keys instead of grabbing the mouse. For bigger, espacially vertical movements, I usually grab my mouse, unless I know the line I have to jump to. In that case using the movement keys would be faster as well.

I've come to the conclusion that the discrete interface of the keyboard and keypresses meshes well with the discrete nature of text versus the analog control the mouse gives. When selecting by individual characters/lines, I'd much rather use my keyboard and know that for each keypress I'm interacting with some X amount of text than fumble with my mouse until I get exactly what I want selected. Vim keybindings specifically are nice because they provide a pretty universal interface - most applications I use implement Vim keybindings, so there's very little context switching when working with my IDE, CLI file browser, Firefox w/ Vim Vixen, etc.

Also, I find that preventing constant movement from the keyboard to my mouse and back helps mitigate wrist pain and discomfort from long sessions at my PC.

To me the interesting part is not having to do precise mouse movements.

With vim bindings it’s easier to do things like rewriting arguments in a function, without having to carefully select them with a cursor or using ctrl+shift+Right arrow the right amount of times.

The speed I find it’s only a plus when having to work with old/sluggish machines, because it breaks my flow way less, but that’s completely personal preference.

The gain is less frustration.

If you don't mind moving back and forth between mouse and keyboard, or smashing ctrl-arrow to move, then it's fine.

I wouldn't call VSCode an IDE. It is an editor with plugins that give it IDE features. If that's your goal, you can really customize vim to similar place.

VSCode is at the edge of an editor and an IDE though, or so is my feeling at least. I feel like the massive need for ease of use and speed clashes with the needs of power users (e.g. for Java EE or database developers), and that this push vs pull might to be the downfall of VSCode in the future (unless MS throws a pile of money and devs on the codebase).

You’re being downvoted because that’s nonsense. It comes built-in with formatting, intellisense, a terminal, a debugger, Git support, and syntax highlighting.

Secondly, trying to discern between an “IDE” and a “text editor” in 2020 is a fools errand. It’s pointless because there’s such a grey area between where one definition starts and ends.

Coc.nvim provides VSCode equivalent plugins in vim.

Reply on news.ycombinator.com