Best of Vim Tips

same here, also ido+helm+projectile; and not that ctrlP feeling yet.

i think this will be solved though (or is fixable), Vim on the other side does not seem very fixable to me.

I use Evil with emacs prelude now. Has more than enough features I need.

I don't know if it's by default but Vim also saves search / command history across sessions. So if you quit or accidentally kill the terminal and open Vim again, that history will still be there.

Well I want to wait until I have a chunk of focused time to dedicate to the project rather than pestering them without cause.

might want to switch to relative line numbers. makes using 12j/k much easier in my experience.

In your vimrc add the following (version 7.3+):

    set number
    set relativenumber

This turns your line numbers into a hybrid mode that show the numbers relative to your cursor and the actual line number your cursor is currently on.

Generally in vim, if you're pressing a key over and over, that's a smell that there's room for improvement there.

In addition to counting motions, other great options for getting around include:

    % jump to the matching brace/bracket/paren
    ( jump back a "sentence"
    ) jump forward a "sentence"
    { jump back a "paragraph"
    } jump forward a "paragraph"

Also, getting around by searching can be hugely worthwhile.

I believe there is an option to display relative line numbers to your cursor position. Really helps with jumping X number of lines.

> Do you count the number of lines or characters before you move?

I think most people use commands like f) (move to to the next ')' on the current line) more often than something like 12k (move twelve chars to the right), because, like you say, counting chars is slower than mashing 'k'.

People just use 12k because it's a simple example of how vim commands can be chained together. As a less-contrived example, you can do 2f) to move to the second ')' on the current line.

% will bounce back/forth over matched pairs of (), [], {}. :/foo/z6 will move 6 lines after the line that matches "foo" (I know it's not eliminating counting). There are also word, sentence, and paragraph movement available.

I "bookmark" important lines with named markers "ma", "mb", etc for "a" and "b" markers respectively, available as 'a, 'b.

Not to mention cscope or ctags for finding function declarations, various call chains, etc., etc.

There are quite a few ways to get around.

I use relative line numbers so I don't have to count, vim tells me how many lines are between my current cursor position and wherever I need to jump to.

It's more about "semantic editing" than memorizing arcane keybinds. With Vim, you describe what you want to do with actions and motions. Motions move the cursor from a starting point to an end point and then actions do something with everything between the start and the end.

For example, if you want to delete 3 words, there is an action to delete (d) and a motion to move forward one word (w): 3dw (read (3) times, (d)elete (w)ord)

If you want to delete everything up to a closing bracket, there's a motion to move to the next occurrence of a character (t): dt) (read (d)elete (t)o ')')

It becomes much more productive when you're thinking in terms of composing actions and motions to achieve a goal rather than memorizing situational key combos. The hardest part is getting over the hump of memorising the actions and motions.

Relative line numbers aren't even too important, given that there is a motion to jump to a line number. If you have a function that you can see starts at line 6 and ends at line 14 and I want to move it to the top of the file. You want to go to line 6 (6G), delete (d), go to line 14 (14G - thus applying the delete action to the motion of moving from line 6 to line 14) then go to line 1 (1G) and paste (P).

Personally I just estimate and correct. Usually I use numbers that are easy to type with the left hand so I can keep my right on the home row. If the place I'm moving to is 17 lines up, I'll likely get there with 15jjj. Even with relative line numbers turned on, that feels faster for me than stopping to look at the number. (Haven't timed it, but feeling fast keeps me in flow so that's my metric.)

Various semantic movements help a lot, too. But I never stress on hitting the target exactly, I'd rather get nearby without thinking than stop and think to get there in one command.

Of course I'm exaggerating, and I agree this page isn't particularly friendly but nor is it intended to be, its a reference to be searched rather than a piece of prose to be read.

A lot of pages I find frustrating are often trying to spin a narrative around what amounts to reference material, or vice-versa & results are often framed with the tropes I mentioned above.

As opposed to the modern trend where there is too much non-information to digest.

What's nmh?

I must admit to setting $EDITOR to nano for mutt.

Does Reddit not have [spoiler] tags?

I agree.

As far as a business case goes, there's no real "vendor lock in" with a plaintext editor like this. You can always switch to something else and your files will be fine/the same. You're investing (potentially non trivial) time to learn using it, but it didn't take me long to learn ST2 to a depth that made it really handy.

I will say I'd buy a lot more into that argument for people who develop plugins.

That said I can respect the "open source" only mindset. I'm just not sure I'm that concerned about it in this particular case.

I also care about being able to use the tool several years from now or on different distributions/OSes, etc. With closed source you are locked to whatever the vendor provides, you can't just recompile it if it doesn't work on your OS anymore. Also I don't have the time to reverse engineer and check the software for backdoors (not that I do that with the open-source one either, but at least its more obvious if something goes wrong there).

If you work on closed-source software then you probably don't care about this / doesn't matter there, but as someone who spends most of his time working on open-source software I definitely want my editor to be open-source.

That's the same logic that got us OS X Mac using developers for Linux :(

I think you could also ask the question in a different way. What is the market for closed-source text editors? We have open-source text editors, and freeware(?) closed-source ones. So who would buy a closed-source text editor? (Talking about a text editor here, not an IDE)

So then why not just open-source it? Seems to me there are only drawbacks in keeping it closed.

Yes, I know the article and wholeheartedly agree with it.

In addition to composability, which I agree is a big idea, I believe there's another big idea in Vim: modal editing.

On paper this works perfectly, in reality it doesn't.

A lot like Regexes. The first n attempts at a regex always fail, and fail for human reasons - I didn't spot that the pattern I'm matching on actually appears earlier in the writing, the pattern has a typo but I spelled it correctly, the pattern used a unicode character that looked like an apostrophe, etc.

And Vim composability suffers in exactly the same way. "Delete back eight words" works on paper, but eight words isn't a thing you can glance at, it means stopping and counting - especially not if it goes back over a linewrap. And does what about the word boundaries? If the cursor is in the word, at the end, at the start but still has to cross the word boundary to get to the previous word?

Combined with that, the way Vim commands have instant and unbounded effects means that the wrong command or a misspress of a key, and suddenly there's a huge change to the text and you don't know what happened. This leads to the effect where even if a change looks right, if it was a big change ("add a comma to every line just before the last word") needs a lot of careful verification to make sure it worked as intended.

In real world use, almost everything I try to do in Vim outside the everyday patterns of habit, takes enormously longer, works less well, is more fiddly and stressful, than 'just' doing it by hand or in Python.

Agreed. I'm honestly not sure how it could be made easier.

It's mostly to do with the various plugins that I use. I can pretty quickly get to syntax highlighting and editing with vim (read: instantly), but the other tools that I like integrating into my editing are where I hit a wall every time. Even with that I could sync everything via git or dropbox or whatever else that I wanted to do. It's just the fact that I have to dig through my mental notes to get it working. I also don't specifically have a VIM haskell environment to clone. (I don't have a sublime haskell environment to clone, either)

I'm not that it's necessarily excessively complicated; it's just not particularly straight forward, either. This could just be a failing on my part, but I haven't set up a vim environment in about a year, and there were enough confusing parts to do a little head scratching to get haskell plugins working to make me grab something else for now. With ST2, it's been about the same amount of time since I've set it up and only took around ten minutes to finish (that's with plugins to integrate HLint, compilation, a repl, type checking, etc).

Again, keep in mind that I said this was a very narrow use-case/situation. I'm not arguing that VIM is more difficult to set up for any case outside of the exact one I said. I'm not saying it is or isn't a generalizable point. I'd really have to do more digging to find out. What I am saying is that in this situation ST2 was easier to setup.

I'm also not arguing against VIM because of setup time/difficulties. Setting up a coding environment should be a relatively small chunk of the total time you spend using it to code. I'm just noting a relevant experience I had last night.

There are certain features where this would be problematic. Things such as copy/paste to/from the OS clipboard, and a few extensions that require ruby support (since ruby isn't always available).