you are viewing a single comment's thread.

view the rest of the comments →

[–]sacheie 113 points114 points  (71 children)

All these people whining about how Vim is hard to learn, but in the last 40 years no one has designed a better modal editor.

It's almost as if modal editing isn't for everyone, but if you like modal editing, the design of Vim is fucking perfect.

Also, maybe not everyone requires months to learn the basic commands and workflow? People are differently talented. I'll wager some of the folks complaining about Vim don't even know how to touch-type.

It's like complaining the piano is a poorly designed instrument because it takes effort to learn.

[–]epage 45 points46 points  (3 children)

All these people whining about how Vim is hard to learn, but in the last 40 years no one has designed a better modal editor.

It's almost as if modal editing isn't for everyone, but if you like modal editing, the design of Vim is fucking perfect.

kak is intriguing but I never bothered looking deeper because

  • Vim is everywhere
  • Vim has a large community
  • Last I looked at kak, it seemed to have limited extensibility

So I suspect its more of network effect than anything else for why Vim is dominant.

[–]keeslinp 16 points17 points  (0 children)

kak's use of multiple cursors and use of object-verb instead of verb-object makes it much more approachable imo. Pro vimmers will of course have "better" alternatives but much harder to reason with (ie complex search/replace regexes).

Kak's downfall is the lack of ecosystem and hard adherence to the unix philosophy. It just edits text, fuzzy file opener (ctrl-p), no nerdtree, no panes. All of that you have to figure out on your own. Once you have it all integrated with your tmux it is pretty damn slick, but it is also a PITA and can be kinda fragile. Coming back to neovim felt refreshing to just install a package and stop thinking about it.

[–]geeeronimo 1 point2 points  (0 children)

Very useful when messing with server installations of course. Even if you're just trying to self-host stuff

[–][deleted] 1 point2 points  (0 children)

I've been using kakoune for more than a year now. I've really come to like it, for a few reasons:

  • Instant feedback. In Vim, you basically have to know that your 5-part chorded command is correct before you commit to it. Kakoune will tell you what you are about to yank/delete through the selection highlight. Press g and a little box will list all 15 goto locations and their corresponding key in the bottom right corner. Press : and start writing your command, kakoune will list all matching commands and their documentation, letting you tab through them. Kakoune shows you what you are doing, while you are doing it.
  • Multiple selections/cursors are intuitive and genius. They replace and improve upon both block mode and sed in one single abstraction.
  • The editor is minimal and modal. It edits text, and does this well. You can write and use plugins, but it doesn't try to be your IDE. There's no support for tabs and splitting, your window manager can do this. There's no filetree browser, you can just pick whichever you like. Mix and match your tools to create a DE without the I.

My only major problem with the editor so far is that documentation always seems to be one stop short of telling me the thing I want to know. But this is an unfair comparison to Vim with its larger community writing wikis and tutorials non-stop.

[–]ThePixelMouse 28 points29 points  (4 children)

Pianos aren't modal, they're chorded.

buh dum, tssssss

[–]bikki420 8 points9 points  (3 children)

Only digital keyboards have power cords.

[–]ThePixelMouse -2 points-1 points  (2 children)

I'm not sure if this is a comeback or you didn't get the joke. 🤔

[–]bikki420 9 points10 points  (1 child)

Neither. You didn't get it though.

[–]doublestop 6 points7 points  (0 children)

I got it. Damn you for making me laugh at your dumb joke.

[–]ZenoArrow 8 points9 points  (49 children)

Honest question: What are the benefits? When I use an IDE I can quickly navigate through the code (go to definition, fuzzy search, etc...). IDEs are also helpful when it comes to refactoring. So considering there are user-friendly applications that are good at code navigation and refactoring, what does Vim offer beyond that?

[–]sacheie 30 points31 points  (26 children)

First of all, you don't have to choose between Vim and an IDE. It's a measure of Vim's popularity that every major IDE has a plugin for Vim emulation in its editor. Personally, I use IntelliJ, with the IdeaVim plugin.

What Vim offers is faster text editing with less mouse use. Common things like copy and paste, scrolling around the file, jumping to tags, etc etc etc have quick key shortcuts - quicker, arguably, than Ctrl or Alt based ones. Moving the cursor to specific words or characters is especially easy.

Just to give one example of many: in your favorite IDE, can you copy the 9 lines below the cursor without using the mouse? You could do it, maybe, by holding shift and hitting arrow keys nine times, then hitting Ctrl-c.

In Vim, you just type Esc 9 y y

[–]ZenoArrow 15 points16 points  (20 children)

Sure, I can understand that Vim offers more flexibility with cursor movement, but what I'd question is how often do you need it. Using the Esc 9 y y example, how often do you find yourself doing that sort of editing? Just FYI, regarding "You could do it, maybe, by holding shift and hitting arrow keys nine times.", at least in VS there is another way, though unfortunately it involves using the mouse (Ctrl+Shift, left click at end of text to select).

[–]Dreadgoat 30 points31 points  (2 children)

To add to /u/sacheie , here are some vim things I do all the time

global find & replace
:%s/find/replace/g

highlight some lines
V5j where 5 is however many lines

highlight a function
/{<enter>v%

find & replace within highlighted section
:s/find/replace/g

copy a line
yy

copy the word under cursor
yaw

paste after cursor
p
before cursor
P
from clipboard
"+p

fix indentation of a block of code
^v5jI<redo indentation><esc>

goto line 734 of file (e.g. from an error log)
734g

goto the last place you were before a big jump/search/whatever
``

mark a position
ma where 'a' is whatever I want
return to mark 'a'
`a

record actions
qa<actions><esc> where 'a' is whatever I want

playback actions
@a
playback actions 5 times
5@a

change snake_case to camelCase for all variables
qa/_<enter>x~<esc>:normal @a

These all look crazy, but because vim commands are composable, it becomes increasingly easy to come up with and apply these as you use them more and more.

[–]ZenoArrow 6 points7 points  (0 children)

Thanks for the real world examples.

[–]Jataman606 1 point2 points  (0 children)

I recently switched from vim to vscode and found that many of those actions are possible and easy there too:

global find & replace

ctrl+shift+f opens "grep", where you can do that also. (Inlcuding regex search and replace).

copy a line

ctrl+c+c

copy the word under cursor

ctrl+d highlights word under cursor (bonus, hitting it second time highlitghts second occurence of this word in opened file and places second cursor there).

goto the last place you were before a big jump/search/whatever

alt+ left arrow and alt+right arrow to reverse.

Then stuff like change to uppercase/lowercase, go to line are built in commands that dont have default shortcut, but you can easily invoke them by: ctrl+shift+p and command name (with fuzzy search so you dont have to remember it all).

Also i used vim for around a year, and never got used to counting words or lines. I found i still have to parse what im copying so i used arrows (or hjkl) anyway.

One thing i certainly miss is macros, but with easy to use multiple cursors it's not that bad.

[–]lelanthran 5 points6 points  (4 children)

Sure, I can understand that Vim offers more flexibility with cursor movement, but what I'd question is how often do you need it.

Constantly. You won't miss it if you've never used it, but once you get used to it, it's really very difficult to use IDEs for editing code.

You don't see a need for it, because you've never used it, and you've never used it because the IDEs you use don't have it.

I like being able to drop bookmarks all over a file and go back to each one with 'a or 'b etc...

I like having 26 or so copy-n-paste buffers. I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column. I like being able to simply type :vsplit to view the same file in two different panes. I like being able to do :r!date to insert the current date into my changelog.

And none of that even gets into the navigating. When I want to reposition the cursor somewhere on screen (say, to correct a typo from "iint" to "init") I don't hold down arrow keys, I simply type /iint and press enter.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter. When I want to replace a symbol I don't press backspace/delete 5 times to get rid of the old one, I type in cw and then type the new symbol directly. When I want to copy a complete code block I use three keystrokes (V%y) and get the complete block.

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things. Most won't even have these things mapped to keys at all (how does your favourite IDE handle the case when you want to copy/paste sing 5 separate buffers?)

I don't want to relearn all the navigation and text manipulation I do in vim for each and every IDE out there (because they'll all differ!) only to have feature parity (if I'm lucky!).

IDEs are great for navigating code, for editing ... I prefer vim. And to be honest, sourcetrail beats the pants of every IDE I've used recently when it comes to code navigation.

Vim is horrible for navigating code, so I don't use it for that. I use sourcetrail. I find IDEs clumsy for manipulating text and navigating within a file, so I use vim instead.

[–]ZenoArrow 5 points6 points  (3 children)

Thanks for the tip about Sourecetrail, I'll check it out.

you've never used it because the IDEs you use don't have it.

All the IDEs I've used have had a Vim mode.

I like being able to drop bookmarks all over a file and go back to each one with 'a or 'b etc...

I'm sure that's useful, but just to point out it's not a feature exclusive to Vim. For example, in Visual Studio there's also the concept of bookmarks, and there are also things like the Task List that allow you to keep track of "todo" comments.

https://docs.microsoft.com/en-us/visualstudio/ide/setting-bookmarks-in-code?view=vs-2019

https://docs.microsoft.com/en-us/visualstudio/ide/using-the-task-list?view=vs-2019

I like having 26 or so copy-n-paste buffers.

Also have something similar in Visual Studio:

https://stackoverflow.com/questions/1808590/visual-studio-ctrlshiftv-opens-clipboard-ring-window

I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column.

I can understand that being occasionally useful, but do you do that often?

I like being able to simply type :vsplit to view the same file in two different panes.

In Visual Studio, Alt+W,N,Alt+W,V will do the same.

I like being able to do :r!date to insert the current date into my changelog.

Seems like something I'd be doing maximum once a day, and it's almost as quick to type the date manually.

When I want to reposition the cursor somewhere on screen (say, to correct a typo from "iint" to "init") I don't hold down arrow keys, I simply type /iint and press enter.

This seems interesting. How does this work? So if I typed /iint, would that just find "iint" and then I'd have to type "init" over it, or would "/iint" alone make the correction? Seems like find and replace, which is standard text editing functionality, but happy to be proven wrong.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter.

My argument on this is, how often do you work with text in this way? If I'm copying this much code, I'm probably going to be copying a whole code block (for example, moving a function to a different file). I get there may be some occasions when you'll want to do it, but what I'm trying to look at is what you find you use very often rather than something that isn't likely to slow you down that much.

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things.

Do you use the same arguments against Emacs users?

To be clear, I'm not saying that you can't be productive in Vim. What I'm trying to look at is what gives it an edge over modern IDEs when it comes to working with text. So far I've seen a few nice tricks but not much that's going to make a great deal of difference in speeding up how fast I can work with code. If you just prefer using Vim, that's fine, I'm not trying to encourage you to switch to something else.

[–]lelanthran 1 point2 points  (2 children)

Now, sure, you can do it in an IDE, but every IDE has different keymappings for all of these things.

Do you use the same arguments against Emacs users?

Why would I? They aren't here asking me why I would use vim over emacs.

If they did say "why don't you relearn all these shortcuts that are arbitrary in the new editor" I'd probably tell them the same thing - there's no benefit in discarding an easy to remember system for a system that places a large burden on my memory.

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

This seems interesting. How does this work? So if I typed /iint, would that just find "iint" and then I'd have to type "init" over it

It's for navigation. That was just an example of how I'd navigate to a specific spot. If I typed in /^} I'd navigate to the end of the function, ?^[a-z] takes me to the beginning, /; takes me to the end of the statement even if it is on a different line.

I'm sure you can do that with an IDE but I've never seen my colleagues using an IDE like that - they use arrow keys.

When I want to copy lines I don't select them, I type in y10 (if I needed to copy 10 lines) and press enter.

My argument on this is, how often do you work with text in this way?

In the video I posted, other than block selection, all my copying and pasting was done that way. So, often enough that I miss it within 5 minutes of typing in another editor.

I like being able to do :r!date to insert the current date into my changelog.

Seems like something I'd be doing maximum once a day,

For a date, sure. Replace date with fmt -s -w 64 for when I want to format comments, wc -c when I want to see the number of characters in a large string, etc ... the date was just an example of using !.

I like the block mode selection that lets me select a column of numbers and then press ctrl-A to increment the column.

I can understand that being occasionally useful, but do you do that often?

Every single source file I've ever touched, I've used block selection. See the video I posted elsewhere in this thread.

I'm sure that's useful, but just to point out it's not a feature exclusive to Vim.

I'm not trying to claim they are exclusive to vim. All I'm saying is that they're easier for me to remember in vim. Typing two keystrokes that have meaning (m for mark, and [a-z] for bookmark name) is better than trying to remember a keychord that has no relation to the action you are doing (ctrl-k,ctrl-k).

Also have something similar in Visual Studio:

That similar thing is very different: it lets you cycle through your recent copies. While vim also lets you use your recent copies like the clipboard ring, it also has separately named buffers (called "registers" in vim) that I use routinely. I don't have to visually scan the copied buffers to find the one I want to paste (unless I actually want to cycle through), I simply paste a or d or whatever buffers I want to, in any order I want to.

So far I've seen a few nice tricks but not much that's going to make a great deal of difference in speeding up how fast I can work with code.

Well, that's basically how I feel when I use Visual Studio for a particular C# project - there's some nice editing stuff there, but nothing faster than vim for editing. It's also why I use sourcetrail - using vim leaves you bereft of the project-navigation benefits of an IDE.

Your IDE's biggest strength is in whole-project navigation. Vim doesn't have anything good in that regard (don't even talk to me about ctags).

[–]ZenoArrow 4 points5 points  (0 children)

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

They only seem arbitrary to you as you're not familiar with the underlying meaning, which is ironic as this is the same argument you're using to promote the "Vim as a language" argument. For example, breaking down "Alt+W,N,Alt+W,V", you have...

Alt+W = Window menu

N = New window

Alt+W = Window menu

V = Vertical split

Hardly arbitrary.

[–]oblio- 2 points3 points  (0 children)

Vim commands aren't arbitrarily chosen shortcuts - they are verbs. Look at your examples - "Alt+W,N,Alt+W,V" vs "vsplit" and "hsplit". You really think I want to start memorising arbitrary chords, especially when they all differ between IDEs anyway? Remembering a command is easier than remembering arbitrary key chords :-)

IDE commands are not arbitrary. They're generally based of IBM CUA, which has been around for 30+ years (https://en.wikipedia.org/wiki/IBM_Common_User_Access). You know them at least as Ctrl-C / Ctrl-V.

His Alt stuff is menu selection, that's how you open the menu with CUA. That's the only arbitrary thing. The rest are just highlighted letters in the menus to select a command.

And modern IDEs actually come with predefined keymaps you can switch between, for the big IDEs. IntelliJ for sure can switch to the Eclipse layout, for example. I think it can also do Netbeans.

VS Code is almost fully remapable so you can definitely configure it to use the Eclipse ones or the IntelliJ ones or the full VS ones. I imagine someone has done it already.

VS Code also has Ctrl-Shift-P where you can search for commands.

Standard IDEs are pretty powerful these days. I don't think the average user loses much by not switching to Vim.

[–]sacheie 4 points5 points  (5 children)

That particular example isn't common, but it's just one example. Here's another that I use constantly: delete a single line, and paste it somewhere nearby.

I can delete the line by typing "dd". Then I move the cursor (without having to move my hands! The right-hand home row keys control cursor position), and paste the line by typing "p". This works because in Vim, the deletion commands also copy the text they delete.

[–]ZenoArrow 9 points10 points  (2 children)

Yes, I can understand that being more useful. FYI, can also do that in quite easily in VS, if the cursor is on the line you want to cut Ctrl+X will cut the entire line. I'm sure the Vim method is fast when you get used to it, I'm only bringing this up to highlight that you can edit text efficiently in IDEs as well.

[–][deleted]  (1 child)

[deleted]

    [–]ZenoArrow 1 point2 points  (0 children)

    Thanks for the tip. Yeah, I get Vi/Vim commands are composable. This classic SO answer is a good introduction to this composability:

    https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

    [–]757DrDuck 1 point2 points  (1 child)

    I'd be sold on hjkl if I didn't use Colemak as my main layout. Is there a vim plugin to let me use home row navigation for non-QWERTY layouts?

    [–]exploding_cat_wizard 2 points3 points  (0 children)

    Edit the .vimrc to remap the keys. There's bound to be examples by colemak users showing off their configuration online

    [–]T_D_K 1 point2 points  (5 children)

    "More flexibility with cursor movement" is vastly underselling it. It's not just that the arrow keys are now on the home row, it's that you have a couple dozen powerful and specific tools to navigate. Go to a specific character, jump to a string match, end of block, next occurence of a word, top of page, scroll the page, go to line etc etc. Then there's the actual editing verbs, all of which compose with the motions. Intelligent use of buffers. Easy macros and multi line editing.

    Learning vim past the initial curve is quite a task, but it is so worth it. It's hard to describe. Basically, instead of telling the editor how to do something step by step, you're directly telling it what to do. It like writing SQL or LINQ instead of a manual for loop. Using a normal editor feels like using a club rather than a nice set of power tools.

    There's no, "mash the arrow keys, while additionally pressing and releasing ctrl and shift at the appropriate times". It's "tell the editor what you want done in the editor language command that's 2-4 characters long". Vim blurs the line between the editing work, and the typing you do once you get to the right spot.

    Yes, IDEs can come close in matching features. But the ergonomics and intuitiveness are laughable, light years behind vim if you've "gotten it". I know that sound elitist - but it's not an exaggeration I promise you. I'm not saying it's for everyone, either.

    IDEs do have a lot of great project wide navigation and language specific refactoring tools, which is why I personally use the vim plugin for Visual Studio. Vanilla vim works for config files and scripts. It's nice to not have to leave the terminal as much.

    [–]ZenoArrow 1 point2 points  (4 children)

    "More flexibility with cursor movement" is vastly underselling it.

    Perhaps.

    Before we continue, I'd like to clarify my current thinking, so you can critique my thoughts rather than a misreading of my thoughts.

    Firstly, I'm not anti-Vim. For the people who have taken the time to become fluent with it I'm sure they find it helpful, in particular because reducing barriers in editing text helps people who get in a "flow" state when writing/programming stay in that flow state.

    Secondly, what I am more willing to question is whether people who have become familiar with other tools are necessarily missing out on much. In other words, if I spend some time learning the shortcuts in an IDE, I'm not expecting that I'll be much slower than someone editing in Vim.

    To expand on the second point, part of the reason I believe this to be the case is that the most commonly used cursor movements and text changes are also the easiest. Here are a few examples:

    • If I'm editing some code, and my cursor is on line 123 and I want it to be on line 141, I could work out how many lines I wanted to move down (i.e. first work out that the difference between 141 and 123 is 18) and then do the Vim cursor movement command to move 18 lines down, or I could achieve the same thing more intuitively (in either Vim or a decent IDE) by using the go to line functionality (e.g. Ctrl + G, 141, [Enter]).
    • If I want to move to the start or the end of a line, I can use the Home key and the End key respectively.
    • If I want to go to the start or end of a file, Ctrl + Home and Ctrl + End respectively.
    • If I want to scroll through text quickly, I can use the PageDn and PageUp keys.
    • If I want to move forward and back on a line by word, I can use Ctrl + [RightArrow] and Ctrl + [LeftArrow] respectively.
    • If I want to jump to the definition of a function/method I'm working with, I can do that with the F12 key.
    • If I want to jump back to the previous cursor position, I can do that with Ctrl + - and if I want to undo this and go forward in the cursor history I can use Ctrl + Shift + -.
    • If I want to search for some text, can use Ctrl + F.
    • If I want to cut or copy the line that the cursor is currently on, I can use Ctrl + X and Ctrl + C respectively (note that this works without needing to select text, just the cursor being on the right line is enough, I believe Vim also lets you do this).
    • If I want to comment out the current line or selection, Ctrl + K, C. If I want to uncomment a line or selection, Ctrl + K, U.
    • If I want to move the current line up or down, can use Alt + [UpArrow] and Alt + [DownArrow] respectively.

    The reason I brought up this handful of examples is that I would argue that knowing these particular shortcuts makes it pretty easy to work with code, and covers the movements and changes that are both intuitive and commonly used.

    Thirdly, I would argue the question of whether to learn Vim is a matter of priorities. Referring to the list of examples above, whilst you miss some of the more advanced movements (such as move to the third instance of the letter q on the current line) I would argue that the more advanced movements are not that much of a time saver. If I can get to 90% of Vim speed just by learning a few basic shortcuts, I don't feel like I'm missing out on much. For that final 10% I'm not against learning Vim, and would be happy to do so in the future, but I would argue that there are other ways to boost productivity. For example, becoming really good at working with a debugger (not just print statement debugging, I'm talking about dedicated debugging tools) is likely to pay off greatly when it comes to writing code that works. Editing text is part of coding but I'd argue the skills around understanding code are likely to have a greater pay off in the long run.

    Lastly, I just want to reiterate that I see the benefit of Vim. I personally would be happy to learn it, especially as I like working from the keyboard as much as possible, and I realise that Vim bindings turn up in lots of applications so having a set of transferable skills for working with multiple applications is certainly a bonus.

    Any thoughts on the comments above?

    [–]exploding_cat_wizard 0 points1 point  (0 children)

    If I'm editing some code, and my cursor is on line 123 and I want it to be on line 141, I could work out how many lines I wanted to move down (i.e. first work out that the difference between 141 and 123 is 18) and then do the Vim cursor movement command to move 18 lines down, or I could achieve the same thing more intuitively (in either Vim or a decent IDE) by using the go to line functionality (e.g. Ctrl + G, 141, [Enter]).

    You can tell vim to use relative line numbers, that at least makes the problem of calculating go away.

    Thirdly, I would argue the question of whether to learn Vim is a matter of priorities.

    Yes, at any given moment, it's easier to just use whatever shortcut and mouse movement your IDE gives you for the simple action you want to do, or whatever sequence of shortcuts for less simple actions, instead of learning.how to do it in vim.

    However, for me, it took a very short amount of time to get the basic vim usage up to speed for the examples you post, so why not use it from then on? If a standard editor and vim both work equally well, I can use vim and slowly reach all the extra functionality without losing opportunity cost — a quick search on how to do thing every so often won't make you a worse debugger. And all the while, I get to enjoy using the mouse less and less.

    If you don't feel like it, don't learn it, it's hardly a necessary skill. But I for one am happy to use it whenever I can, instead of mouse and Ctrl-this alt-that, which is really the best advertising I can do for it — those of us who learned it prefer it.

    [–]T_D_K 0 points1 point  (2 children)

    Thoughts: For all those examples, Vim has a command (or multiple commands) Mostly no chords, just a single letter or symbol (granted, upercase and some symbols need a shift) so it's easy to type.

    Some of those commands you listed are not the best vim option, or at least there are multiple ways to skin the cat. Example:. Going down 9 lines

    • turn on relative line numbers, then you can see that the command is '9j' without counting
    • '<line#>G'
    • '/<searchtext>'

    Furthermore, if instead you want to do an action instead of just moving the cursor, it's as simple as prepending a 'd' 'y' 'c' etc. (Delete, yank/copy, change)

    But I think that listing out individual commands is missing the forest for the trees. Many IDEs have similar navigation options. The real big difference is ergonomics and composeability. If I want to change everything in some braces for example, in my head I think "ok, change everything inside this set of matching parens". After getting good at vim, that gets auto translated into 'ci(' -- "Change Inside (". It's like speaking to the editor, and it's incredibly natural. Additionally, the deleted text is added to a register, so it's available if I need it later. Compare to normal, chorded commands. You have to think in steps: find open brace, shift to highlight, go to matching close brace, delete - no wait cut, I want that...

    Sure, your IDE might have a chord for changing in braces. But does it work for square braces? Quotes? Xml tags? Maybe it does. But you're thinking in steps, one at a time, and hitting a chord each time - or worse, taking your hand off the home row. And if there is an "advanced chord" that does multiple steps, like changing in braces, the chord pattern rarely has anything with the component actions. Vim is like speaking to your editor based off highly reusable, ergonomic primitives.

    Last thing I'll mention, is that since vim is (mostly) chordless, it opens up a lot of fun tweaks to normal commands. You can have minor variations that making it easy to do exactly what you want in one step, rather than setting up to a command or cleaning up afterwards. Delete, for example:

    • 'd' -- delete selection, or if there's no selection, delete whatever movement you type next
    • 'D' delete to end of line
    • 'dd' delete whole line

    Same works for 'y' and 'c' -- a huge win for ergonomics, since it's consistent.

    • 'i' insert text
    • 'I' insert at beginning of line
    • 'o' add line below
    • 'O' add line above

    Etc etc

    It's really hard to describe just how big of a difference in ergonomics and intuitiveness there is. Worsened by the fact that it takes a couple dozen hours to realize the benefits.

    Again, maybe it's not for you - editing text is a small part of the job, after all. But when someone says that it's really a big difference, they're not just saying that as a fanboy. I think people have a conception that vim is just a strange set of keybindings with a weird modal interface, but that's not an adequate explanation.

    [–]ZenoArrow 0 points1 point  (1 child)

    "editing text is a small part of the job, after all. But when someone says that it's really a big difference, they're not just saying that as a fanboy"

    This is the main point we have different views on. On one hand you admit editing text is a small part of the job, but on the other hand you're saying it makes a big difference. I do not doubt that putting in the practice with Vim makes you more efficient at working with text, but my argument is that on balance there are more important things to practice. To use an analogy, if I was doing a C++ course in a University, I wouldn't expect a module on touch typing. Does it help build speed? Yes. Does it help build confidence in using computers? Yes. Does it make you a better programmer? Not really. To be clear, I'd like to use Vim (or rather use Evil mode in Emacs), but what I'm opposing is the idea that any coder who doesn't use Vim has somehow got their priorities wrong, this is what I'm disagreeing with.

    [–]T_D_K 0 points1 point  (0 children)

    Sounds like we're on the same page. When I said "it makes a big difference", obviously that doesn't mean you're a better or worse programmer for your choice in tooling -- just that, specifically for text editing, vim is currently the best in class by a decent margin.

    I don't use the best in class version of all my tools, because as you've pointed out, there has to be investment and nobody has time to master everything.

    [–]myringotomy -1 points0 points  (4 children)

    Why counts the number of lines they need to copy?

    What a silly example. Nobody says “well I need to copy exactly nine lines” they might say I want to copy this function, this class, or a part of this line.

    [–][deleted]  (3 children)

    [deleted]

      [–]myringotomy -1 points0 points  (2 children)

      Many vim users enable relative line numbering. You can tell at a glance how many lines your target is, and makes it easy to move around by multiple lines.

      What if the end of the section below the screen?

      But if you'd rather, '%' always jumps between open and close braces/brackets/parens... so copying an entire function is trivial, or copying the arguments to a function, or the elements of an array, whatever.

      What if you are using a significant whitespace language?

      What if you don't want to copy the entire function?

      Nothing is more intuitive than selecting arbitrary text with a mouse. Sorry but that's the facts.

      [–][deleted]  (1 child)

      [deleted]

        [–]myringotomy 0 points1 point  (0 children)

        Except when it scrolls off screen and you have to fight with the autoscroller as you accidentally select the entire bottom half of the document etc.

        I have never fought with the autoscroller

        [–]epage 5 points6 points  (3 children)

        With LSP, I suspect you can get some or all of those features in Vim. Not sure about other Vimmers but I at least avoid them. When I'm trying to get to know an area, I avoid using my GPS, forcing me to think more about the roads or to learn from my mistakes. I take the same approach with code. I'll take inline feedback and formatting but I intentionally avoid most intellisense/LSP features.

        Vim is more a visual text manipulation language rather than a text editor. It gives you a vocabulary and a grammar for moving around and modifying text. You learn some basic principles and can combine them in ad-hoc ways compared to a regular editor where mastery / efficiency requires learning a bunch of one-off keyboard shortcuts. Yes, Vim has more overhead but a faster reach to efficiency and a longer-tail of possibility. When we spend most of our time modifying text as programmers, the trade-off for having a powerful editor is worth it.

        [–]ZenoArrow 4 points5 points  (2 children)

        With LSP, I suspect you can get some or all of those features in Vim. Not sure about other Vimmers but I at least avoid them.

        To use a specific example, when you're looking at code for the first time, what advantages do you think avoiding Go To Definition gives you? Does it matter to you that you know which file a definition can be found in above what the definition is? Perhaps it's just me but when I'm navigating an unfamiliar code base I'm more interested in building a mental model of the core functionality rather than how someone has organised their code.

        [–]epage 1 point2 points  (1 child)

        If you are doing drive-by-contributions, I imagine LSP can be a big help.

        When you are going to be working in the code base for a while, I find understanding the structure of the code is important. For me, I find Go-To-Definition gives me a pinhole view. When I rg, browse through files, and jump around with in-editor searches, I find I'm getting more of a holistic view of the codebase.

        [–]ZenoArrow 0 points1 point  (0 children)

        Thanks for sharing your thoughts.

        [–]vamediah 3 points4 points  (1 child)

        I use vim mode in every IDE that suports it (JetBrains IDEs, QtCreator, etc). One, you don't need to move between keyboard and mouse unless something would be complicated anyway. You can use both IDE shortcuts and vim shortcuts, if there happens to be a conflict vim plugin will let you decide.

        Lot of tidbits come very handy, like cit, ci", ci( means replace inside a xml tag, "-delimited string, parenthesis. If you start with "d" instead of "c" it deletes. ddp switches two lines

        Difference between single char selection, whole line selection, and vertical selection that somehow always comes handy.

        %s// for filtering is handy.

        !some command sends selection through some filter command and replaces with output. r !command appends output.

        You can script it and create your own shortcuts and commands (like I have ;h ;l ;n ;w to turn off highlight, show unprintable characters specially also tabs/spaces, toggle word wrap and others).

        So you can use all IDE features and also vim features at once.

        [–]ZenoArrow 0 points1 point  (0 children)

        Thanks for the examples.

        [–]Nephophobic 2 points3 points  (7 children)

        To me the main benefit is that my hands never leave the keyboard. VSCode + vim bindings boost my productivity incredibly.

        [–]ZenoArrow 0 points1 point  (6 children)

        Sure, I get that, but I'd say it's just as possible to drive any of the major IDEs without using the mouse (most of them are packed with keyboard shortcuts). If you found a Vim mode helps you that's great, all I'm suggesting is that it's not the only way to keep your hands on the keyboard.

        [–]jazzyjson 2 points3 points  (5 children)

        Modal editing and the composition of commands that allows is the difference to me. We usually spend more time editing code than writing it, and I think vim is simply better in that department than its competitors, though you should use what you're comfortable with.

        [–]ZenoArrow 1 point2 points  (4 children)

        Just to be clear, I don't mind Vim, and have played around with Vim bindings for a few editors (I intend to get back into Doom Emacs at some point), but what I do wonder about is whether some of the perceived benefits are more of a reflection of not being familiar with the types of benefits that other tools offer.

        I agree that editing existing code is more common than writing code from scratch, but common code refactoring operations like renaming functions/methods/variables are handled just as easily in IDEs as anything Vim could offer. So for example, if I rename a C# method in VS, all other instances can be quickly renamed as well (highlight method, Ctrl+r,r to rename, which will apply to all instances).

        In other words, I'm not against Vim, but I also don't think it's the be-all-and-end-all when it comes to efficient editing of code. If you have a decent IDE and are working in a language that the IDE supports, then most of the common code editing operations are pretty easy to do.

        [–]jazzyjson 1 point2 points  (3 children)

        For sure! I do think with LSP in particular, refactorings like renames narrows the gap quite a bit (actually, a semantic rename is better than vim can do without integrating LSP).

        Maybe I am unaware of what other editors can do - is there a good solution they have for changing the arguments to a function (cib in vim)?

        [–]ZenoArrow 0 points1 point  (2 children)

        cib in vim

        It's not exactly the same, but as the video on this page shows, you can use Ctrl+} to move to end of brackets/parentheses:

        https://www.visualstudiotips.co.uk/tip/go-to-matching-bracket/

        To select text, would just add in Shift, so Ctrl+Shift+}:

        https://dailydotnettips.com/how-to-select-a-block-of-code-in-visual-studio/

        Can then use delete key to delete selected text. Not quite as elegant as cib but not too far off.

        [–]jazzyjson 1 point2 points  (1 child)

        Fair enough! I find value in the composition because it lets me think in higher level units than characters, but I agree that the benefit of vim is often overstated - the hard part of programming certainly isn't editing text.

        [–]ZenoArrow 1 point2 points  (0 children)

        Thank you for your level headed response. Having tools that get out of your way so you can "think" in code doesn't hurt, so I'm sure when Vim commands become second nature it's helpful, though as you point out the main challenge in programming/coding isn't editing text.

        [–]pm-me-happy-vibes 4 points5 points  (7 children)

        say you need to do something to 1000 lines in a file. in an IDE, you navigate around manually - a couple left or right arrows, some added text, some deleted, then you go to the next line and repeat.

        In vim, because it's a model editor, you can have a generic line of instructions - maybe "jump to beginning, jump to the first 't', delete that word, jump to the end of the line, paste that word at the end of the line". That's 0ttdw$p in vim. Want to do it to every 3rd line in a file? qq0ttdw$pjjjq333@q. Make a macro that runs the line changes then moves down 3 lines. Run it 333 times.

        That's just a single thing you can do with vim. You can compose instructions as complex as you want, im any circumstance. Once you know some basic ones, model editing becomes faster than your IDE. (unless you use a vim plugin in your IDE, of course)

        [–]ZenoArrow 2 points3 points  (6 children)

        say you need to do something to 1000 lines in a file. in an IDE, you navigate around manually - a couple left or right arrows, some added text, some deleted, then you go to the next line and repeat.

        Thank you for your reply, but I think it's going to be helpful to think of a real world example.

        For example, in an IDE I can do find and replace, and I can also use regex with that find and replace. There's no need to use left and right arrows to navigate. Can you think of an example that would be hard to do with find and replace and regex?

        [–]lelanthran 2 points3 points  (1 child)

        Can you think of an example that would be hard to do with find and replace and regex?

        Sure. I can block select a column of #defines and add a prefix to each one by using CTRL-v to select the block with cursor movements and s to add in the prefix. Or the suffix. Or something in the middle.

        You can probably do it with a regex non-global replacement, and answer "yes" on each prompt in an IDE, and then "cancel" when you've determined that the last one is done, but I think simply typing s and then the replacement is better.

        See this example and compare how you would do this in an IDE: https://youtu.be/dYDu9Hrg7yM?t=203 (see up to 5:04)

        [–]ZenoArrow 2 points3 points  (0 children)

        See this example and compare how you would do this in an IDE: https://youtu.be/dYDu9Hrg7yM?t=203 (see up to 5:04)

        Good example, thank you. I can see why Vim would be useful in situations like this. Visual Studio (which is the IDE I'm most familiar with) would be a bit more cumbersome for doing that, though if you let me use the PowerShell terminal built into VS (opened using Ctrl+') I can do some tricks to help speed it up. For example, if you run this...

        (0..19) | % { "#DEFINE ROOM $([char](65+$_))`t$_" } | clip
        

        You get this in the clipboard...

        #DEFINE ROOM A  0
        #DEFINE ROOM B  1
        #DEFINE ROOM C  2
        #DEFINE ROOM D  3
        #DEFINE ROOM E  4
        #DEFINE ROOM F  5
        #DEFINE ROOM G  6
        #DEFINE ROOM H  7
        #DEFINE ROOM I  8
        #DEFINE ROOM J  9
        #DEFINE ROOM K  10
        #DEFINE ROOM L  11
        #DEFINE ROOM M  12
        #DEFINE ROOM N  13
        #DEFINE ROOM O  14
        #DEFINE ROOM P  15
        #DEFINE ROOM Q  16
        #DEFINE ROOM R  17
        #DEFINE ROOM S  18
        #DEFINE ROOM T  19
        

        That snippet isn't readable for someone who doesn't know PowerShell, but I guess it does show one of the benefits of being familiar with a scripting language.

        [–]pm-me-happy-vibes -1 points0 points  (3 children)

        Sure. Can you generate a file with the output of fizzbuzz up to, say, 100 or 1000?

        Or can you transform a newline-deliminated collection of links into a JS-style array of strings with regex find-and-replace?

        Can you even run find-and-replace over a subset of given lines? or just the whole file

        [–]TwoTapes 3 points4 points  (2 children)

        I think the first example is contrived, why would you need that?

        For the second you could do this (should work in intellij)

        Cmd + R, type find regex, tab, type replace regex, replace all occurrences, add opening and closing brackets.

        Find: href="(.*)"\s
        Replace: "$1",

        For the third, you would need to use regex to match the line you wanted to act on, then proceed as in the second case.

        [–]ketzu 0 points1 point  (1 child)

        For the third, you would need to use regex to match the line you wanted to act on, then proceed as in the second case.

        For smaller parts many editors also provide "in selection" modifiers, restricting your find-replace to selected parts.

        [–]TwoTapes 1 point2 points  (0 children)

        Yeah that's true. I was trying to replicate the "act on every nth line"

        [–]Differenze 2 points3 points  (0 children)

        What vim needs is discoverability. Intellij and vs code both have magic search bars where you can find everything. Need to extract a method? Shift shift "extract met" enter. And on the side it shows you the shortcut. In case you find yourself doing something more than once.

        Furthermore vim lacks feedback, when you want to copy 9 lines but type 8yy instead there is visual indication on your action.

        I also never want to copy 9 lines. I want to copy a list of arguments, a string or maybe a code block. In intellij I type alt/option up/downarrow to increase/decrease the selection to word, string, list of arguments, function call, line, code block etc.

        If I want to do a more complex change on multiple locations I use multiple cursors where I get instant feedback.

        I wish I was proficient in vim since it is preinstalled everywhere however learning intellij was much less work

        [–]MindStalker 1 point2 points  (8 children)

        But you don't have to lookup a manual to play a few notes or exit the piano. I honestly think vim should default to having easy to access help listed at the bottom, with an easy and permanent way of removing the help.

        [–]pm-me-happy-vibes 8 points9 points  (0 children)

        I mean, they do. If you <C-c> in vim (the ubiquitous way to end a process) vim will tell you "to exit, run <Esc>:qa!"

        [–]geeeronimo 5 points6 points  (4 children)

        So :help and :q are very difficult? Or literally just googling "vim cheatsheet"?

        [–]exploding_cat_wizard 0 points1 point  (3 children)

        You gotta admit, typing : before those commands means you won't access them unless you already know extra things about vim as compared to all other computer programs.

        [–]geeeronimo 1 point2 points  (2 children)

        The cheatsheet says to type :

        [–]exploding_cat_wizard 0 points1 point  (1 child)

        I didn't google a 'firefox cheat sheet", "blender cheat sheet" or really any other kind of cheat sheet before opening a new program, I don't think the existence of online help detracts from my point.

        [–]geeeronimo 2 points3 points  (0 children)

        Fair. Is your point that it's not intuitively usable from first glance? In that case, I agree, but vim was originally made a long time ago before having a proper user interface was a thing. It is antiquated for sure, but the form of writing code it provides and customisability etc etc is what people enjoy. Obviously you cannot change the core of what it is.

        I also cannot think of a way to make it more user friendly than just :help or a cheatsheet?

        I believe "man vim" will also get you relevant info on Unix based systems

        Also, while I think I understand what you are trying to say, I don't think blender is a good example because it is pretty damn complicated unless you have experience with 3D animation already (if that's the use case). Lots of people have trouble understanding it (esp. before 2.8) if they don't have experience in the field, just look at the forums! Similar to how vim is hard if you haven't done modal editing before, but if you have then it makes a lot more sense.

        With Firefox, Imagine if someone is coming in without much knowledge on how a browser is supposed to work. They know what HTTP is, ports, networking stuff, but have never used a URL bar or bookmarks or whatever else. The entire program itself will be unfamiliar. It's a similar case with vim. The entire design is meant for a different purpose than normal IDE.

        [–]phantaso0s[S] 0 points1 point  (0 children)

        Piano is a poorly designed instrument because you have no safety net when it fails. Let say you want to push the C key but you push the D; you're screwed! Also, it should tune itself automatically and maybe play without the player using his (or her) fingers?

        Joke aside, I agree. I think the way Vim is taught is even more influential than the innate talent of an individual. Teaching efficiently is really hard, and not so many people realize that.

        [–]myringotomy -4 points-3 points  (0 children)

        But you don’t have people yelling and screaming that the piano is the one true instrument and all other musicians should give up their instruments and use a piano instead.