Live data from Hacker News

Ask HN: Is Vim still worth learning?

news.ycombinator.com

71–80 of 93 posts

Re: Ask HN: Is Vim still worth learning?

#71
post #44
post #36

Earlier quoted context omitted.

> things like S to replace the line what is this barbaric default binding, s/S shall be bound to the indispensable vim-surround! ;) built in text objects are already nice combined with modifiers (e.g cw, ciw, caw, cW, ciW, caW), ramping it up a little bit with argument (ca, cia, daa), surround (cs"', cs([, ci", ca", viWS , dst), and indent (vii>) is stupidly powerful. Once the [verb][modifier]{object} pattern clicked…

Most people I know (including many linux users) regard me as a vim pro relative to them, and I still have barely an idea what most of these do. Or what surround is. Might want to explain a little for the rest of us mortals ;)

Sure. Here's a quick rundown of how it works (in my mind at least, might not be 100% technically exact):

Vim normal mode commands have something like this structure, a bit like a sentence:

    [verb][modifier]{object}
There can be a bit of implicit in this sentence, e.g [verb] and [modifier] are optional. {object} is mandatory, final, and "commits" the normal mode command without having to press something such as Return.

Let's look at some basic movements:

    w => word (== [A-Za-z0-9_]), forward lookup
    W => Word (== \S i.e not whitespace), forward lookup
    b => word, backward lookup
    B => Word, backward lookup
Without [verb] it's like the implicit [verb] of the sentence is "move", so typing just these indeed results in pure movement:

    w => move (from cursor position to) one word forward
    W => move (from cursor position to) one Word forward
    b => move (from cursor position to) one word backward
    B => move (from cursor position to) one Word backward
With a count modifier

    2w => move (from cursor position to) two words forward
    2W => move (from cursor position to) two Words forward
    2b => move (from cursor position to) two words backward
    2B => move (from cursor position to) two Words backward
With [verb], things are applied to the object. Let's look at some verbs:

    d => delete
    c => change (== "delete + enter insert mode", exit with ESC)
A repeated verb is a shortcut to mean "whole line"

    dd => delete line
    cc => replace line
    d2d => delete two lines
Back to the sentence. It's a bit like the movement implicitly defines a "text range" object: "from current cursor position to movement target". So:

    dw => delete (from cursor position to) one word forward
    dW => delete (from cursor position to) one Word forward
    db => delete (from cursor position to) word backward
    dB => delete (from cursor position to) one Word backward
The interesting part about c instead of doing d+i is that it is going to be "atomic" (end these with ESC to exit insert mode):

    cwfoo => replace (from cursor position to) one word forward with "foo"
    cWfoo => replace (from cursor position to) one Word forward with "foo"
    cbfoo => replace (from cursor position to) word backward with "foo"
    cBfoo => replace (from cursor position to) one Word backward with "foo"
Which is really cool because now you can move to another position and press . (dot) and it will repeat the last normal mode command, dynamically/semantically, like a mini macro. Combine that with search, and incremental search/apply is n to go to the next occurence and . to apply, or n again when I want to skip. Also, u for undo goes back from atomic change to atomic change.

Similar to wWbB there's "find" and "find until" (n is an optional count, defaults to 1):

    [n]f{char} => find nth occurence of character, forward lookup, after character
    [n]F{char} => find nth occurence of character, backward lookup, after character
    [n]t{char} => find nth occurence of character, forward lookup, before character
    [n]T{char} => find nth occurence of character, backward lookup, before character
So e.g some examples, combining two sentences:

    F,dt) => move back to previous comma, then delete (from cursor position to) until next parens
    t)dF, => move to last parens, then delete (from cursor position to) up to previous comma
These are useful to e.g delete arguments! e.g with the cursor somewhere inside parens here:

    foo(42, 123, 345)
Note that depending on what the initial cursor position is within parentheses the result will differ. Also note that this is good for simple arguments, we'll address more complex ones later.

Words can receive a "inside" or "around" modifier:

    iw => one word, up to word boundaries
    iW => one Word, up to Word boundaries
    aw => one word, up to word boundaries, plus trailing whitespace
    aW => one word, up to word boundaries, plus trailing whitespace
What's cool about this is: you don't have to position at word beginning, and it can handle whitespace as you see fit.

So given this text:

    foo bar baz
Doing diw with the cursor inside bar would delete "bar" but leave you with two spaces while doing daw would delete "bar " thus leaving you with only one.

Now, i and a modifiers don't just take words:

    i" => inside double quotes, excluding quotes
    i' => inside single quotes, excluding quotes
    a" => inside quotes, including quotes + trailing whitespace
They're also smart about delimiters (also works with a but by now you should get the idea):

    i inside a  pair
    i{ => inside a { } pair
    i[ => inside a [ ] pair
    i( => inside a ( ) pair
    a including  pair
Guess what these do:

    ci
These are all built-in, let's go further with tpope's vim-surround:

    s" => surrounding quotes
    s surrounding  pair
    s[ => surrounding [] pair
Which you can use this way:

    ds" => delete surrounding quotes
    cs"' => change double quotes to single quotes
    cs(( => change closest parens around to parens with one space inside
    cs() => change closest parens around to parens without space inside
    cs2() => change 2nd level outwards parens to parens without space inside
    dst => delete surrounding tag
    cst => change surrounding tag to be "" (closed by "")
None of these affect the enclosed text, only the surrounding items.

Visual mode is entered by pressing v (or V for visual line mode, or ^v for visual block mode) then moving around, and the object will be the highlighted area. Since {object} is what ends the vim normal mode sentence things are a bit different in visual mode:

   viWS( => surround Word with parens + inner space
   viWS => surround Word with  and 
Usage of visual mode and visual line mode is greatly improved with % (move to matching delimiter), especially with vim-endwise (which makes % work on more per-filetype things such as tags in HTML, and def/end in Ruby)

Other nice plugins are argtextobj:

   dia => delete argument but not comma, properly handling parens and commas as argument delimiters as well as nesting
   daa => delete argument + one comma (leading comma, unless first arg then trailing comma) + surrounding whitespace
and vim-indent-object (cool in general, but stellar on yaml or python):

   cii => replace indented block, leaving out surrounding lines
   cai => replace indented block + surrounding lines + one line above
   caI => replace indented block + surrounding lines + one line above + one line below
   vii> => visual line select indented block, then increase indent
   vii visual line select indented block, then increase indent
   viigc => visual line select indented block, then comment (using vim-commentary)
   vii:norm i# => visual line select indented block, then prepend line with # (pure vim)
   via= => fix indentation
   viagq => hard wrap lines
I often do the "comment" one using visual block mode (^v) and moving around with % then do I# (insert # at line beginning) when I can rely on delimiters. Same for indent increase/decrease and fix, only with visual line mode.

Wrapping one's head around this vim interactive "sentence" dialect of normal mode is not that hard but usually badly explained (I hope I did a slightly less bad job at that!), but it's key to unlock some of vim's insanely composable superpowers.

The nice thing is that by understanding how these work together, I can replicate the behaviour of these plugins in a plugin-less vim (at a cost of a bit more thinking+typing), so I save time when I have the plugins but gracefully degrade to something still more efficient than painstakingly moving my cursor around and deleting/changing every text character by hand.

Next step: macros!

  qa => start recording macro in register "a" (can be about any other key)
  q => end macro recording
  @a => play macro in register "a"
  @@ => play last macro again (such a timesaver)
And a little bonus:

  "ap => paste macro from register "a" (which you can then edit!)
  "ayy => yank line back in register "a"
All of this combined is ridiculously powerful, to the point I can barely hold nervous laughter at some hilariously complex refactoring I did.

A few links:

https://github.com/tpope/vim-surround

https://github.com/vim-scripts/argtextobj.vim

https://github.com/michaeljsmith/vim-indent-object

https://github.com/tpope/vim-commentary

Re: Ask HN: Is Vim still worth learning?

#73

Yes definitely. Vim will be around for the rest of your career, long after VSCode or other IDE's have come and gone. Investing in tools and workflows that are properly open source, and have serious longevity has a big payoff.

That holds on paper but I'm not sure I agree.

I've used Notepad++, Sublime Text, Atom, and Visual Studio Code. Each of these has introduced game changing improvements (ST has popularized the command palette, Atom allowed high quality, well integrated, and easy to write extensions, VSCode improved upon Atom with way better performance, brought LSP, and drastically improved the remote dev experience). They have in common that switching from one to the other is extremely easy. When VSCode dies, it's because something better has emerged, I'll just have to install the VSCode keybindings on this new editor and I'll be good to go. Because this new editor will adopt the common conventions that everyone use, unlike Vim.

I've used Vim for a year, became pretty efficient with it, but it always feels like it's playing catch-up with other editors. And the modal editing feels more like a gimmick than something really improving productivity. I sometimes open Vim to do some data cleanup, because Vim moves make it easier than writing a script. But when writing code I never think "damn, typing 3dd would be so much faster than selecting 3 lines and hitting delete"

Re: Ask HN: Is Vim still worth learning?

#75
Vim is way more customizable and portable than any gui editor imo. An extreme amount of filetype support is builtin to the vim runtime, try to peek how many definitions there are in the src/runtime path on github.

I think its well worth it. Even for the macros, normal commands there is no more efficient way to edit text.

If all touch keyboards had vim-mode we'd all be more productive on smartphones. People who use vim over ssh on mobile devices knows this. I've remapped the record macro (q) to (qq) on mobile devices and put my normal-mode leader key on q, it works really well.

Re: Ask HN: Is Vim still worth learning?

#76
No I don't recommend -- and I am a daily vim user for years. I program mostly in C, sometimes C++. I use i3 on my desktop and tmux when remote/ssh'd into a vm. Inside vim, I use the bare minimum of plugins to reduce dependencies/complexity. I use ctags for getting around, as well as the built in features. gdb in a terminal window next to my vim window source. It's fine and snappy and does everything I need.

I live in a terminal except for the browser. Of course my xterm bindings are always vi-mode and tmux too. I have key bindings to unite all my i3/tmux/vim 'getting-around' keys and also fought that fight to unite the clipboards, even across VMs etc.

Getting back to why I say 'no' is because once you're used to the modal, and getting around with the usual vim motion keys, it makes using anything else near impossible and clumsy. I have great difficulty composing text in browser (like right now) and also emails, etc. And if any editor online allows vim keybindings, you must make sure that you are used to defaults otherwise the vim-mode won't do you much good. Like escaping with CTRL-[, or delete word with CTRL-W, which closes the tab in the browser (firefox and chrome and I never found a way to turn that off, so I lose a lot of work that way). For instance godbolt and leetcode both had vi-modes but there's enough of a difference, even though I try to use nearly all defaults, that I still end up composing any code/english in another terminal window.

I am completely hopeless using a mouse or arrow keys. If I have to go to on-site interview and have to use something other than vim, well it makes me look like I haven't sat down at a computer in 15 years. I am a hostage now to my habits and am very wary of hopping over to VSCode/CLion/jetbrains whatever else because I will be a fish out of water.

Re: Ask HN: Is Vim still worth learning?

#77
You don't need to master vim as some other commenters seem to think. I've been using vim for 10+ years, but have relatively little of the manual committed to memory. You can learn enough to be productive in a day. The muscle memory comes quickly especially if you align your other tools with it. For example I run my shell's line editor in vi mode, have my window manager configured for keyboard-driven operation with a vi-like navigation scheme, `:set -g mode-keys vi` in tmux, and use one of the vimperator clones in my browser. So I never go very long without using the same patterns.

Re: Ask HN: Is Vim still worth learning?

#78

No I don't recommend -- and I am a daily vim user for years. I program mostly in C, sometimes C++. I use i3 on my desktop and tmux when remote/ssh'd into a vm. Inside vim, I use the bare minimum of plugins to reduce dependencies/complexity. I use ctags for getting around, as well as the built in features. gdb in a terminal window next to my vim window source. It's fine and snappy and does everything I need. I live in…

Oh please it isn't that hard. Mildly annoying maybe but you can't possibly be that "handicapped" by it. If you're using all that crap and "fought the clipboard unification battle" then you're a bigger geek than 95% of programmers and never had to ask the question "should I learn vim?"

I don't feel the need to use vim exclusively. I like IDEs too, but will probably continue using vim in some capacity so long as it's useful.

Re: Ask HN: Is Vim still worth learning?

#80
I wouldn’t bother. I’ve been using it for 25 years, but only because it’s available everywhere. I would never use it as a code editor. For me it’s a skill to be able to edit files in any unix environment and I leave it at that.
Post reply on HN