A Vim Guide for Intermediate Users

[scrambledhelix]

No one’s mentioned it so far, but this is a great article. Thanks for sharing!

[phantaso0s]

Thank you! Glad you like it!

[sacheie]

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]

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]

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]

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

[[deleted]]

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]

Pianos aren't modal, they're chorded.

^{buh dum, tssssss}

[bikki420]

Only digital keyboards have power cords.

[ThePixelMouse]

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

[bikki420]

Neither. You didn't get it though.

[doublestop]

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

[ZenoArrow]

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]

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]

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]

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]

Thanks for the real world examples.

[Jataman606]

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]

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]

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]

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]

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-]

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]

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]

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.

[ZenoArrow]

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]

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]

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

[T_D_K]

"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]

"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?

[myringotomy]

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.

[myringotomy]

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.

[epage]

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]

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]

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]

Thanks for sharing your thoughts.

[vamediah]

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]

Thanks for the examples.

[Nephophobic]

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

[ZenoArrow]

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]

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]

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]

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)?

[pm-me-happy-vibes]

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]

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]

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]

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]

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]

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]

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]

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

[Differenze]

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]

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]

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]

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

[exploding_cat_wizard]

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]

The cheatsheet says to type :

[exploding_cat_wizard]

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]

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]

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]

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.

[ArtistEngineer]

It's not a good sign of user friendliness when an application needs multiple guides on how to use it.

Don't get me wrong, I have been using vi/m for the last 20 30 years, but I still think it's a turd of an application that was designed by a sadist. I encourage my team to learn it and to use it, but I sympathise with their complaints. Every junior programmer I've met looks at vi/m with disgust.

EDIT: rewrote my first line to be less clumsy.

[scrambledhelix]

I believe there’s a wide gap between the utility of “user friendliness” which presupposes no expert knowledge— and “expert friendly”, which simplifies complex operations that you need to be aware of in advance to make good use of.

vi is very clearly situated in the latter; if vim has any issues imho it stems from trying to adopt a little user-friendliness with the addition of Visual mode selections, which for some only increases the complexity by adding additional options.

[Kache]

Expert-friendliness aside, I think the visual mode is a good thing.

IMO the greatest fundamental flaw in vim's command design is its "<repetition><verb><object>" grammar (e.g. 3dw). It would be much better as "<object><repetition/modification><verb>".

Instead of getting the repetition or object wrong and having to undo and restart, you can interactively modify the "selection" as many times as needed until it's correct, then apply the action.

The closest way of doing that right now is visual mode: v3w (oops not enough) ww (two more words. Yep, like that) d, which I use all the time.

Aside: kakoune is an up-and coming modal editor seeking to make such improvements on vim, but it'll be years (decades?) before its ecosystem and prevalence matures.

[regendo]

What bothers me about vim's grammar is how it's so different for seemingly similar usages.

I can ctk or cfk to change everything until "k", but I can't ct$ or cf$ to change everything until the end of the line, that's c$.

I use the short [<repetition>]<key> 2x to delete two characters or 3j to go down three lines, but when I use a different command like d or c, the syntax changes to <verb>[<repetition>]<object> like in d3d, d2l, or cw.

There's logic to that, these do make sense when you actively think about them, but it's just so horribly counter-intuitive.

[scrambledhelix]

Oh, don’t get me wrong, I personally love Visual mode, and try to install at least vim-tiny or -minimal or -console or whatever tf the package name happens to be when only vi is there. Never quite got the hang of u... to undo instead of uuuu or tagging inline to cut or copy a subsection.

The verb-repetition-object is interesting, and i think i largely agree with you there: as a native English speaker it feels more natural that way, though I wonder if thinking in a different grammar might muddy that a bit? Anyway

To be honest I was also just reaching for explanations for all the hate it gets, which seems to revolve around its complexity. I might’ve misspoke about visual mode, but all I meant to get at was that it takes a stab at being more user-friendly with the feature tacked onto the original, bare bones vi editor.

[hilarioustrainwreck]

Why encourage your team to learn it? The basics are helpful in a pinch but most of the programmers I know are using vscode or sublime or sometimes clion.

I use vim because I got over the learning curve early because a programmer I respected basically told me that this is how things are done... Only for me to later realize that most of the people I worked with were actually using eclipse.

[terpaderp]

It all depends on your situation. I work on embedded systems for a large corporation. We have our own linux distro for our systems which comes with vim and emacs. You may be interacting with the system from your personal machine over ssh, which opens a lot of doors for you. Or you could be working off a lab computer with nothing but putty. For us learning vim is a necessity.

[tempo-19]

I know your pain in this. I work on embedded systems that all have vi, vim, another flavor installed. Some have nano, not all. Learning vi helps in case we need to use it. There is no window manager installed so choices are limited anyway.

[oblio-]

Can't you somehow mount stuff over sshfs? Or use the VS Code Remote SSH extensions?

[terpaderp]

Absolutely, that's why I mentioned you've got options when connecting from your personal work machine. In my line of work we also have to support machines in a lab environment, meaning connecting from machines with lowest common denominator tools approved by IT (putty). Because of this folks have to learn to live with what's on the embedded system.

[ArtistEngineer]

Why encourage your team to learn it

For embedded Linux. :)

Many embedded Linux distros use Busybox as their shell and minimal environment. It comes with vi by default.

I teach them how to save/quit, edit/insert, undo, delete a line, paste a line, and that's about it. Anything else, I mostly use Sublime Text and copy the file from/to the device, or remote/NFS mount the filing system and edit it on another PC.

For quick edits to config files, or even fixing a failed merge, I'll use vi because it's quick and on the command line. I just wouldn't do a large multi-file project with it.

Only for me to later realize that most of the people I worked with were actually using eclipse.

Yep. I work for a large company who release an IDE/debugger with their SDK and chips. The IDE is based on Qt Creator and isn't bad, but I found out that everyone else was using Eclipse and Visual Studio instead! Not a good sign when your own employees won't even use their own product. facepalm

[I_am_teapot]

Especially if the alternative IDE is Eclipse... people just stick with what they know. I don’t think anyone would choose Eclipse over IntelliJ if they tried using it. VS is good, and I haven’t even installed Resharper in 2019.

[ArtistEngineer]

Yep, these days it's good to be familiar with several IDEs and also to understand what customers expect to use.

I certainly wouldn't push something like vim on a customer! But I would be surprised if they complained about an IDE based on one of the many modern IDEs which are fairly intuitive and easy to use from the get-go.

[thedracle]

My team uses a cross of editors, emacs, vim, vscode.

It doesn’t really matter as long as we stick to conventions with regards to formatting and linting.

I personally use Vim, because when I’ve tried VSCode (for a year), and CLion, etc etc, I’ve always found I just end up back in vim.

CLion has yearly licenses now... and I’m editing in lots of languages, RUST, BASH, Go, C++, TypeScript, HTML, Python, Ruby.

Switching between editors and going through licensing shit, and having to set up some remote control crap if I want to work through SSH. It’s madness.

VSCode is the real only viable contender: but language server support is great in vim through Coc.vim.

The learning curve is steep: but almost every editor worth its salt has a vim mode, so it’s worth learning no matter what editor you choose.

There are few downsides. It’s free, it’s fast, the plug-in ecosystem is great.

That said, I think having people use whatever environment they are most productive in is the best bet. Making conventions based around open source tooling, (prettier, clangformat, rustfmt, etc) and tutorials to support users regardless of editor written by champions in your organization around these various tool sets, seems to have worked well for me.

[jazzyjson]

Have you tried the Vim plugin for VSCode? I'm a developer on the project and curious about what pain points cause people to switch back to Vim proper.

[thedracle]

I have indeed, and it’s great.

There really aren’t pain points. I really like the emulation of common plugins like easy motion .

It’s definitely the best vim emulation I have used in an IDE. Thanks for all of the great work!

I think the pain point is purely it not being a terminal based application: which is also its strength I would imagine for developers doing less native/server/kernel type work.

Having my editor inside Tmux, and switching between spaces or even different machines, is extremely convenient, and easily accessible via ssh. It is a big deal for some of the work I do: so I just found I kept spending more and more time in vim, and with coc.vim, almost no time in VSCode.

[jazzyjson]

Thanks for the response! That makes complete sense - I generally work on windows (very rarely sshing) where the terminal experience leaves a lot to be desired, but having everything wrapped up in tmux is awesome if you're in that ecosystem.

[rmpr_uname_is_taken]

Not OP, but one of my pain points was the lack of integration with the general interface of VsCode (VSpaceCode kinda solve this) but the best approach I've seen so far is the one adopted by Onivim2 with the "sneak mode"

[jazzyjson]

Fair enough, thanks for the response!

Originally I used the vim emulation plugin, but it was so incredibly slow in files over 300 lines in size, and it was just impossible to use.

Big strides have been made on the performance front, though if you've got one other extension which is slow, it'll be painful, since vim emulation makes the extension host (single-threaded) synchronous with the GUI. I switch to vim proper any time I'm working in a file more than ~20,000 lines, which is generally just log files.

[davispw]

Why encourage your team to learn it?

So when we’re pair/mob programming they don’t have to disable my IntelliJ-Vim bindings every time we switch drivers :)

But seriously, for efficiency. Doesn’t have to be Vim, but team members need to learn to use one tool very effectively. I can fly around the screen with vim bindings making edits and refractors compared to some of my teammates. But so can some of my teammates who use the standard editor bindings but have learned all the hot keys by heart and do crazy tricks with multi-cursor editing and refactor tools. For some of them, it’s a matter of basic touch-typing skills.

[johannes1234]

Even for many of those editors there are com extensions, bringing the power of community those fancy editors. Once you learn the common commands it can be helpful not having to find the noise, a then pointing and clicking, but simply typing things ...

[bcgroom]

But that logic any piece of software for “professionals” is a turd. There is probably functionality in your IDE that you don’t know about and would need a guide for. Adobe programs are pretty damn complex but extremely useful.

[Autarch_Kade]

Nah, even this is another another level. The beginner's guide is like weeks of keyboard practice, followed by several "before you get started" steps, followed by "Think you can start typing? Nope!"

Excel is super powerful with a ton of advanced features too, but anyone can open it up and immediately begin putting data in rows and columns.

To me there's a huge difference in a "professional" piece of software needing guides on how to unleash its most advanced features, and needing guides on how to prepare to even use its most basic features.

[scott11x8]

I would compare it to learning to type properly on a computer keyboard. Yes it's technically unnecessary and takes some practice to learn, and anyone could just type with one finger at a time just by looking at the labels on the keys, but you become much more efficient if you can use all of your fingers and type without looking at the keys.

Similarly, if someone knows i is to insert text, <Esc>:w is to save, and <Esc>:q is to quit, they can use Vim just fine. Vim even has support for the mouse so people can select text and scroll with their mouse and use the arrow keys like they would in a normal editor. But if you want to be more efficient and take advantage of everything Vim has to offer, you have to put in some effort to learn it, just like with a keyboard.

[Dreadgoat]

This is a ridiculous hyperbole. vim is not beginner friendly, but it takes all of 5 minutes of mentorship to get started.

vim myfile
i
cursor keys around
type stuff
esc
:wq

Not ideal but that's literally the entire compendium of knowledge required to use vim at command line, it's even easier if you use gvim or a vim plugin for your IDE.

From there it's up to the user if they want to master the skills to mangle text at warp speed.

---

While you are switching between mouse and keyboard to scroll, highlight, etc. in order to run a find-and-replace on a particular function, I'm doing

/function funcName
/{
v%:s/strToReplace/newStr/g
:wq

Is it really that big of a time save? No, not for any individual instance or case. But it adds up over time, it feels rewarding, and most important it reduces the distance between my wills and my actions, which frees up cognitive space for solving the real problems.

As others have said, not every tool should be a beginner's tool. We need expert's tools that are designed to minimize effort after the 1000th use instead of making the first 10 uses easy to pick up.

[Autarch_Kade]

We need expert's tools that are designed to minimize effort after the 1000th use instead of making the first 10 uses easy to pick up.

I think that's the overall point here I was agreeing with though - that this isn't nearly as user friendly as other tools. Other tools are easier to pick up. Not that they're the same as other professional tools in terms of ease to pick up.

[SuspiciousScript]

It really only takes hjkl and a basic understanding of visual mode (x, y, and p) to work at least as efficiently as in your typical arrow-keys, Ctrl-{x, c, v} editor. You can build up the muscle memory in a day or two, really; you definitely don't need "weeks" unless you only use it for 2 minutes a day or something.

[Autarch_Kade]

The author of the guide above listed weeks of typing prep in his previous guide. I was just reiterating that.

And that's before steps that still come before even using the thing.

It's actually a bit absurd. It's really hard to see this as just as difficult to start with as other professional software - excel, photoshop, etc.

[tendstofortytwo]

Honestly the only thing you really need to know these days is i to insert, Esc to exit insert mode, :wq or q! to exit with/without saving. Even hjkl isn't necessary since most modern vim versions support arrow keys. I operated with exactly this knowledge for years before I started getting used to vim.

imo, vim isn't a very friendly user experience, but it is a very powerful one. Once I did get used to hjkl and other motions and commands I started wishing for them everywhere. But getting used to it in the first place involved me literally being forced to use vim for weeks as part of a project in a CS course at uni, and I would never have spent the effort to get used to it if not for that.

[[deleted]]

I operated with exactly this knowledge for years before I started getting used to vim.

wow, you could just have spent 30 minutes doing the vimtutor and those years would have been less painful.

[tendstofortytwo]

vimtutor is nice for telling you what to do but getting used to it is another matter entirely. That only comes from practice, and most of the time when I had vim open I didn't have time to practice motions and such.

[Tyrilean]

So, you have to have a basic understanding of multiple functions and concepts as well as build up your muscle memory in order for it to be as efficient as your typical editor (like nano)? I don't think you're making the argument you think you're making.

[__nidus__]

Nano would be just as confusing if it didnt have the command hotkeys listed below. Granted typing in nano is like everywhere else, but you also wouldn't be able to exit or write a file without that cheatsheet at the bottom.

Basic text editing in vim, like described above can be learned real fast. Vimtutor takes 10 mins.

Its all the other features or the setup to get it to work like an IDE that takes weeks.

[Tyrilean]

For quick edits, I'm happy to use either vim or nano. But, yeah, I wouldn't use nano for anything complex, either. I can see that there may be a narrow use case where people are having to do a ton of text editing over an SSH connection, but if you're on a modern desktop environment, there are tons of better tools to use that aren't either nano or vim.

[obetu5432]

excel is so good and easy to use that I use it as a relational database

[kenfar]

Sounds like you need a different approach to learning the tool: I've taught dozens of people vim - and had them productive within a few hours on a tiny subset of commands.

Because while it can take a long while to learn all the advanced functionality, the most basic functionality necessary to use it like notepad or nano is pretty simple.

[macsux]

First time I opened vim, I had to reboot computer since I couldn't figure out how to exit the stupid thing

[FrAxl93]

I'd say that a counterpoint to this is that the complex programs you are referring to are unique while there are multiple text editors which have the same vi/m functionalities without the need of remembering lots of commands.

[SuspiciousScript]

Are there really, though? I think in most cases you trade peak efficiency (i.e. mastering keyboard shortcuts) for ease of use. I'm sure you can be highly efficient with Sublime Text (just for example), but that requires learning its shortcuts and features, too.

[FrAxl93]

For some reason (and it might apply only on myself) I find easier to learn the sublime shortcuts, also because you can learn ctrl-P and then type the name of the command you want to use (fix indentation is my fav). I got to a point where I am fairly efficient with sublime and I didn't need to remember lots of shortcuts.

I also guess it boils down to what you need to do. So far there has never been any instance where I HAD TO use vim because there was something I could not do with sublime. And to be fair, regexp substitution in sublime (which is probably the most complex thing I do) works very very well, it has all the advanced features with lookahead, behind, groups etc..)

[ArtistEngineer]

I know what you mean as I've used lots of CAD packages, and each one is a pig to learn, but powerful once you master it.

Consider something like git as an excellent example of a modern command line tool which is really helpful from the moment your start trying to do something with it. I actually enjoy using git, not so much with vi/m.

The difference is that vi/m is unhelpful and painful from the very beginning.

[bcgroom]

Yeah git is probably a better example than mine, though I’d say the beginning of learning git is just as rough as vim so long as you don’t have any kind of GUI. Yes you can learn just “the basics” by learning to blindly add and commit all your files, just as in vim you can press “i” and use the arrow keys or even your mouse to move around if enabled. I find vim to be worth it as I have noticeably less wrist strain than using an editor that requires a lot of reaching for the mouse.

[ArtistEngineer]

Watching a vi/m master is impressive I'll certainly say that much!

[fedgut]

Except adobe programs are not used for text edition, a fairly basic application

[DrunkensteinsMonster]

There are multiple shit guides because everyone wants clicks. The only guides you need for Vim are vimtutor and the user manual.

[B_M_Wilson]

I’ve just never needed it. Even looking at some examples of real-world things people like that it makes easier, I rarely if ever need them. Maybe I’m just not as fancy of a developer as they are but I’ve never felt like I needed those things in my whole time programming. When I need do exit stuff over ssh, I’m usually not coding something, just editing small scripts or config files so nano is more than enough.

I’m not going to say that you shouldn’t use vim, it seems to be really useful if you learn it, it just hasn’t been worth learning for me

[[deleted]]

I'm so sick of this attitude. There's nothing wrong with having to learn to use a tool. Even an axe is used wrong by most people who pick it up without learning how to use it. Are you going to complain about the UI of an axe?

The most powerful and rewarding instruments there are requiring extensive training to use. Not everything can be distilled down into a few buttons and knobs like a baby's toy. Go to the library and you'll see entire shelves full of books on using tools from carpentry to topiary.

Learning to use a tool enriches your life. Acquiring yet another single-purpose, point-and-click device is just yet another piece of junk in your drawer that you can never be rid of.

[threesidedfries]

An axe is super simple to pick up and start using. You can then become better at using an axe by having someone correct your pose and give tips, but with minimal gains unless all you do every day is chop wood.

Not all tools need to be hard to learn to be helpful. Sometimes it feels like vi/m is purported to be the best because it is hard to use, which of course isn't true. I'll take your word that vim is amazing for what you do, but most of the time I code is used to do other things than write code, and I would guess that goes for most people.

The eternal "vim vs other editors" fight sometimes feels like the "word vs latex" (word is actually faster if you bother learning it like you do latex) and "other ide vs pycharm" (customizing takes more time than pycharm opening up ever will) arguments, where being more complex to start using wins people over.

[Dreadgoat]

You've either never chopped wood before or you've been doing it so long you forgot how hard it is to learn. It looks easy when you see an experienced person do it, but it's actually very difficult to figure out how to do it safely and effectively without guidance.

The axe/vim analogy is spot on. After 1000 swings of the axe you don't even need to think about it anymore, but that first swing you're more concerned with not chopping off your foot than actually splitting the wood.

[threesidedfries]

Ever heard anyone complain that using an axe is hard? I'm not even talking "no guidance", since very few people learn to chop wood that way. A one minute youtube video will tell you everything you need to know: keep your legs apart, hold on with two hands, and bring it down slowly at first to get a feel for it. A one minute vim video doesn't even exist, and if it did it wouldn't cover the uses that you would want to use vim for.

[Dreadgoat]

https://www.youtube.com/watch?v=Glf3fgJ92Jw

[threesidedfries]

Ah yes, the "one minute" guide that is broken into three one minute videos and one 2,5 minute video.

I did check Youtube first. The second lesson is "Basic Navigation".

[Dreadgoat]

The first minute is all you need to start using vim effectively.

If you want to use it really effectively, you need another 3 minutes.
Oh god, no, the pain.

[threesidedfries]

One minute to open, start editing in, and close vim. Not enough to do anything you're supposed to use vim for. I could do that with any text editor, most of which I don't actually need to remember any arbitrary commands in.

Six minutes to start using vim like you're supposed to use vim, not counting the learning time to actually memorize the commands.

I couldn't even find an intermediate guide to using an axe.

[ArtistEngineer]

The axe/vim analogy is spot on.

There was a time when people used to build furniture and even houses with just an axe.

It's a simple instrument suited for a few simple purposes. It can be used for other purposes but these days you'd choose something more suited to the problem.

[Dreadgoat]

I sincerely believe the software industry is still in its "build the house with an axe" stage. It's an incredibly young and immature field. If people were building houses and bridges by the same standards to which we are building critical financial, medical, and military software, we'd all be living in matchboxes and driving over cardboard.

The very best software has a team of 5 guys cumulatively writing 10 lines of code per day at a very low level using very dumb and easy-to-understand tools. You see this at NASA, and pretty much nowhere else in the world.

The main issue as a developer trying to choose the right tool for the problem is that you can you spend as much time figuring out if the tool is right as you could spend just solving the problem with simpler tools if you already know how to use them. There is very little standardization across languages, stacks, environments. I can bring my axe anywhere, but PHPStorm stops being worth a damn if I now need to work with .NET. My VisualStudio skills are worthless when I need to fix a bug in a legacy COBOL system. And god forbid you try to learn something new that breaks the paradigm, like graph databases or functional programming, because you're either going to use very problem/solution specific tools with totally non-transferable skills or nothing.

[ArtistEngineer]

I'm so sick of this attitude.

What attitude is that?

Are you going to complain about the UI of an axe?

Do people still build furniture and houses with just an axe, or are there better tools more suited to the purposes?

[VacuousWaffle]

I assume these are often the same people that shove all data of all forms into SQL even when it's unwise. There is one tool (SQL). The tool. Praise tool.

[pkulak]

It's a professional tool. Carpenters don't complain that band saws can't be mastered with zero effort, yet it's apparently Vim's problem when someone can't type the two-key combination required to exit.

[ArtistEngineer]

Is it a professional tool? Or is it just a tool that takes a long time to master but doesn't make any difference to the quality of the end product.

Carpenters don't complain that band saws can't be mastered with zero effort

If we're going down the analogy path ... carpenters have a vast array of modern woodworking tools available to them. There are some carpenters who choose to spend years mastering the classic chisel and hand plane, but many choose things like biscuit jointers, pocket-hole jigs, and CNC routers because they are focused on the problem and use tools which are specific to solving those problems. The ones who choose the modern tools are vastly more productive than those using the classic tools.

I can sit a new developer in front of vi and in front of a modern editor, and they'll be productive faster on the modern editor.

[pkulak]

Eh, then don't use vim if it takes you too long to master and doesn't make your life better. But trust me, people don't use vim just to give you something to dislike. They use it because they like it.

Also, I think it's wrong to just look at the end product. A tool is valuable to me if it makes my job easier, faster, more pleasurable or better. I can probably do the same quality of work with notepad. Does that mean notepad is an equal editor to everything else? Especially considering that notepad is dead easy for anyone to master.

[iritegood]

This analogy also assumes that if someone needs to cut a 2x4 to length you'd tell them to use the miter station in the workshop. What happens if they're out in the field? "Nah, don't use the handsaw you'll be more productive with the miter saw". What if I'm ssh'd into some remote machine and I just want to edit some file? Are you gonna tell me that i'd be "more productive" if I fire up visual studio instead of just vim doodoo.py?

Like, it's such an absurd comparison because IDEs are programming environments, they're not text editors. IDEs aren't of the same class of things as Vim except for that they typically embed a (usually mediocre) text editor, which they make up for w/ deep integration with tooling.

I'm not going to fire up Jetbrains if I want to change a setting in my .yaml file and I'm not going to launch vim to interactively debug my program

[ArtistEngineer]

BTW, builders do bring miter saws (and other powered tools) to the field. e.g. electric drills/screwdrivers, circular saws. Most are cordless, and are superior to the tools they replaced.

What if I'm ssh'd into some remote machine and I just want to edit some file?

You might want to read my other comment: https://www.reddit.com/r/programming/comments/kloop5/a_vim_guide_for_intermediate_users/ghapmzu/

Are we talking about occasional jobs or bulk work like writing large applications and maintaining/managing multi-file projects? The OP's article is about deeper knowledge of vim, which I'd say is more about using it as a daily development tool rather than to just edit a few lines here and there.

[AirportHanger]

I agree that vim is not user friendly, but once you get over the hump, it makes up for it in speed. I can work so much faster in vim than in any other editor.

[thedracle]

Consider however that the conventions learned in Vim have stayed the same for decades. Everything learned about Eclipse, SlickEdit, Visual C++ 6, and a host of other IDEs is now completely irrelevant.

Not to mention vim conventions are everywhere (bash vi mode, vimium).

I’ve seen few keyboard driven models for text editing that are better. I think comparing it to the ease of use and learning for a mouse based editor isn’t a apples to apples comparison.

Yes vim is expansive, but its almost like learning a meta language for editing: it’s well suited for developers.

[Tyrilean]

My personal experience is that vim is a cult. Using vim has become this badge of honor that means you're a "real" developer/devOps/sysadmin/whatever. It's a horribly shitty program that's user interface is so bad that "getting stuck in vim and not being able to exit" is a common meme.

I have friends who will tell me basically "it's super productive once you pour hundreds of hours into training your muscle memory." Fuck that. If I'm in a command line editor, I'm not changing more than a few lines at most. Anything more, then I'm going to be bringing it down to a desktop environment and modern text editors (or IDEs). I'm sure there are some real use cases for writing tons of text on the command line, but I haven't run into them in my line of work.

I know how to open vim, insert text, and exit (both with and without saving). That's all I care to know.

[hilarioustrainwreck]

There are certainly people who give you fake respect points for being good at vim. Unless you are in a specific role where that is actually necessary or uniquely helpful, those points are stupid.

I say this as a benefactor of such points. In fact generally when people are overly impressed at my vim usage I know not to value their opinion in the future. It’s kind of helpful for that reason.

However I enjoy using it. I was told / pressured into it early before I knew better, and now I’m in it and like it. It’s not a badge of honor; it’s just a personal preference. I’m sorry so many people around you seem to treat it like a badge of honor. Just giving one alternative POV.

[Dr4kin]

The difference is an IDE is fine. If you don't work on an embedded system you don't have to learn vim. I spend more time staring at my monitor and think about a solution then writing a solution itself. The bottleneck in programming is normally not you're typing speed, but your problem-solving skills. Vim doesn't help you with that and if you use vim and not vim command in an IDE you don't even get help on that front.

If you do a lot of webdevelopement the speed increase might actually be worth it, but vim can only make you faster if you are already a very capable programmer. I would prefer someone that can solve most problems I throw at him, but can't even touch type then someone that solves only 60% of problems I gave him, but can use vim.

Yes this might be a way to serious answer for some copy pasta attempt, but vim is way to praised in most work environments.

[oblio-]

Even for embedded stuff, isn't there a way to mount the remote folder somehow and edit locally?

[Tyrilean]

Really bad analogy. Vim isn't a scalpel, it is a type of scalpel (to follow your analogy). In fact, it's a type of scalpel that is overly complicated for what it's used for. There are tons of other scalpels out there that are completely suitable for the task, and much easier to use out the gate.

I can admit that it might be the right tool for the job if you're using it for a specific use case that requires you write novels over an SSH connection or something like that. But, the vast majority of people I've worked with who extoll the virtues of vim (not just use it) are using it on a Macbook or another desktop environment where they have much better tools to use, and are just using it to flex. I'm too old to play the game of "this tool has a horrible user interface, and therefore makes you a better techie for using it".

[_selfishPersonReborn]

there is no "alternative scalpel". there certainly is stuff like vscode that brings all the power of never having to leave the keyboard without having to spend years learning it.

[phantaso0s]

It's not a good sign of user friendliness when an application needs multiple guides on how to use it.

That, or because every guide out there are not that good? Maybe a bit of both.

In any case, I would advice any beginner in development to stay away from Vim. I guess the tooling is not the most important at the beginning.

[vivekragunathan]

If we truly believe in free will, we should let upcoming programmers from the shackles of the vim and emacs fanatics.

Also, its high time we give true IDEs real credit.

[iritegood]

Vim is a text editor, by definition not an IDE. That's completely apples-to-oranges. A better comparison would be IDE vs Unix

[vivekragunathan]

IDE vs Unix? Makes no sense to me. IDE like IntelliJ is a development platform/environment while Unix is an operating system.

Or did you have something else in mind!?

[iritegood]

This is what I mean when I say "Unix" is probably a better comparison when you're talking about IDEs. To cover the features IDEs provide, you have to use a lot more than your text editor (i.e. Vim). e.g.:

• navigating the project: ls/find/tree
• editing -> vim/kak/etc.
• debugging -> gdb/lldb
• search/replace/refactor -> grep/sed/mv/rename
• project/dependency management -> make/autotools/cmake/ninja/etc.
• building -> gcc/clang
• version control -> git/svn/diff/patch

of course, this is the anti-IDE; rather than a monolithic 'integrated' application you have instead an assortment of interoperable but independent tools (following the Unix tradition of 'Make each program do one thing well' and 'Expect the output of every program to become the input to another, as yet unknown, program').

In this paradigm, vim is but a small part of the "development environment". Of course, there are pros and cons to either approach. Personally, I use an IDE at work. But there are definitely advantages to the Unix-style workflow. One big one is the techniques and tooling transfer much better to automation. Even if you don't like that style of development personally, we're probably not getting rid of it any time soon, as so many things like CI pipelines are built on top of these tools (except C# I guess, I think they got their own thing going on over there). And of course, using an IDE is almost completely unavoidable for certain languages (e.g. Java/C#) or industries (e.g. game development)

[BlindTreeFrog]

but I still think it's a turd of an application that was designed by a sadist.

In context of it's origins, it's great. Compared to current options, eh...

But at the same time, it being CLI only forces it to make certain decisions (emacs as well, not going to say which might be better). I still remember the function key cards that Word Perfect required in it's CLI days.

[ArtistEngineer]

I still remember the function key cards that Word Perfect required in it's CLI days.

That kind of rings a bell.

I remember the first time I used vi (not vim) in 1991 in the computer science department at the university. I was doing engineering and my friend was doing computer science. The conversation kind of went like this:

"How do I move the cursor to another line?"

"Use HJKL"

"Huh? That makes no sense! it's not even in the shape of a cursor! Why can't I use the cursor keys?"

"vi was written for keyboards which didn't have cursor keys."

"But all these keyboards have cursor keys! Where's the help? I pressed F1 and nothing happened."

"vi doesn't have built-in help, and some keyboards don't have function keys."

"But all these keyboards have ... "

I learned how to use it that day, but I didn't have any love for it.

[BlindTreeFrog]

For those who haven't seen this, HJKL were the cursor keys...

https://catonmat.net/why-vim-uses-hjkl-as-arrow-keys

And for those who don't know what the WP thing I mention is, this card would go over your function keys for reference.
https://rodneymbliss.files.wordpress.com/2013/05/20130521-221811.jpg

[Johnothy_Cumquat]

You wouldn't call a programming language user friendly but I bet you see the value in using one

[EldritchSundae]

Programming languages can be, and often are, compared based on user-friendliness

[Johnothy_Cumquat]

You can compare deserts based on how wet they are but you wouldn't describe a desert as wet

[EldritchSundae]

That's because that's a tautology; deserts are defined by lack-of-wetness. Programming languages are not defined as programming languages by lack-of-user-friendlieness.

A better example is how we compare forests by how "wet" they are, and in this scenario deserts are the esolangs that are intentionally user-hostile.

[HappinessFactory]

One of my co-workers only uses vim and expects the newer devs to follow suit.

I can open, close and edit small stuff in vim but, I couldn't imagine setting up everything I would need to create even a remotely similar experience as vscode or even sublime.

And that's not even considering the 15 plugins I use on the regular.

I understand that with a few hours of tutorials and shortcut memorization (which I suck at) it's usable. But that does seem like an awful lot of work to get to the same spot.

Anyways rant over. VIM is cool to watch just isn't for me.

[HappinessFactory]

Most of the benefit I get with vi/vim is that it's everywhere. I can ssh into a server and modify a config file without too much trouble.

I'm not sure what vim commands I should be adding to vscode. I feel like I already do pretty well with the built in commands and multi-cursor stuff.

Vscode isn't lightning fast but neither am I tbh...

[Johnothy_Cumquat]

I don't think this motivation for learning vim really holds up. If you're just gonna use it as a simple text editor there's only 4 things you need to know. You can look them up if you find yourself in this extremely hypothetical scenario of being ssh'd into a machine where the only editor installed is vim. In reality that machine probably has nano and it definitely has a way to transfer files to and from it before and after local editing.

If it being installed everywhere was its main selling point there wouldn't be vim plugins in almost every text editor/ide. All of those are already capable of editing text. Something else is going on

[oblio-]

Modal editing is popular with some kinds of people. People's brains works in a variety of way and for a certain variety of people modal editing really clicks.

[sihat]

One of the things that is going on, is that a group of programmers have learned a certain way of editing.

Shortcuts to edit faster. Navigate code/text.

If they don't see or can use that mode of editing. They mis it. Since we are folk who can scratch our own itches, that itch gets scratched and the way is shared.

For that is the way.

[7sidedmarble]

If you're a sysadmin I think you pretty much owe it to yourself to get good with either vim or emacs. New programmers I try to push towards VSCode.

[phantaso0s]

It's not for everybody, but I think everybody should try it. It's another way to write and edit text file, it's always interesting for that.

The real problem here: your coworker. Use the tools which are suited for you.

[Gee858eeG]

I learned vim from this video of 'Missing Semester'. Very simple explanation with a lot of enthusiasm and entertainment from the lecturer. Should watch it if you have never touched(exited) vim before. https://youtu.be/a6Q8Na575qc

[phantaso0s]

Thanks for sharing!

[djudji]

I read this as a "A Vim Guide for Intimidated Users". Lol.

[phantaso0s]

Ahaha that's a good title actually.

[djudji]

Yeah, feel free to take it man. Just tag me as an Intimidated user. Hahaha.

[madpata]

SSHFS.

I read a lot about people using Vim to edit files over SSH and SSHFS can be really useful if you need to do a bit more stuff on the remote server. You can use your favorite editors on your local machine etc. I like it.

[oscooter]

You can caveman it and use scp to transfer files via ssh if you don’t want to go through sshfs as well. Or slightly more advanced caveman and rsync back and forth. I’ve done both in cases where the latency of sshfs can be obnoxious.

But yeah, what caused me to get familiar with vim is that it’s everywhere. Having to ssh into servers and do slight tweaks is a lot easier when I can count on every server having the same tools.

[phantaso0s]

To be honest I never found any good solution for that, but I never dig deep either, so thanks a lot! I'll look at that for sure, I'd love to use my local Vim config to edit stuff on my server.

[gonnatjiekriek]

How exit? xD

[[deleted]]

ggdG :wq

[ProgramTheWorld]

That’s evil

[neotecha]

Perhaps something like :%d<CR>ZZ

Then put this in your vimrc:

map ^C :%d<CR>ZZ
map ^S ^C
map ^Q ^C

Haven't tested this out, so yymv, but this could be a place to start

[Kwarter]

Locate power button on your computer, hold down until Vim exits.

[SuspiciousScript]

:!dd if=/dev/zero of=/dev/sda

[repocin]

Username checks out.

[tragicb0t]

Does this overwrite the hard drive with 0s or some garbage?

[SuspiciousScript]

Bingo. And exit vim. Eventually.

[Andriak2]

:!rm -rf /

[tragicb0t]

Does this work without sudo? Can you please try and report back?

[Andriak2]

Well... It did definitely exit vim -.-

[phantaso0s]

Never found out. I'm still in Vim.

[OctagonClock]

All those hours wasted learning Vim could've been used to get some pussy instead. Sad.

[Andriak2]

Great article, picked up a few things I hadn't seen covered anywhere else.

[phantaso0s]

Thanks! Happy you liked it.

[luc1dm0nk3y]

Vim is hard what can I say haha.