Getting started with vim | Hacker News Reader

Getting started with vim

lucapette.me

123 pointsgrey-area90 comments

Vim keybindings are amazing. Easiest way to think of it is to think of how frustrating it is watching someone do everything with a mouse, not knowing any shortcuts. Clicking File -> Exit instead of the window's X. Or deleting a whole line of text just to change one word. Not knowing Ctrl-X/C/V.

That's how I feel when I work with someone editing text files without Vim.

Once again I'll recommend Vim Adventures[1]. It's fun enough even my 8-yr-old daughter wanted to play/learn. You learn a few keys at a time; no big deal. Meanwhile, install Vim emulation in your current text editor. Slowly you'll learn keys. Your desire for knowledge will increase, and you'll start picking up the ideas mentioned in the article. Within a few months you'll be flying and wonder how you ever coded without it.

The key is making it a natural thing, not forcing yourself to "learn Vim". At least for me, those approaches failed due to the short-term productivity decrease.

1: https://vim-adventures.com/

Whoa that's seriously fun!

This makes vimtutor look like pong.

absolutely agreed on vim-adventures. I generally play the game once a year or so out of pure enjoyment as well as a way to remind myself of all the areas where I'm getting lazy or relying too much on a plugin!

My 1 gripe with vim adventures is the whole subscription based model for a game. I went ahead and shelled out for the full thing but after 6 months I was no longer allowed access because my subscription had expired. That's some bullshit.

Don't you miss the days when you could just buy software once for a reasonable price and own it forever?

Even though my development role means I do SAAS yes, yes I do miss owning software forever.

Yeah I'm not in love with that part. But... It's still worth it.

I hate that part... but I learned vim...

My advice: don't go wild with plugins or vimrc hacks. Get sensible.vim for sensible defaults and work with that. Vanilla vim is good enough for most editing and coding needs.

My retort. Install YouCompleteMe because if you don't have high quality auto-complete your editor will feel rubbish compared to an IDE and you will end up moving.

Is autocomplete really necessary though?

YES. Oh GOD yes.

Some of the worst D'oh moments I've had came from before I added tab completion to my .vimrc, because it almost completely eliminated errors that my typos introduced.

Do you have any suggestions about how it may not be, or are you just pondering the idea? I really want there to be something that has the benefits without the Intellisense-level overhead, I haven't seen it though.

I find autocomplete annoying.

I also suspect autocomplete to be the leading cause of a particular set of subtle bugs - ones where the words on the page seem right but the function chosen has a surprising and uncatered for side affect.

When you reinforce to people that it is OK to code blindly ahead, grasping for the right calls at the last second you will end up with poorer quality code (although, it may be typed faster).

There are always tradeoffs but for me, I feel like lack of autocomplete encourages people to use shorter less descriptive names for identifiers.

I am a believer in using as descriptive identifiers as possible to make the semantics of your code as clear as possible. If this gives rise to 5-word+ identifiers, so be it, providing it is done tastefully (and not for verbosity's sake).

As typing 10+ characters per function call/variable call can get tiring, lack of autocomplete can leads incentivizes the use of shorter names which runs counter to this philosophy, and leads to code being harder to read. (IMHO)

It really depends on what you're working on. Huge code bases, weird APIs (for instance the raw Windows API), verbose languages may need an IDE to be manageable.

You can also use vim with an IDE, e.g. IntelliJ IDEA. So you get the best of both worlds. :-)

As someone who uses IntelliJ at the moment, this is an interesting thought to me. What would your workflow look like? In-IDE terminal + Vim for code editing and the rest of the IDE for refactoring, running code, etc.?

Or did you mean use Vim bindings in IntelliJ?

Using vi key bindings is the easiest way to use IntelliJ, IMO. That's how I use my PyCharm and it's amazing. You can even tell your IDE to use your .vimrc.

Vim comes with autocomplete (omnicomplete) built in. It's just bound to a rather nasty key combination, and works mostly with text on the page and values in the tags files.

This isn't always enough for folks, who fall back to YCM or others.

I am well aware that vim comes with a crude autocomplete built in. It is just not anywhere near the same class of usefulness as IDEs' autocompeltes - YCM is. Hence just bite the bullet and install YCM or you will end up moving to an IDE in the end anyway.

I wouldn't quite say this - the comforts that plugins bring can be quite useful, even if I only use them once in a blue moon - but definitely have some idea of what the bare minimum you want in a .vimrc is.

In the well over 20 years I've used vim, I've always just installed and used whatever plugins I liked.

Occasionally there were conflicts or problems caused by plugins, and then I just troubleshot those and uninstalled or disabled plugins until I found the culprit. No big deal.

Whenever I use another computer that just has vanilla vim installed, without my own .vimrc on hand, I just touch ~/.vimrc and away I go. I just try not to spend too much time on such systems before loading up my own .vimrc. Again, not a big deal.

I really don't get people who deliberately cripple themselves by using fewer plugins or features than were maximally useful.

On the other hand, I was never a big fan of giant plugins that make a lot of choices for you. I like to make my own choices as much as possible, and know why and how these choices are made. So the plugins I install tend to be very specific plugins that are good at one particular thing that I feel vanilla vim is lacking.

I like the fact that my vimrc is easy to deploy on new machines without having to hassle with plugins.

At one point in the past, I did have a bunch of plugins (nerdtree, fugitive, surround, nerdcommenter, etc, etc) but they weren't that great (I guess because vim's scripting facilities and UI isn't optimal for writing complex IDE-like features) and were always conflicting or otherwise a hassle.

These days I get by with vanilla vim with a conservative vimrc and I don't consider my productivity crippled. The only plugins I miss are surround.vim and a commenting plugin.

If you like to try any plugins, sure go ahead but I don't think it's a good idea for someone new to vim.

What do you use instead of fugitive?

git on the commandline together with tig.

While I read this thread, I actually noticed that I use only a single feature out of vim-fugitive, which is the :Gw command. So I replaced vim-fugitive by https://github.com/majewsky/devenv/blob/master/vim/plugin/mi... just now.

For someone new to vim, I agree. They should really get used to vanilla vim before moving on to using fancy plugins. But once you have a good grasp of vanilla vim, I don't think there's any good reason to avoid plugins.

When I install my own .vimrc on another computer, I just copy my whole ~/.vim directory over with it, and that's really all it takes to migrate. Easy.

As for plugin conflicts, I've found them to be pretty rare, and when they happen they've been easy enough to troubleshoot and then I just disable the incompatible plugin, if I can't find some other fix. The occasional incompatible plugin is no reason to avoid plugins as a whole.

> The only plugins I miss are surround.vim and a commenting plugin.

Incidentally, surround.vim and commentary.vim are also why I wouldn't want to live without plugins. Everything else is expendable.

Any idea why a surround feature isn't in vanilla Vim? It seems to follow the Vim philosophy, i.e. enacted with a command that has action and movement components.

This is great advice for beginners, but as you get more advanced and comfortable with vim, it's OK to let your custom configuration grow organically. Once you've mastered vim you'll be fine on non-customized version running on a server.

For coding, I would really suggest using the NERDtree plugin [1] (after getting a basic hang of vim modes)

[1] http://www.vim.org/scripts/script.php?script_id=1658

I had it at one point and it was decent (but not great), but I no longer use it.

I always prefer using tags files to do code navigation instead of browsing files. With `:set wildmenu` (enabled in sensible.vim), using `:tabnew :edit :split` etc from command mode is also quite nice. For browsing, the default netrw is decent or I use ranger in another window.

What I could really use is a fuzzy finding plugin, I've heard Ctrl-P is nice but I haven't tried it.

Agree with this. I regularly have to jump onto other colleagues' machines and edit code. So I try to stay as close to vanilla key bindings as possible.

I've always added a line to my .vimrc file that would source the vimrc_example file included in the vim distribution. I have maybe 5 more lines in there with some additional settings (colorscheme, ls=2, etc).

If vim doesn't click for you, I'd really suggest trying kakoune. It swaps vim's behaviour around - where vim commands are "verb-object", kakoune's default behaviour is to allow you to select things, and perform an action on them once you know what you're operating on. Movement is precisely equivalent to selection - w is "select the next word", W is "expand the selection across the next word".

The visual feedback makes it easier to pick up (for me), and also makes building up complicated sequences of actions very easy. Multi-selection ties into that as well - a common workflow for me when editing is to select an object (a-a or a-i), split it by some regex into multiple selections (s), then perform my changes on those selections.

I've had a really easy and enjoyable transition from vim to kakoune in the last month or so. The only thing I'm bothered by is the lack of text wrapping.[1]

I've also started playing with VSCode and have found it great as well. It's the first time in a number of years I've played with anything other than vim.

[1] https://github.com/mawww/kakoune/issues/484

This sounds like visual mode.

I saw Kakoune last week on HN and think about giving it a shot. Can you comment on how extensible it is? Are there extensions available, and can I write my own?

I've not played much with extending it past writing a couple of hooks. It has a decent enough hook system. What would you like to try and replicate in it?

At work nobody understands why I use Vim, I'm tired of having to explain myself to my coworkers and hearing all the time "Why don't you just switch to Atom?"

I have trouble understanding Vim as well. It seems to be good at code editing, where I find that I'm not bottlenecked there. I'm bottlenecked at my ability to plan and think about programs.

Once I have either a plan or comprehension of a program, I move at lightspeed, and typing becomes a small proportion of software production time. When editing an unknown codebase, it becomes even more imperative to have comprehension + plan before making an edit.

Also, since its my ability to comprehend and plan that is so strained, I'm not sympathetic to Vim's lack of anything like intellisense, or cross-file grammar and type awareness + autocomplete.

Exactly why I use vim bindings in Intellj.

Typing may be a small part, but there's no reason not to make that part efficient.

I like this quote:

> Vim is a small language for editing text that ships with a small user interface.

Pardon my ignorance, but are the two separable? Could someone write a GUI interface that uses the vim text editing language underneath? I know of gvim, but this seems to be just vim with a menu bar.

There are plenty of Vim emulator plugins for "GUI editors" like Atom (or even the Visual Studio family, as a comment in this thread mentions) that do just that!

Sadly, most do it poorly. There's a lot more to Vim than 'hjklia'.

Yes, I've used them in emacs, atom, etc. They're useful, but often feel unnatural. I was looking for something that was built from the ground up specifically as "vim editing with a nice interface" -- maybe this is neovim, as someone else suggested.

Nope, VIM the UX (keys and movement) and VIM the application are not separated at the moment.

It would be great to be able to use VIM key movement as drop-in replacement for any text field OS wide but the VIM interface (the command line) plays an important role in the UI and I don't see how it could be swept aside without losing some VIM core functionality: EG how do you :%s///gi without the overlay command line ?

I actually have a design document from 5 years ago lying around in my backup that outlines a desktop shell based on (and expanding on) vim's UX. I should get back to that project one day.

I think you're looking for neovim.

NeoVim is really a fork though, not a separate implementation.

Yeah, but someone could "write a GUI interface that uses the vim text editing language underneath" using neovim. It's one of its main selling points.

https://github.com/neovim/neovim/wiki/Plugin-UI-architecture

Shortcut Foo's vim dojos are also a good way to learn all the shortcuts in vim once you have got the basics down (opening and closing files, insert mode etc)

Each dojo trains you on a few related set of vim actions.

Practice one dojo at a time and try to use it during your regular editing. Once you have incorporated it into your existing workflow, move to the next dojo.

https://www.shortcutfoo.com/app/dojos/vim

I'm looking forward to teaching a Vim class in Seattle next month. https://www.casitconf.org/casitconf17/tutorials/

I've got some resources for learning Vim on http://www.verticalsysadmin.com/vi.htm

For an easy start, use a sane defaults plugin like sensible.vim [1] or vim-simple-defaults [2] (more opiniated).

Also, use vim-plug [3] with few plugin like ctrlp, nerdtree, nerdcommenter and vim-simple-complete [4].)

[1] https://github.com/tpope/vim-sensible

[2] https://github.com/maxboisvert/vim-simple-defaults

[3] https://github.com/junegunn/vim-plug

[4] https://github.com/maxboisvert/vim-simple-complete

I am the author of [2] and [4].

For someone mostly playing with Python, and using Atom, what is the great step forward that editors like Vim and Emacs offer?

I read things like this occasionally and still don't really get why? Why is the learning curve worth it?

speed and efficiency.

some people don't care about those things, some people do.

Exactly the kind of thing I have read. But nothing explaining how it achieves that

So it has keyboard shortcuts, and I guess I could add those to another editor...

Is it one of those things you just have to take someones word for it, have a go with it and see?

You can get vim-shortcuts for other editors. I really like using those in Intellij for example.

One thing I have noticed however is, that once you are good at the vim keyboard shortcut "language" (as someone described it above), you tend to use other features in the editor a lot less. And if you don't use the features, you might as well just use vim neat.

in your editor, without leaving the keyboard, how would you search-and-replace using a 2-variable regex, only between lines 275 and 1305, and then turn every instance of 'TEST_' into a lowercase, but only on the lines that didn't match?

How often do you find yourself doing operations like this? I feel like it would take me more time to formulate and confirm that your set of commands are correct than it would for me to just ctrl+f to each instance and then ctrl-v the ones that needed to be changed. Don't get me wrong, I think it is really cool that you can do this, but it feels like this requires a level of fu that is beyond most typical programmers.

you search and replace by hand?

... are you serious?

Thanks for the substantive reply;)

In almost all cases where I need to do a find/replace there are typically no more than 4-5 references that need to be updated. And I think a better way to phrase my behavior is I search, inspect the code to make sure that my change won't introduce a bug or some unintended consequence, and then replace. This may be slower, but in the grand scheme of things it barely registers on my overall productivity and if it saves even one bug from getting introduced into the code than the extra time spent probably pays for itself. If I need to update more than just a handful of references, than Sublime has a perfectly functional find/replace tool, but I have only ever really needed it maybe 3-4 times in the last few years.

To get back to the question at hand. How long does it take you to formulate these series of commands in your example? Because to me it feels like it would take longer to come up with a correct set of commands for your example than it would be to just search and replace 'by hand'. Of course if you are updating 100's of references than spending some extra time to formulate your solution makes sense, but in your example, you limited your search ~1000 loc, so presumably you are only updating a few lines, maybe a dozen at most? I understand that vim is powerful tool, but it seems to solve problems that I don't have (or that I don't consider to be problems), and I am genuinely curious as to the sort of problems and types of code bases that vim aficionados work on.

I would do this in awk. I could specify the line numbers. Or I could use the editor option to pass selection through said awk script. Or I could pipe xclip to and from the script.

Someone else could do it with sed, but I prefer awk.

In vim, it would probably have to be done in two separate commands

    # Search and replace using a 2-variable regex
    :275,1305s/two_variable_regex/first\1second\2/g

    # Replace TEST_ with test_
    :275,1305g!/a_regex/s/TEST_/test_/g

But, if it's too convoluted to do something like this in vim, you can instead do something like:

    :275,1305 !perl -ne '# substitution, then print'

It's more than keyboard shortcuts, vim has different sets of commands that can be composed to take different actions. Say, typing di" [d]eletes what's [i]nside a pair of ["] characters. Also vim is more powerful if used as a Unix tool instead of per se, it's more of a citizen of that ecosystem.

There are different paradigms in development environments, Unix+a text editor is one. There are also those like Emacs, Acme, and usual IDEs. One has to choose which is better for their use. Say if you're a Mac or iOS dev maybe XCode is better for you, but if you're writing C, Perl, Python, etc., Unix & Vi is a nice environment. If you're doing Lisp, Emacs is the best environment out there (though Emacs and Vim are extensible, so they have some tooling for all the languages out there).

It's not just that it has shortcuts, per se, but that these shortcuts are sort of "fundamental units", which combine in interesting and intuitive ways, often resulting in efficient text editing.

The latter is rather subjective. I love vim for small projects, which, being a grad student, is most of what I write. However, I prefer IDE's for large projects with multiple files and hierarchies.

It's not the shortcuts, it's how they work. The thing about vi shortcuts is that they form a composable "language" of sorts, so instead of having to memorize a set of shortcuts for doing specific things, you memorize motions and actions and the rules to compose these.

For example, in another editor you might have ctrl-K to delete a line (dd in vim) , but what about deleting 4 lines? in vim, it's 4dd.

Or you might want to delete from the start of a block to the end... The motion for block in vim is %, so to delete a block, you'd do "d%". Similarly, deletion to the end of the line is d$

In visual block mode (ctrl-v) you can select a bunch of text and apply an action (eg. a simple replace, which would be :s/foo/bar) on only that text.

Even if you just learn a bit at the surface, the free composability of motions with actions makes even classic vi (which doesn't even support arrow keys for moving around) extremely comfortable to use, and most of the time you don't need to twist your hands into uncomfortable chords involving multiple modifier keys.

"Another editor" presumably means Emacs, but isn't Vi vs Emacs dead? In 2017, the argument is really Vi-or-Emacs vs other editors.

In Emacs, deleting four lines is Alt-4 Ctrl-K, usually written M-4 C-K.

One way to delete a whole block (meaning a paragraph?) is M-h Backspace. Deletion to the end of the link is C-K.

Selecting a region is done with C-Space, running a simple replace is then M-% foo bar !

I'm not an expert with Emacs. The most useful function I use is the macros, which saves me learning many other functions. F3 starts macro recording, F4 ends it, then F4 again runs the macro. It's easy to script changes and run them in this way.

Ctrl-K is just what came to mind. I think it works in both nano and emacs, and the mnemonic is "kill"

Emacs is without a doubt superior technology when compared to vim. There are perfectly usable vi clones that run on Emacs, after all. The main benefit vi has over emacs is that it's everywhere (except windows :() in some form, so even on a completely unfamiliar machine away from your highly developed dotfiles, your muscle memory still works to an extent.

The main reason I don't use an Emacs implementation of vi is that muscle memory is really bothersome to retrain, and the differences are enough to disrupt my workflow rather badly when using eg. Spacemacs. I just haven't found the benefits to be significant enough to outweigh the inconvenience of retraining myself.

For me, all this talk about "speed and efficiency" has put me off of trying vim for a good while—I thought it was a waste to spend time and effort improving the speed of something that was never a bottleneck to start with.

However I did give vim a try eventually and use it now exclusively, but the reason I like it is comfort. Navigating around and doing operations is sooo much more comfortable now that I don't have to use a mouse or repeated key presses, plus all the many helpful shortcuts it has.

Well, for one, it seems more natural to open vim in the terminal than opening Atom

Then, Vim automation (like doing a search/replace) seems more straightforward

It's also useful when vim is all you have (remote systems or if your X server became borked)

But Atom is fine and you shouldn't worry about it

The comment below from MichaelGG sums it up perfectly for me:

> Easiest way to think of it is to think of how frustrating it is watching someone do everything with a mouse, not knowing any shortcuts. Clicking File -> Exit instead of the window's X. Or deleting a whole line of text just to change one word. Not knowing Ctrl-X/C/V.

Vim(and I guess emacs) are another layer on top of that.

I am a lazy person. I don't want to bother moving my hands away from my keyboard. I just want to spend my time thinking. Thus, vim is a natural choice. I'm also a big terminal fan. I have my vim and my tmux. They both fit extremely well, and I live in there. That said, at the end of the day, vim is just another editor. In my opinion, the best out there, but it's no more than that. If you are comfortable with atom, keep using it. If you are curious about vim, install a plugin that emulates the basic vim movement keys. You are not gonna be less of a programmer for not using it. That said, I think everyone would gain a lot by just using a basic vim emulator on top of whichever editor they use. You don't have to give up your current tools.

Vim, at its core, is a language for manipulating text. When you "think" in Vim, you are writing small one-off (or stored, in the case of macros) programs to do something to a text file. Once you become familiar with the basic building blocks, you can construct complex text manipulation commands on the fly. I've found that while programming I often spend more time reading or thinking than writing, but when I _am_ writing, I usually bump against an input bottleneck as I generally have a good idea of the changes I want to make. Vim speeds up that step.

My take on it, use what is easiest for you. Especially in your situation where it sounds like you are more of a recreational/casual programmer. Free time is a precious commodity and in your case it is probably better spent getting more familiar with python. If/when programming becomes your full time career (or passion), then it might make sense to start playing around with vim. But for what it's worth, I program for a living and I use Sublime. It works for me, and I spend an order of magnitude more time on other tasks (reasoning about code, working on infrastructure, code review, design meetings) than I do 'struggling with my text editor'. Until you really feel like your editor is holding you back, you are probably fine sticking with Atom.

I think you may be right, I write some code as part of my job, but it is not my main job. I fell on Atom purely because I was trying Atom out at the time when I happened to get into a larger than normal project. Otherwise I would probably have stuck with Sublime (from which it obviously takes some inspiration).

I have had to do a little with Visual Studio in the past, and I feel like you spend more time learning the IDE than you do learning to code. I think I will stick with Atom and leave Vim, Emacs et al to the full timers!

First of all it's far easier to learn than most people make it out to be. As for why I decided to learn vim: I grew tired of having to switch IDEs depending on the language I use and most importantly memorizing their different sets of keybindings. Now I only have to learn vim's keybindings.

I think one of the most under-mentioned features of vim is that a line is one of its fundamental units.

Suppose you want to move a few lines of code from one function to another in a regular GUI text editor. If you select these lines with a mouse you need to be careful about exactly where you click to start highlighting and where you end highlighting. Do you start from the beginning of the first line or from the end of the previous line? Do you include the new line at the end? (Can you even?) Then, when you paste, where do you paste? Do you just put the cursor on the line you want to paste before and paste? Or do you put the cursor at the end of the line you want to paste after, hit enter and then paste? Oops, you did it wrong and now this the first line isn't indented at all, or now you have two lines of code on one line.

After a while you figure out where you need start and end the selection, and where you need to paste, but it's still easy to mess up.

This isn't an issue in vim. Using Visual Line mode selecting and pasting is super simple. 'V' to enter visual line mode, 'j' and 'k' to highlight everything you want (and 'o' to switch which end of block you're moving!), 'y' to yank (copy) or 'd' to delete. Then put the cursor _anywhere on the line_ that you want to paste after and hit 'p'.

The ease of use is one thing, but I also think it makes more sense to have an entire line be a fundamental unit. When you're editing code, you're usually moving codes around or editing single lines. I rarely copy and paste just one part of a line to another, and I think in most cases it's easier to just paste the line and change the parts I don't want.

Thank you for writing this great summary. Just last week I was was trying to compile such a list as a 'novice' user and this has everything I had bookmarked and much more.

My focus was on portability, I switch systems alot, I don't know how practical carrying all these plugins around is but have not given vundle a try yet.

I have to say that working with VIM feels like a weekly/monthly epiphany's. I will discover something new that can be incorporated into my workflow and can't believe what I'd been missing all along.

Modal keybindings seem to be the most efficient way to work in an editor.

Xah Lee created one for emacs. Has anyone given it a try?

http://ergoemacs.org/misc/ergoemacs_vi_mode.html

https://github.com/xahlee/xah-fly-keys

Isn't evil-mode more well-known?

Sure, that's vi bindings. The author analyzed his layout and claims this is more efficient.

If you're in the Visual Studio ecosystem, I enthusiasically recommend ViEmu. It let's you learn the vi keystrokes a little bit at a time, all the while being able to fall back to the VS keys when you don't know how to do something the vim way. It really flattens out the learning curve tremendously.

I started to used VIM seriously last month. My biggest concern so far is editing new files. Too much switching between INSERT and NORMAL modes.

This is not a problem when editing existing files.

Also I think some keyboard shortcuts are not comfortable on an AZERTY keyboard layout.

> Also I think some keyboard shortcuts are not comfortable on an AZERTY keyboard layout.

Agreed. That's why I switched to the US international layout. Took me only one week to train my fingers. And it's not that hard when I have to use someone else's computer (somehow I didn't forget the azerty layout :D).

Have you remapped Caps lock to Escape yet?

I just use ctrl-[ to go back to normal mode. I actually do use the CAPS LOCK key for typing in all caps on occasion, so I would rather not remap it.

One trick is to postpone the correction of a typo for instance until you're done with your current editing. And there's also plenty of ways to switch between modes: i,I, o, O, a, A, and ^o and ^d (insert mode) which are occasionally handy.

Also people often duplicate Esc to the "jk" combination. I personally use ^L instead, but for no particular reason.

On AZERTY keyboards, the nastiest shortcut for me is ^[ ("jump to tag", which is ctrl-AltGr-5). I simply remapped it to F2. A second one is ` (backtick, altGr-7), which I remapped to ' (tick). I did not move tick somewhere else, it wasn't useful enough to me to bother doing it.

See :map and :noremap for how to do these things.

Vim itself comes with a user manual, besides the command reference. :h user-manual

Another site with good general advice is https://www.vi-improved.org/

Reply on news.ycombinator.com