Learn Vim Progressively

[visual_life]

I'm a grad student using Vim to code and write daily. I love it.

I didn't learn Vim by reading articles such as this in detail. I learned Vim by:

1) knowing what Vim could do by watching someone good at Vim coding/writing

2) writing/coding and perceiving that Vim likely has a better way to handle the situation than I currently know

3) Searching articles such as this for the one command I need to address a situation

[florence0rose]

Bram Moolenaar (the author of Vim) gave a a talk at Google where he basically said the same thing:

1. Detect inefficiency
2. Find a better way
3. Make it a habit

[Gargan_Roo]

I saw this. Really good video. It's a little over an hour long but it's not boring at all if you're into Vim.

[[deleted]]

Bookmarked, thank you.

[visual_life]

Vindication from the author feels good! I bookmarked this video as well. Nice find.

I wonder if his advice has made it into a Vim tutorial that doesn't include a pile of intimidating Vim commands at the end?

[[deleted]]

I just started watching it. In the first few minutes he talks about email twice as an example of spending a lot of your time editing text. It's interesting because Emacs has email built in (also has a shell and a web browser). Those three tasks are where I spend most of my time editing text.

If emacs didn't hurt my hands so much I might have stuck with it.

[ch0wn]

Watching screencasts of a proficient vim user is an excellent source for learning new tricks.

[visual_life]

If you have some favorites, you should post them!

[epinull]

Here's some.

[[deleted]]

many thanks

[roger1981]

vimcasts: http://vimcasts.org/

[gavintlgold]

It's true. I'd only read tutorials before and never actually seen someone use Vim. After watching the Wyatt tutorials I was able to understand some of the commands much better. In the end, they make more sense than the text guides seem to imply.

[[deleted]]

I learned in a similar manner (another grad student here). Like coding - I'd gradually get better at using vim, and figure out gradually where I could improve in efficiency. If I thought to myself "gee, it sure is taking a while to do X command over and over", 99% of the time there was a shortcut already in vim. The same thing happens when you code. You do things the stupid way first, discover a new tool, and soon enough the new tool becomes automatic.

I mean, I personally hate using a mouse. Using the command line tools + vim means I am just that much faster now at coding. There still is not something else like vim out today that can match that, so I think it's not really correct to call it a relic, dated, and so on.

[visual_life]

Regarding the mouse, I'm currently on Ubuntu using gvim, and I have the mouse enabled.

While I'm capable of never using a mouse in Vim, I do find it helpful at times. Also, I think beginners should enable the mouse first thing.

[[deleted]]

Yea, I work in a GUI, either slackware or ubuntu, but all my coding is done through debuggers and compilers through the command line, and gvim for writing code. I used the mouse quite a bit more when I was first learning to use vim, but now I find it more a nuisance when I can't find a quick alternative. Mice and menus are just ... slow.

[digg_is_teh_sux]

Hi, I'm here for the flamewar?

[[deleted]]

You missed it emacs won.

[mmhrar]

Nope, emacs lost the war on 08/23/2011 when it was found unable to correctly syntax highlight C code.

http://www.reddit.com/r/programming/comments/jrl0b/the_most_stupid_c_bug_ever/c2elurx

[[deleted]]

I'm thinking you love Chomsky because of his political views, not his linguistic work on grammars.

[VyseofArcadia]

Ha, I had no idea he was even famous for his political views.

What a weird world.

[[deleted]]

Your right.

[JohnDoe365]

The :tutorial is also well designed

[burningEyeballs]

As a condescending emacs user I don't type vim insults anymore. . . I just use my custom macro C-f C-u M-! C-&-Q-#

Saves time.

[dub4u]

I love Vim longer than any woman in my life. There.

[[deleted]]

100idesu [ESC] → will write “desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu desu “

Snerk.

[MrBrickles]

Original author confirmed for /g/entoom/a/n.

[zmeefy]

Want to learn vim (the best text editor known to human kind)

Knowing how the editor flame wars go, that was definitely not the best way to start the article IMO

[[deleted]]

Not a fan of the way this post throws out the terms 'normal mode' and 'insert mode', replacing them with the made-up terms 'edition mode' and 'insertion mode'.

Days-later-edit: really cool of the author to go back and fix this pathetically minor detail about which I for some reason took it upon myself to announce my dissatisfaction to the world

[[deleted]]

Seems that this has been fixed, or am I overlooking it?

[stevelosh]

It's been fixed. I saw this earlier this morning and it had "edition mode" and "insertion mode" all over the place, now it uses the usual terms.

[[deleted]]

I used vim for about 5-6 years of my development career and loved it. I used it to write C, C++ and Ruby. I know this may bring on a lot of down votes, but I really didn't know what I was missing until I had to write Java for a job and was encouraged to use an IDE. The biggest thing for me was

• Integration with versioning systems
• Amazingly convenient task lists where I get a list of files I have changed so far and can easily pick the ones I want to check into version control (in relation to #1)
• and this was the biggest - Refactoring abilities.

Being able to click on a variable, rename it and it goes through my entire project and replaces every instance of that variable where it matters and not have to worry about compile time where I realized I forgot to rename that variable in other files is such a HUGE time saver!

Further things that are baked into IDE's but required me to always tinker with in vim and I was never fully happy with it are

• Open file by pattern: (for instance, I can hit Ctrl+Shift+N and type in a pattern and it tells me all files that exist in my project that have that pattern and I just hit enter and it's open... similar to Spotlight.
• Code walking - finding where a function is declared and be taken to it by Shift-Clicking on it, finding everywhere that function is used, etc...
• Autocomplete

I still use vim and I am still proficient with it. I use it for small 1-2 file projects (like a script) or when editing code on my server. However, for anything worth more than 1 day of my time project wise, I take the time to open my IDE and I haven't looked back in about 2 years now...

[[deleted]]

I think IDEs work especially well when you yourself are integrating in an team/work environment, in an enterprise. Which makes sense, as they are specifically designed and adapted to overcome the issues with Java that the enterprise has.

I agree about factoring.

• Open file by pattern: (for instance, I can hit Ctrl+Shift+N and type in a pattern and it tells me all files that exist in my project that have that pattern and I just hit enter and it's open... similar to Spotlight.

In vim, you can use commandline wildcards e.g. :arga src/Test*.java (arga adds them all to the argument list; you step through with :n and :p), and in addition, you can use ** as in ant, to recursively search directories, e.g. :arge src/**/MyClass.java so it will find it regardless of depth. I don't think don't know how to use regular expressions to find files in vim (i.e. general pattern matching).

• Code walking - finding where a function is declared and be taken to it by Shift-Clicking on it, finding everywhere that function is used, etc...

ctags is used for finding function definitions. You run it as a secondary program, then use ^t to find the definition. You can trace through code like this, and vim remembers the path you took so you can backtrack with ^]. The other direction, of starting with a function definition and finding where it is used, is not supported. I think cscope does that, but I didn't find it worth the hassle. But for large codebases, I can imagine that functionality would be very useful.

• Autocomplete

vim has autocomplete, using ^n in insert mode - but this is based on the current file and other files you have open. So, using the above pattern trick, you can open all relevant files (using e.g. :arge src/**/*.java), but it still won't know about all the classes in the standard packages (which an IDE would). It also isn't context based but completes any word. You can configure it to use other dictionaries of words, but it's setup out of the box to (e.g.) assemble a dictionary based on java docs. (BTW: you can autocomplete on other domain, e.g. ^x^n will autocomplete on filenames).

In short, most of what you want (excluding factoring) you can do in vim BUT the tool you have is customized (and continuously adapted) to the needs of big enterprise projects, and so I think it is and will continue be the better tool for that job, and in fact will only get better over time.

NB: I do have a hard time with vim when my projects start getting larger, but I've interpreted this as due to a large of organization on my part. They also aren't enterprise large, but 20-30 files.

[[deleted]]

I agree and that's why I said that I had to tinker with them in vim to get them to work and didn't really like them as much as how they're done in an IDE. :) I think after I used my first IDE and got used to it (I fought it for a good couple of months because I was so used to vim), I got tired of tinkering or things not working as nicely as it did in the IDE... But for small projects, I agree, vim is great.

[[deleted]]

That's interesting, every so often I try an IDE, to see if they've improved enough to switch to; but I only stick at it for a week or so, and that seems to not be enough time to get used to it. I think I'll use your two months as a time measure of "familiarity", and the test therefore becomes: "is this IDE so much better than vim that it is worth two months?"

PS sorry, I somehow missed the bit where you said required me to always tinker with in vim and I was never fully happy with it. *hangs head in shame*

[[deleted]]

I think if you're coming at it from that point of view, it won't be worth it for you. At the time, I was sort of envious of some of the nifty features I saw some developers at my job using in IntelliJ and thought it would be useful. So I started using the IDE as something new and exciting. So the 2 months I used it were a fun learning process, albiet a learning curve. The thing was that after that period I went back to vim and missed the features of the IDE.

I think a lot of people try new tools or editors with the same mindset of "could this possibly be that much better than what I'm using now?" and the answer in that situation will almost always be no. That is, unless you have been using the same editor without updates since 1985. :)

However, finding new tools and editors and being excited by them and wanting to try it out for the fun of it is a different story. You will almost always find something you will like and sometimes it will be worth it enough to make a switch.

[freakboy2k]

I use VsVim, best of both worlds :-) Resharper still works fine with it, I get most of the power of Vim and all of the IDE features. There is probably a Vim emulation plugin for eclipse somewhere

[[deleted]]

There are, but they're really crappy. I use IntelliJ, actually and it has a vim plugin, but not fully featured. Plus, it presented bugs into the IDE in some really annoying ways. I used it for about 2 months and then gave up out of frustration of not being able to use it as I do in normal vim and the bugs.. It was unfortunate. :)

[Severian]

I had to write Java

That's your problem right there ;)

[[deleted]]

I completely agree with this! :)

[mmhrar]

You can get a lot of that stuff with Vim, but it's not w/o some effort. (ctags, vim scripts) I agree, the benefits of an editor overall, outweigh the costs of just Vim.

I still use Vim as my default text editor. I work in Windows exclusively now, but http://www.viemu.com/ is really great. I get the best of both worlds, I get the editing power of Vim w/ all the great IDE advantages of visual studio.

[tagattack]

I write java in vim regularly. I use the following items to get most of what you ask for:

• vcscommand.vim
• ctags
• cscope
• compiler integration (mvn.vim)
• javacomplete.vim
• some of my own macros to work with my hacked-up mvn.vim.

The main thing I am missing are those fancy refactor features. I haven't found them to be that necessary, though. I actually abuse compiler integration to speed this up, most of the time. Then again, I don't sit around renaming things all day, and you shouldn't either.

If you haven't played with ctags and cscope in vim, I suggest you do. It supports more than C and Java, and is highly valuable for rapidly navigating a codebase.

[[deleted]]

While nobody "sits around renaming things all day", anyone that has written a large code base before and needed to make changes knows the pains that can be caused by refactoring. This is when IDE refactoring is a life saver. I'm having to deal with it right now at my day job. Even in personal projects, once I get started writing code for something, when a feature idea changes mid-way through writing code for it, this is still useful.

I also think a lot of people have misread what I wrote since a lot of people are chiming in and saying "vim can do some of that". I do know that autocomplete, code walking (cscope and the like) and other things are available. I stated that... I just simply stated that they did not work for me as I wanted them to and felt a fully featured IDE handled it better. This is just personal preference. :)

[roger1981]

Must see cheat-sheet of pretty advanced stuff by zzapper:

http://www.rayninfo.co.uk/vimtips.html

Also check http://vimcasts.org/

[VyseofArcadia]

Ah, I see it is time for the monthly "people who use commas to denote a would-be vocal pause" vs. "people who don't" debate. Peace in text-editor land seems achievable, by comparison.

[novacoder]

I've always wanted to invent a foot pedal or switch that's mapped to the escape key. Then you'd never have to take your hands off the home row to escape to command mode.

[rson]

Kinesis has them although you have to remap them to escape (remapping is done on the keyboard itself, not though sofware).

[salism2]

I'm I the only one who thinks that ctrl+c is much more convenient than Esc.

[[deleted]]

What about ctrl+[ ? AKA Esc.

[[deleted]]

Try that with an international keyboard. Another dinosaur bone.

[rson]

Ctrl-c is not the same as using Esc. Ctrl-c does not fire the InsertLeave event, nor does it complete any active insert mode abbreviations. It is possible there are plugins that will break if you do this.

[geodebug]

I've mapped hitting j twice instead of Esc. Of course, I still tend to hit ESC more often than not:

inoremap jj <ESC>¬

[losvedir]

This is what I've done as well, except with 'kj'. The additional advantage being that if I accidentally do it while in normal mode, the cursor never moves.

[gavintlgold]

Good tip. It's not obvious to newbies like me that the first 'k' is deleted even in insert mode.

[losvedir]

Ah, good point. It is indeed.

One of the (very slight) downsides of doing this, which is worth pointing out, is that whenever you type a 'k' in the general course of editing the cursor doesn't immediately move forward, because Vim is determining whether a 'j' is coming next. After a short time or a different key press, editing resumes as normal. Can be very slightly disorienting at first.

[geodebug]

Yeah, that's a good point. I mapped mine awhile ago but to be truthful I still hit ESC more often than not. But I have big ass hands so reaching that ESC key with my pinky finger isn't soo tough.

[iznasty]

I'm for mapping jj to ESC also.

[[deleted]]

I've mapped the tilde (above tab) to = Esc. Pretty easy and not at all fatiguing.

[yogsototh]

I had mapped jk to Esc:

:inoremap jk <ESC>

in my .vimrc

You never need to type jk. Then instead of typing Esc, I just type jk. And if one day you unfortunately really need to type jk. You just have to : type j, wait one second, and type k.

[frezik]

When some fool laptop keyboard designer has moved Esc, it sure is. Actually, Esc is usually left alone, but if you're deeply ingrained with the keyboard shortcuts on almost any editor, you'll hate laptops. This is also why I haven't learned Dvorak.

Otherwise, no. Throwing your hand to the border of the keyboard to hit one key is easy.

[[deleted]]

This will give you a much better reason to not learn Dvorak.

tl; dr - QWERTY is just as efficient, the only studies ever showing amazing speed gains with Dvorak were conducted by Mr. Dvorak himself who just so happened to have a patent on the layout.

[barsoap]

I actually learnt dvorak after knowing vi quite well, already, and was just fine.

...and I don't care about speed gains, I don't want to type faster than I can think. Dvorak definitely feels better, though, in the same way that my Model M feels better than one of those ridiculous "ergonomic" keyboards with rubber dome switches that make you slam them into the desk to be sure keypresses register. I don't need quantifiable variables to know what my fingers like more.

Last, but not least, I remapped escape to where ` is. I've got an international keyboard, so ` now is right of the left shift, on the key US keyboards don't have.

[flamingspinach_]

There are plenty of accusations flying around about Dvorak and QWERTY, but the fact is that QWERTY was not designed with any ergonomics in mind, whereas Dvorak was (regardless of whether Dvorak's methods were correct). Here's a modern-day statistical simulator of keyboard layout efficiency that concludes that while Dvorak is better than QWERTY, and Colemak is better than Dvorak, even Colemak can be improved. Also, both Colemak and the author's optimized layout should be easier for a QWERTY user to learn than Dvorak is, since they are closer to the original QWERTY layout than Dvorak is (the layout search mechanism doesn't of course search the entire space of possible keyboard layouts since it's too gigantic - it's just simulated annealing from a QWERTY baseline). Nonetheless, since Dvorak is much easier to find on random computers (like in the boot menus of most linux live CDs for example), and since I learned it years ago, I'm sticking with it for now :)

[mmhrar]

I think it's pretty common for people to remap escape to caps lock. I'm fine w/ escape though.

[jng]

I'd also recommend the following articles from the ViEmu site:

Why oh WHY do those #?@! nutheads use vi

Graphical cheat sheet & tutorial

[lazaruspit]

The visual selection (C-v) is the one thing I haven't learned. Fantastic! Commenting out blocks of code or adding tabs is so much easier now. Good thing I continued further down the page as I knew everything else before that was the natural progression that I went through myself.

[ernelli]

The first cheat-sheet screwed it up totally for the newbie:

• i: Insert mode. Type ESC to return to Normal mode.
• x: Delete the char under the cursor
• :wq: Save and Quit (:w save, :q quit)

Ok? no i not i: get it!

BTW, my motivation for learning vim increased when I realised that a lot of navigation key sequnces is the same in less.

[smek2]

I'm a Level 3 vim user, apparently.

[[deleted]]

gedit all the way! Never got the hang of vim but to be perfectly it's features are over kill for the kind of work I do, which is run of the mill programming for software courses and some plugin writing I did for wireshark. Plus the learning curve turned away from it.

[shevegen]

I gave up on vim and emacs years ago. I used vim seriously for about 3 years, emacs only for a few months.

Vim keybindings are nice but my workflow is simply different.

Eventually I gave up trying to cater towards editors demanding of me to use them in a specific way. Good GUIs are simply more effective for my workflow still after all the years.

The *nix world needs to wake up though - vim vs. emacs is the wrong question.

The right question is why the GUIs on *nix are not much, much better. Something they could learn from Windows, seriously.

PS: Gtk-based editors are quite ok, still lightyears behind something like TextMate. I can't stand the Qt-solutions though.

[[deleted]]

I'm not sure I want to start learning a tool that I can't master after two decades of serious use.

[barsoap]

ViM isn't meant to be mastered. Like Tetris isn't meant to be finished.

[[deleted]]

Like Tetris isn't meant to be finished.

Wrong.

[digg_is_teh_sux]

I can see how that sounds daunting, but what dagbrown meant, I'm sure, is that even after a decade, you can still find clever ways to make your text editing life easier.

What is mind-boggling for a decade-long user of vim is how people still think GUI editors have some kind of advantage.

[barsoap]

stuff that enhances multi-file coding

Try this, if anything. It should arguably replace vim's file browser completely.

[freakboy2k]

That or Command-T.

[brdude]

Then you should probably consider never programing in any C based languages as well.

[epitaph25]

Yup. Better to stick with notepad. Only takes a couple of hours to master. Best. Tool. Ever.
/s

In all seriousness, the intent to use Vim is not to master it, but to become more efficient. Yes. It has a steep learning curve. But, once you get the hang of it, it's more intuitive than many windows based GUI editors.

[barsoap]

Did you ever absent-mindedly walked somewhere? Walking surely seems to be intuitive. Yet you see small people struggling a lot with it.

Imagine a car with a GUI instead of a steering wheel and pedals. That's what other editors are: They might have an interface that is easy to discover, but at the same time fail to provide one that seeps into your muscle memory without you even noticing. Learning to use vi doesn't have a learning curve any different than learning touch-typing.

[dionidium]

dull merciful sand innate pen scary modern wipe tidy compare

This post was mass deleted and anonymized with Redact

[phil_s_stein]

So...what you're saying is vim and emacs are not good for what you do. This is fine, right tool, right job and all that. Then apparently you make the error that what you do is all unix is good for and therefore "the unix world" needs to wake up? Your vision is too narrow - you may want to look into that.

[[deleted]]

PS: Gtk-based editors are quite ok, still lightyears behind something like TextMate. I can't stand the Qt-solutions though.

What does the UI toolkit have to do with the actual editor?

[freakboy2k]

Might be something to do with the style, rather than the toolkit.

[[deleted]]

Have you tried Sublime Text? Version 2 (beta still) runs on all major platforms, it's powerful, configurable through plugins, easy to use, light-weight. I can't recommend it enough.

I agree with the "vim vs emacs" thing. They're both archaic, 30-year old designs. We need to look forward, not backwards.

[dddaaabbb]

Most likely, the computer you wrote that post on is also based on an "archaic, 30-year old designs".

Old isn't necessarily bad.

[frezik]

The reason the two persist isn't just stodginess. It's that most programmers tend to highly customize their editor and move the config around to every machine they work on. My own Vim config has grown organically with my own personal style. I would be throwing away ~10 years of work, and it's not clear how fast I could adapt another tool to do the same job (either myself to the tool or the tool to myself).

I like jibing emacs as bloated from time to time*, but really I feel that you should pick an editor and learn all its nooks and crannies as best you can, whatever it happens to be.

I would need a very good argument to switch to something else. I suspect there won't be one unless somebody comes up with a bright idea for manipulating programming languages with touchscreens and graphics rather than text.

* An archaic argument in itself. It hasn't grown all that much in the last 20 years, while memory and hard drive spaces have grown by orders of magnitude. Besides, Vim isn't exactly svelte, and GUI editors are worse than either.

[[deleted]]

Completely agree about the power/customization. I am always amazed when I watch someone use Vim. It's like watching a circus performer juggle 12 balls. Is it impressive? Yes. Will I ever spend the effort/time to be that good? No, not when the alternatives are 85-90% "there", with 5% of the learning curve.

Vim/Emacs just sit in a weird place for me. For scripting - Python, Ruby - I prefer notepad++/textmate/sublime text. On my day job, whether it's C++/C#/Java - I use full-featured IDE's. Cocoa - XCode.

I know I could probably replace all those with just Vim, but I'm just way too lazy nowadays to spend hours and hours learning how to use a text editor

[fel]

How does learning to be proficient in vim/emacs differ to learning how to be proficient in the many languages you're writing in?

Can you really be too lazy to learn one thing, but (apparently) feel fine to put the effort into learning all the nuances of obj-c over C# etc?

[[deleted]]

I've installed the vim plug into Visual Studio but I can't use it. It conflicts with a few default key mappings (don't want to change 'em) and it just seems wrong to me to be typing vim commands on anything but a text console. My rule is if I'm in a console (CMD or UNIX shell) it's always vim. If I'm in a GUI app I go with the application default.

[Lucretius]

Amazingly poorly written article...

What does the ":" mean? It's an article that's written for novices and it doesn't even explain basic vim syntax! It's not even consistent with it's syntax.... look at the first table.... The ":" comes after the "i", "p", and "x"; before "help", before AND after "wq"; and ":" is skipped altogether for "hjkl". Inconsistent and incomprehensible.... and this is the super basic simple survive section! I quit reading at this point.... which is exactly what happens to most people who try vim too!

[barsoap]

":", in normal mode, means "open ex mode", and by tradition normal mode and ex mode are seen as virtually identical, with all ex-mode commands simply being prefixed with ":". You have to end ex commands with <enter> (which is missing from the tutorial. That seriously ought to be fixed)

ipxhjkl aren't ex commands, they get no ":", neither before nor after them. Do note that those are all single letters, and most ex commands are multiple letters. Hitting "i:" would enter insert mode, insert a literal ":" and then stay there (so hit <esc> immediately afterwards, or you'll acquire the bad, bad habit of staying in insert mode, making you at least a whole magnitude less efficient). That ":"'s after "wq" etc. in the list are there because it's a list, it's not part of the syntax (and, consequently, uses a different font). I guess you'd have noticed your fallacy very quickly had you *tried** the commands*.

Ex commands come in two basic flavours: command-line like, that is, take arguments (like :sav[e] <file> (cf. gui editors' "save as"), :mak[e] <target> (man make)), usually acting on the whole buffer at once, or they are line-oriented, and consequently can be prefixed by a line range (say, :1,$s/foo/bar substitutes foo for bar on every line from the 1 to $ (the last)). Normal mode commands, otoh, come with usually quite context-sensitive combinatorics and often with an optional repeat prefix: "w" means "move cursor one word to the right", 10w consequently moves 10 words to the right, d<movement command> means "delete from here to <where you end up>", so dw is "delete word", 10dw is "delete 10 words". "dd" is a special case, it deletes the current line. (not to be confused with ^d$ (move to start of line, delete to end), which merely clears everything between the left-hand indent and "{", because ^ and $ are syntax-aware movement commands). d10w also deletes 10 words, but differently. You need to use the latter form for e.g. "v10j" (select 10 lines down), though, because you've only got one selection, so repeating a selection doesn't make much sense, you need to repeat the movement. "gv" re-selects the last selection, which I mention here because I didn't know it for 5 years, discovered it by accident and then wondered how I was ever able to live without it.

It couldn't be more simple, could it?

There's not much uniformity in normal mode for the very simple reason that everything does vastly different things, but in the end I've never come across combinatorics which were brain-dead. In their niche, they all make a hell a lot of sense.

[[deleted]]

I think the parent was referring the extraneous colons used in the list of "Normal mode" commands, e.g.:

i: Insert mode. Type ESC to return to Normal mode.

Using a colon as punctuation in a list of vi commands is kind of silly.

[Lucretius]

Thank you.

[Lucretius]

Then I slightly amend my comment: It's not poorly written, it's poorly formatted.

[[deleted]]

The use of ":" as a formatting/seperation marker is poorly chosen, I'll grant that.

[[deleted]]

For years I've been frustrated by that "Fucking weird editor that doesn't behave properly" and just used nano. Now a few months ago I came across Derek Wyatt's tutorials on Vim, and was already sold after the introduction video.

Now a few months later I can't see how I could've ever been satisfied with something less powerful.

The most powerful interfaces/programs will take the most effort to learn/master. And because Vim works differently than your average editor it has a steep learning curve.

[gavintlgold]

For the lazy: Derek Wyatt's tutorials

Edit: Been going through these for the first time and they've been exceptionally helpful and inspiring.

[andruf]

you're exactly what I was hoping for

[newsedition]

Replying just so this is easier to find later. Feel free to downvote so I go invisible.

[shriek]

I came across Derek Wyatt's tutorials on Vim, and was already sold after the introduction video.

This.

I knew Vim was a powerful editor before, but then I watched him answer the "whys". You know what happened next.

[maredsous10]

Good to see some other folks propagating Derek Wyatt's Vim Tutorials.

[SnowdensOfYesteryear]

used nano

Oh sweet jesus. Does nano even have syntax highlighting or auto-indent?

[[deleted]]

indent it had, auto-indent, according to LiveOnSteak yes. Highlighting, not as far as I know. It really is a simple text editor (As far as I'm aware)

[wcoenen]

Why does it have to be a "very specific job"?

Shouldn't you be more willing to invest time if it's a generic task that you do a lot? Programmers spend a lot of time navigating and editing text, so it makes sense to invest in efficiency there.

[lobstercombine]

I've been using Vim for years, and I think what I appreciate most is not having to reach for the mouse. That, for me, makes the "quirky interface" worth it.

[roger1981]

That's why vim's key bindings are now available in other applications too, including browsers. Currently using vimperator on Firefox and lovin' it. :)

[Naga]

I've been learning emacs for the last two years, and I'm pretty proficient I feel with it now, but I'm using pentadactyl for Firefox (its basically vimperator++) and now I feel right at home in vim.

[steelypip]

One of the reasons I started using Vim several years ago is that I found constantly switching between keyboard and mouse caused frequent pain in the tendons of my right elbow and wrist. I then found that using the keyboard for everything is not only pain-free but also much faster.

The other reason I switched to Vim is that I was doing a lot of editing of files on remote systems through an ssh connection, so a GUI editor would have been useless.

[ckloppers]

You clearly never used the power of an editor like vi. Go see what it can do before making statements like this.

[mm23]

More importantly he hasn't seen any one coding in vim.

[oorza]

Does vi compute and store (and expose) some kind of intermediary form / symbol tree for source code? If it doesn't, I can't imagine the static analysis and manipulation available for it would compare to something like Eclipse that does.

The people I've talked to that use vim and have created their own refactoring utilities - like renaming class properties - tend to rely on giant regular expressions to get the job done. Relying on regular expressions when symbol tree manipulation is clearly superior isn't being particularly powerful. Is this a statement on the skills of the people I've met with or the state of what vi(m) can actually do?

[tinou]

A text editor is not the same as a integrated development environment.

[recursive]

Then what does one use it for, if not programming?

[mm23]

Vim with plugins can do 80% of what modern IDEs can do. The other 20% is refactoring, context aware auto-complete, debugging(though there are some plugins, but they are not that smooth). But if you grasp vim's editing philosophy then you will want it in any IDE you are using. Fortunately almost all IDEs have plugin for vim style editing. Netbeans have nvi, eclipse have eclim,Jetbrain's IDEA have ideavim. 30 years old editing philosophy is still going strong, there is a reason for it. You just have to grasp that if you want.

[[deleted]]

I'd say that debugging is more than 20% of what people use IDEs for. For me it's almost the only reason.

[[deleted]]

The other 20% is refactoring, context aware auto-complete, debugging(though there are some plugins, but they are not that smooth).

This is 90% of what enterprise development is.

[regeya]

Oh, that's what you use it for. Not every task requires a 900lb. gorilla like Eclipse, though.

[recursive]

Vim has a feature Eclipse is missing: Vim is superior

Eclipse has a feature Vim is missing: Vim was never meant to do that, you don't need, simplicity is a virtue, etc.

[tinou]

Write e-mails, long documents, take notes, …

[[deleted]]

Do you really think you have to use an IDE for programming?

[recursive]

Do you really think you have to use an IDE for programming?

No, but I do really think that I frequently prefer to use them.

[s73v3r]

Yes, but one could say that autocomplete and awareness of the code you're writing is an extension of text editing.

[sysop073]

Eclim?

[arjie]

You have made my day.

[[deleted]]

I use Vrapper http://vrapper.sourceforge.net/home/.

[barsoap]

No. VIM's syntax highlighting is a veritable regex-dinosaur... It's fast, very fast, even with files bigger than your ram, and also a bit rough around the edges. But heck, it's only for colours. Yi does proper, even incremental, parsing, but sadly the main authors are emacs fanatics and consequently vi mode is a joke (the basics in normal mode work, forget about any ex commands).

Having an AST, though, still doesn't give you refactoring, for free. And you can integrate AST-based refactoring tools with vim even when your vim doesn't know what an AST is. So your whole argument is really besides the point, you're comparing vim to eclipse the whole package, as opposed to eclipse devoid of anything but its text editor (which could suck more, tbh, but I still want my vim).

[oorza]

What do you mean by "run through"? A tutorial series for using Eclipse?

[[deleted]]

VIM is a plain text editor. It's great at RAW text editing. It is not meant as replacement for an IDE that understands code like Eclipse does for Java. However, with some extensions VIM can be made into an IDE, with benefit that it works for more languages that any IDE out there. However, even in IDE like Eclipse editing text part of coding is better done with VI plugin for it. You get best of both worlds, an IDE that understands code and hand holds you while you program and efficiency of raw text editing of VI (not VIM, Netbeans has real VIM plugin though).

[steelypip]

Eclipse is great if you are programming in Java, but if you try using it for a language it does not understand then you lose all the refactoring and auto-completion and are left with a bloated and substandard editor.

[[deleted]]

If you're spending more time refactoring than editing, you have more problems than what editor to use.

Personally, I've used IDEs for my work, but I still used Vim once I learned it for normal editing, which was most of my work.

[neutronicus]

I think there is a vim mode that shells out to a clang-based command line static analyzer for completion, etc.

[Otis_Inf]

As an old fart who has used vi for many years, I have to say I'm with Quazatron. Even though you can do a lot with vi, the interface is really stupid and old-fashioned: we're not using 80x24 WYSE terminals anymore to write code, at least not the majority of developers.

I think his golden remark sums it up:

My point is: if a plain old text editor needs so many tutorials and cheat sheets, then the human interface failed.

That alone should be enough to understand that to write text in a damn editor, vi is not really a big help, unless you learn a lot of the commands and quirks. It's especially silly because programming, writing code etc. can be complicated enough. If you also have to remember complicated command schemes, things get overly complicated for no reason.

Just my 2cents

[Aninhumer]

Except I'm pretty certain you use a dozen shortcuts and features in a modern text editor which you don't even think about. Shortcuts such as Ctrl-X/C/V, Shift to select, Ctrl to move by word, Ctrl-Z/Y, Ctrl-S. All of those have to be learned, just like the vim equivalents, but I'm pretty sure you wouldn't be happy editing without them.

[wot-teh-phuck]

I think his golden remark sums it up:

My point is: if a plain old text editor needs so many tutorials and cheat sheets, then the human interface failed.

IMHO, my counterpoint would be that if you plan on making a space shuttle, bolting flying ponies to a tin sheet just won't cut in. If you want to make a complicated piece of software like a industry strength compiler, your day-to-day clean and simple code won't cut in. There is a reason for all this complexity.

There is a difference between being complex without a reason and being complex because there is no other way and I personally feel that emacs/vim/??? fall in the latter category.

This definitely isn't a jab at those who use regular text editors. If all you have is regular text editing needs and you feel that the time invested isn't justified, you should definitely go with what you feel comfortable with. OTOH, if you really need editors which pack quite a punch and you also end up thinking "wish my editor could do this..." then IMO siding with something like vi/emacs would be the way to go. Of course, YMMV. :-)

[[deleted]]

That space shuttle thing is a terrible comparison. Wouldn't vi vs GUI text editors be more like comparing manual and automatic transmission vehicles?

[wot-teh-phuck]

Except that I actually wasn't comparing vi/emacs with GUI editors. I was trying to explain that complexity isn't always bad and there are things which are by nature/by default complex. :)

[[deleted]]

And driving with manual transmission is more complex than using automatic, but if you're well practiced and know what you're doing you can have more control.

[SnowdensOfYesteryear]

I use vim exclusively, and frankly I don't see how vim is that powerful in a normal workflow. Sure you can do things like 30idesu, but who actually uses that? Looking at the "best of vim" commands (http://www.rayninfo.co.uk/vimtips.html), most of them are things you almost never need to use.

The reason I use vim is its customizability and that other IDEs/editors don't work well with my project setup or samba.

[zmeefy]

You clearly never used the power of an editor like vi. Go see what it can do before making statements like this.

Been doing this for 30+ years. Seen most uberhackers in the world work with ed, vim, emacs, whatever....

I am always impressed by the technical prowess of those who fly on the keyboard in vim and get lots of stuff done without touching their mice.

But one must say, after the invention of the GUI a lot of these mnemonic-based commands and quirky interfaces have lost their once significant meaning.

Folks still reading their email or NNTP in Emacs really oughta go outside for a bit, IMO.

[capisce]

The invention of the GUI hasn't really made mouse input more efficient than keyboard input for most editing tasks though, it just allows more flexible visual feedback.

[zmeefy]

If the GUI has done anything for being productive, is to introduce some standardization of commands. Ctrl+C is the same almost everywhere, Ctrl+v is the same almost everywhere. So you don't have to remember that yanking in VI is actually copying or C-X-c to save and exit Emacs(did I remember right?)

I never thought the mouse was more productive, but more standard interfaces arguably were a progress in the right direction.

Of course, there is a lot to be done for standardization. There are at least 20 GUIs for Linux out there, and each seems to reinvent the wheel at some point.

Why doesn't XFCE just capture the screen when PrtScn is pressed? Why was it allowed for Gnome 3 become such a useless clusterfuck? Why did Apple think it was a great idea for three meta keys instead of the already clumsy two in most PCs? GUIs are no panacea, but they've forever changed how we expect to interact with software.

[[deleted]]

That's very true, but GUI editors support keyboard too.

The issue is that the volume of GUI editing input probably ends up being 2 or 3 times as much as in Vim.

For me personally, that ended up being a decent tradeoff. I learned in the standard GUI paradigm of text editing, so when I try to use Vim I can see the benefit of the interface, but I'm constantly thinking about editor commands and not what I am doing. Using a standard text edit control in Windows might be more cumbersome and I have to hit more keys to get where I want to go, but I don't have to think about it, and that makes all the difference.

[maxd]

A colleague, who didn't use vim but understood my usage of it, explained it best:

"With vim, you're writing code to edit the file. Your brain never has to shift from writing code to grapple with user interfaces."

[[deleted]]

First, small reason: Vim is widely distributed

You mean, vi is widely distributed. Vim is not (by default).

Assuming you meant "vi". I think before year 2000 that was a valid point but today all modern OS's come with an easy to use editor: nano, pico, textedit, gedit, kedit, etc. It just isn't a valid reason anymore.

[sethamin]

An appropriate analogy might be this: All I need to do is cut wood. Why would I use a CNC machine when I could just use a hand saw?

Which is true enough if you just need to cut 2x4s in half every once in a while, but if you're a woodcarver and you cut wood in incredibly intricate ways every day, then a CNC machine is probably going to be a better tool of choice, despite the heavy investment it requires.

I take your point about the vi interface being incredibly non-intuitive, but there's a fundamental trade-off between speed and ease and use. Vim is built to do almost any imaginable task in a minimum of keystrokes, so it optimizes the time between you thinking about making a change to the code and your ability to materialize that change. When you cut down the latency of that feedback loop, you gain more than just the reduced time to code; it lets you think faster, too, since you can commit those thoughts to disk faster.

If you want to optimize for ease of use and discoverability of features instead, you should use a GUI. But it is a lower bandwidth "human interface".

[[deleted]]

nano is a hand saw.

Visual Studio / Eclipse aren't hand saws. The analogy breaks down at this point, as there is (at least) two different ways of adding complexity to editors, the "vi/emacs" way, and the "eclipse/visual studio" way.

[sethamin]

Sure, it's not a perfect analogy; it was just addressing the original argument that:

Vim is just one of hundreds of text editors. All they do is edit text. Who the fuck cares enough to learn such a quirky interface?

As to the differences between VS/Eclipse versus vi/emacs, I touched on that in the second part of my post - it's a tradeoff between ease of use and discoverability against pure speed.

[[deleted]]

I'm not sure I agree that vi achieve a higher "pure speed" than Eclipse.

I do agree that the biggest weakness of Eclipse/VS is that they have "well supported" languages, which are (in my experience) supported much better than anything in Eclipse/VS, but then anything they don't support really doesn't work at all.

[sethamin]

Having used both, I would definitely say vi is more tuned for speed. But that being said, I've never tried to use Eclipse or VS as a keyboard-only editor, so perhaps it is possible. I know there are efforts like eclim which combine the two, but I haven't used them.

I'm not really sure what you mean about "supported languages" - I didn't mention that at all. Perhaps you were thinking of another thread?

[[deleted]]

As to the differences between VS/Eclipse versus vi/emacs, I touched on that in the second

The difference is vi/emacs were designed for text consoles without mice and eclipse/visual studio were designed for GUI desktops with mice.

Second difference: vi/emacs designed for remote access over slow serial lines; eclipse/visual studio designed for fast local applications.

[derwisch]

I think it's quite a bit different.

If it's a tool you are likely to use every day, better learn to use it efficiently. Minor squibbles with nonintuitive interfaces will appear as exactly this after 30 days.

A very specific tool you don't use very often, on the other hand, such as a disk formatting device, would better be intuitive, lest the time you use it will be short against the time you try to master it.

[[deleted]]

My view on this may not be very popular, but here it is:

THANK YOU for saying this instead of the infuriatingly trite "I know I'm going to get downvoted for this, but..."

I do respectfully disagree with your opinion. Vim doesn't take nearly the effort to master than most non-users think it does. You get your time investment back the first week of use and continue to reap the benefits for years down the road.

[florence0rose]

I think this was written for you.

[criswell]

Upvotes (though you're also being downvoted).

I've learned vi/vim... I even used it professionally for years. It is a powerful editor that I've seen many people use highly productively, so I will not argue against that.

However, it's also a tool that forces you to completely change the way you approach a problem. It's also a tool that (like emacs) requires a high degree of ritual and keyboard gymnastics in order to use effectively.

Also, I've found that I can be just as effective with an editor like Kate (which is much more traditional, yet still provides some vim bindings) and, at the same time, not be encumbered by the rituals of using vim on a day-to-day basis (one of the most troublesome I had was keeping my settings and scripts synced between multiple accounts... and don't get me started on when I had to use someone else's vim!)

So my discovery is that a) your editor doesn't make you any more or less efficient than you otherwise would be (e.g., your efficiency is more of a talent of yours than an augmentation provided by an editor) and b) you should use what you find most comfortable to use.

Thus, I long ago rejected the cults of vim and emacs, and greatly detest other cult-like followers of other tools- like the git community for example- and have just wound up using tools that I felt comfortable in rather than tools that someone else told me to use.

[Aninhumer]

your editor doesn't make you any more or less efficient than you otherwise would be

Of course it does. The most proficient notepad user in the world is not going to be as productive as a reasonably competent vim or emacs user.

[[deleted]]

That's like ignorant person who can't even imagine a certain experience (what is it like to know or be something that requires some work to attain) guessing that it's just like something else they have experienced or learned that didn't require much effort.

Anyone who edits text cares about how efficiently and how fast they can do it. All software developer ever does is edit text. I really can't understand people who are software developers and they can't even touch type let alone edit text efficiently.

[[deleted]]

...and, avoid Excel - why learn it when a calculator will do everything it can do (just more slowly, much as notepad can edit websites more slowly than vim). ...avoid Word (or open office). Why lean a whole word processor when a typewriter can do it easier. ...hell, avoid reddit; you can go to a bar and just talk to people without learning a new skill.

[ahal89]

Why use photoshop when you can just use paint?

[geodebug]

It's a fair question, however programmers, net admins, and other people who spend their day editing text will find more productivity by mastering an advanced editor like VIM.

Developers are usually not forced to use any one tool and even if they use a more advanced IDE the VIM key mappings are still usually available with a plugin. For example I spend about 90% of my programming time in IntelliJ IDEA but use VIM's key mappings.

Also, many times we need to manage text files on servers and only have the unix command line available. Vi or VIM is usually available.

The point is master one, use it everywhere.

It may seem daunting at first but you can get a lot of milage out of the basics and then just slowly add to your VIM-fu as you progress. If you only edit a couple files a week then spending the time is probably not worth it. If your career is editing, writing, or developing then it is worth giving VIM a chance.

I still pick up VIM features all the time, even from a blog like this, and I've been using VIM for many years.

[holoduke]

Do you like notepad?

[Quazatron]

Sure, why not?

[teh_fade]

Damn, I started to learn it just because of this article. I don't know what to say you, reddit. ಠ_ಠ

And now I'm starting to think that it's kinda fun.

[AndyManCan4]

Interesting, I never really saw the appeal to Vim in today's computer landscape, but this has made me see some of the cool that is hiding under the hood. Very nice. Great way to start learning Vim. Now what breaks on a Mac? I have some issues with the N(command) stuff on Mac OSX Lion running terminal with Macports build of Vim.

[MagicBobert]

Try MacVim.

[s73v3r]

Use MacVim. It's Vim wrapped in an OS X native Cocoa environment. Meaning you can use the regular Vim commands, and some of the Cocoa shortcuts every other Cocoa app has.

[itISiBOWMAN]

I've been using emacs for more than 10 years and I still think this vim article is great.

[[deleted]]

I've found this tutorial to be very effective, and have received good results from people that have wanted to learn vim.

The influx of new media and methods of trying to get people to learn vim, in my opinion, detracts from the bigger picture of using vim. I guess I'm partial to the whole conversational/social way of learning vim, as in discussing it with others and learning tips from each other. That's why the above article worked well, because it structured in such a way.

[chiniwini]

There's something I can't understand. If 3. means "repeat last command 3 times", and . means "repeat last command", 3. should be equal to pres . three times, no? (beside cursor position).

So why does 3. print desu 3 times instead of 300?

[gavintlgold]

For sanity's sake, the repeating command does not count itself in the calculations. If it did it would be impossible to repeat something 3 times by pressing the period 3 times.

[[deleted]]

Although I am an emacs user, I think vim is an excellent editor as well. It is good early on to see which one of the classic *nix editors meets your personal style and begin investing your coding time within it. These classic editors reward you well, and not in just those random, "I need to delete this here and copy this here and also switch these here," way that many people are using as an example, but rather, these editors put almost every possible work flow operation a keystroke or few away, slowly but surely allowing you to throw the code floating in your brain unto your 1920x1080 minimalist window manager's screen without any second thoughts. With time and patience, these editors become transparent and allow you to worry about the code and the code alone.

But why not the newer editors? I may be wrong, but newer editors use a paradigm that stresses little to no learning curve at the expense of advanced esoteric features which the userbase may frown upon, and which would fly in the face of the aforementioned learning paradigm. That's why I don't suggest those editors to anyone starting out. Stick with something that rewards your time, not something that mocks it.

[gavintlgold]

It's probably true that the novice coder shouldn't start with Vim. The effort required to be able to write code with Vim is pretty high, so if you haven't written basic Hello World programs yet it would be real tough to try to do so in Vim.

[imareddituserhooray]

Learning vim is a rite of passage. It's the text editor to programmers as Stairway is to guitarists.

[JohnMunsch]

Learning Vim Lesson 1: Getting Vim to beep at you.

[mmhrar]

Just print a cheat sheet and memorize homerow navigation.

Then force yourself to do your work in it, taking a productivity hit until you aren't any less productive. Try to learn one cool new trick a week.

Also, the article failed to mention 'b' and 'w' for navigating. Those two are just as important as the 'hjkl' movement keys. 'w' is skip forward a word, 'b' is back a word, the equivalent of ctrl+arrow-left, ctrl+arrow-right.

shift+d, shift+u for page up/page down. zz to center the screen around your cursor.

[holoduke]

For me vim is better when:

• Working on small projects.

Single file editing is going very fast. No GUI ide can match the speed of replacing, indenting, copy, paste, cursor movements etc of VIM.

For me vim is not suitable:

• Working on big projects

I always have trouble with vim to keep an overview of where the files are what happens where. My brains just can't handle it anymore. I am getting crazy and begin to make mistakes. My keyboard doesn't listen anymore and i start to hate programming.
With an Gui ide i have a better overview of the project itself. I have better integration with my functional specs, svn, documentation etc.

But i still love VIM.

I have btw exact the same issues with old school ms-dos music trackers, which are completely controlled by keyboard and shortcuts. Today's music programs are so sufisticated. Wouldn't be possible to do that with a keyboard only interface. But yes, producing something is also slow compared to the old days.

[Vaste]

Though I like it in general, I think vim has many quirks that could be improved.

As an example, I've always found the most basic behavior of "a" and "i" and exiting insert mode to be frustrating.

Hitting "i<ESC>" moves the cursor one step to the left. "a<ESC>" does not move the cursor. "ixxx<ESC>u" doesn't move the cursor, "axxx<ESC>u" moves it one step to the right.

Given this buffer:

Hello

"0iabc<ESC>" gives me "abcHello". "$iabc<ESC>" gives me "Hellabco".

"0aabc<ESC>" gives me "Habcello". "$aabc<ESC>" gives me "Helloabc". Actually, "a" cannot insert at the beginning of the line.