Vim: from n00b to meh | Hacker News Reader

Vim: from n00b to meh

dtsironis.net

58 pointstsironakos99 comments

I got pretty proficient at vim using basically the defaults (I added tabs to spaces and tab width to 4 spaces, and auto/smart indent in the .vimrc). These are the keys I use regularly. If you can memorize these, you can use vim proficiently:

  h/j/k/l (movement keys)
  i (insert mode)
  esc (leave current mode/go to default state)
  u (undo)
  >> / << (indent, unindent)
  dd (delete line)
  yy (copy line)
  p (paste)
  v (visual mode, used to highlight stuff)
  gg (go to beginning of file)
  G (go to end of file)
  r (replace the char under the cursor with the next char entered)
  % (jump to next paren/bracket, or if on a paren/bracket, jump to matching paren/bracket)
  w (go to next word)
  dw (delete word)
  cw (change word (deletes the word then goes into insert mode))
  A (append (goes to the end of the line and into insert mode)
  0 (go to beginning of line)
  $ (go to end of line)
  /some_word (searches for some_word, hit n to jump to the next occurrence)
  ?some_word (searches for some_word, in reverse direction)

Common commands:

  :%s/regex/replacement/g (replace regex matches with replacement)
  :q (quit)
  :q! (quit without saving)
  :w (save)
  :wq (save then quit)
  :x (save then quit)
  :set blah (turns on setting blah)
  :set noblah (turns off setting blah)

Most vim commands you can stick a number N before to execute N times.

e.g. 5d deletes 5 lines. 5y copies 5 lines. 5> indents 5 lines. 5j jumps down 5 lines. Some common command combinations:

  %v%> (jump to next bracket, go into visual mode, jump to next bracket (highlighting everything in between), then indent it all)

  ggdG (jump to top, then delete everything to the end of file, (clears a file))

  ddp (deletes a line of text and then pastes it (below where it currently it), thus this transposes two lines)

You can see how you quickly develop strings of commands you rattle off by chaining basic commands together.

EDIT (joke):

Q. How do you algorithmically generate a cryptographically strong random string?

A. Put a newbie in front of vim.

I have a scenario that I need help with in VIM: switching between 2-3 files while working on them simultaneously.

For ex: working on an HMTL+CSS+JS documents all at once. Assuming smaller screen where I can't have a vsplit screen.

How to I jump between them quickly? Buffers/tabs?

I love VIM but I haven't found a good tab/file switching solution. In Textmate tabbing was straight-forward. VIM doesn't seem well suited for tabs (especially with things like NERDTree and control-p).

To be honest, I usually just have several terminals open and I alt-` (ubuntu) between them.

I have a friend who has a sweet setup with gvim that has a lot of tab and file management tools, so you might look into gvim, but I don't use it.

I swear by tabbar[1] as well as a few bindings to make switching between buffers faster. Specifically:

map <C-n> :bn<Cr>

map <C-p> :bp<Cr>

It probably helps that I've mapped caps-lock to ctrl so using ctrl is very convenient for me.

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

If you use tabs, you can use gt and gT in normal mode to switch to the next and previous tabs, respectively.

I don't have any plugins for this stuff. I just do:

    nnoremap <Leader>b :buffers<CR>:buffer<Space>
    nnoremap <Leader>n :bn<CR>
    nnoremap <Leader>p :bp<CR>

My <Leader> is space. So "space+b" opens up my buffers, I type a few letters that match a file and Tab to autocomplete it, then press enter to open it. I also use ctrl+shift+6 to quickly switch between the 2 most recent buffers.

So I'd give that a shot. If that doesn't work for you, try just ":tabe <file>" for your three files, then ctrl+pageup, ctrl+pagedown (or gt, gT) to quickly switch between them.

Thanks this is working for me.

I just switched b/p (since I use p w/ ctrl-p as a fuzzy finder to list all files).

Tabs in vim are different to tabs in other programs. You should be using buffers. This[1] StackOverflow answer is excellent. I use a plugin[2] to view my buffers in a bar.

1: http://stackoverflow.com/a/103590/1212338

2: https://github.com/bling/vim-bufferline

For opening each file the first time:

https://github.com/kien/ctrlp.vim

For switching quickly between the 10 most recently used buffers:

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

I suggest adding this to your .vimrc (the default mapping is <Leader>lj; my leader key is the spacebar, and I find space space to be much better):

let g:LustyJugglerDefaultMappings = 0

nnoremap <silent> <Leader><Leader> :LustyJuggler<CR>

For very quickly jumping between the current buffer, and the last buffer I have a mapping:

nnoremap <leader>dd <C-^>

because <C-^> is a bit awkward; <leader>dd could be anything that's very easy to type.

So most of the time I'm alternating between two files using the <C-^> mapping. When I need to jump to a less recently used buffer I double tap <space>, opening LustyJuggler, then double tap the appropriate home row key to jump to the buffer I want. If the buffer I want isn't in the ten most recently used, I open Ctrl-P, type enough characters from the file path of the file I want to make it the first choice, then hit enter.

Vim's tabs are not the same as TextMate tabs: they are workspaces, not 1-to-1 proxies for files. Don't try to use them like in other editors, it's an exercice in futility.

You can make use of command-line completion:

    :b <Tab>

which does partial words too:

    :b js<Tab> completes with teh name of your JS file

You can make command-line completion even faster:

    set wildcharm=<C-z>
    nnoremap <leader>b :b <C-z>

You can try quick, generic, mappings:

    nnoremap <PageUp> :bnext<CR>
    nnoremap <PageDown> :bprevious<CR>

You can try more precise ones:

    nnoremap <leader>1 :b1<CR>
    nnoremap <leader>2 :b2<CR>
    nnoremap <leader>3 :b3<CR>
    ...

to mimic TextMate.

You can try listing and choosing in one move:

    nnoremap gb :buffers<CR>:b<Space>

You can try the builtin Ctrl+^:

    3<C-^> is equivalent to :b3<CR>

You can remap it if you want:

    nnoremap & <C-^>

and do:

1&

Huh. I know almost all of those key bindings in vim, because I have to use vim when I'm editing over ssh. And that brings me to about 20% efficiency compared to what I can do with a modern text editor (I don't use Sublime, but another GUI IDE -- which one doesn't matter, except that it's not Eclipse). So I guess there are different levels of "proficiency" of editor use?

On a related note: I've never understood the fixation with being able to enter numbers into vim. I almost never know the exact number of characters or lines I need to move/delete/indent/whatever, but key repeat is fast enough to "replay" or redo an action that I'm likely done with it before I would have figured out the exact number.

I like the general concept of being able to "program" an editor with strings of commands. But in practice I'm much faster with the GUI approach. As a bonus, all of the commands I need to know to edit text in a Firefox window, or in any other window in a GUI-based OS, also follow the GDI standards, so I get a base level of efficiency in whatever program I need to enter text in.

VIM is great for editing over ssh. When I have no choice. But I feel seriously handicapped having to use ONLY the basics to move around, copy, paste, and edit, when I'm used to having much more powerful functionality at my fingertips.

I guess it's also one thing to know them, and one thing to be comfortable typing them in a nonstop flow of text. My keystroke speed rarely changes from insert mode to control mode; vim commands have become an integral part of my typing process. I feel severely gimped whenever I can't use my vim controls.

As for knowing the number of lines you need to jump, either do :set number and be quick at math, or you can modify the numbers to be relative to your current line.

I took me probably a week to be able to actually get anything done in vim, and a month to prefer vim to anything else.

That being said, I know far more commands than the ones I listed. Those commands got me to my first month, though.

I think the number thing can be confusing, and it is hard to think in terms of 'delete the following 5 lines'. For those things I tend to use visual mode and highlight (still think keyboard-based selection is faster than with a mouse most times).

I also have a shortcut for a 3-way toggle using F2 - so I can either see absolute, relative or no line numbers at all. I don't use it much, but it can be handy at times.

    function! NumberToggle()
      if(g:numberstate == 0)
        set number
        let g:numberstate=1
      elseif(g:numberstate == 1)
        set relativenumber
        let g:numberstate=2
      else
        set nonumber
        set norelativenumber
        let g:numberstate=0
      endif
      set foldcolumn=0
    endfunc
    let g:numberstate=0
    nnoremap <F2> :call NumberToggle()<CR>

You can get rid of the global variable by testing the actual settings instead:

    function! NumberToggle()
        if (!&number && !&relativenumber)
            set number
            set norelativenumber
        elseif (&number && !&relativenumber)
            set relativenumber
        else
            set nonumber
            set norelativenumber
        endif
        set foldcolumn=0
    endfunc

Thanks! It was my first attempt writing a vim function, so wasn't exactly sure. This looks much better.

Numbers are useful for repeating actions in a deterministic way: I'd take 6p over Cmd+v-Cmd+v-Cmd+v-Cmd+v-Cmd+v-Cmd+v any time.

Numbers are also a good way to limit haphazard movements that have nothing to do with what you are trying to do. Do you want to "move the current line to after line 13" or do you want to "move to the first column of the current line, select to the EOL, cut, move down, down, down, down, down, down, open a new line and paste"?

    :t13<CR>

Anyway, you don't need to use {count} for everything.

Do you want to "group together all the variable declarations scattered around the current function at the top" or do you want to "move your cursor to the line of the next variable declaration, move the cursor to the first column, select to the EOL, cut, move up, up, up to the top of the function, open a new line, paste and repeat that nonsense for every variable declaration in that code block"?

    vi{               " visually select the function
    :g/var/m?funct<CR> " move every var declaration right under the function declaration

You'd be blind to not see any value in all that. Being able to do (almost) exactly what you have in mind rather than a long and awkward combination of unrelated actions is an incredible boost.

You have many "more powerful functionalities" at your fingertips. Being lazy or incredulous doesn't make Vim an overrated tool, it makes you an inefficient user.

Using Vim efficiently is a very valuable goal but it's not a goal that can be reached without a little bit of work. You won't get any benefit if you refuse to do any investment.

"Normal" editors/IDEs don't require that much learning because they don't offer much in the first place. You can become a TextMate/Sublime Text power-user in a week because there's not much to them. Becoming a Vim power-user is a life-long experience: it's your choice if you want to take that path or not.

That said, nobody (I hope) is forcing you to like it or learn it. Keep using what works for you, there's absolutely no problem with that.

The guy I was replying to claimed that one could use it "proficiently" with just those commands. I disagreed, and you didn't contradict that assertion.

> I'd take 6p over Cmd+v-Cmd+v-Cmd+v-Cmd+v-Cmd+v-Cmd+v any time.

Does Cmd+V not repeat? If so, I'll add that to the list of reasons I could never be happy on a Mac. I will happily hold down Ctrl-V for as long as I need rather than trying to think in numbers, yes, absolutely, ESPECIALLY when the number I need is some number between, say 20 and 30. Thinking in exact number of things that I'll need interferes with the (mental) registers I'm using to hold all of the code I'm thinking about. This is also true of the more complex vim commands I've seen, including the ones you've quoted.

Nice trick, though, with the "move var declarations" example you gave. Considering I tend to do the opposite (moving variable declarations to be as late as possible), that particular trick isn't something I'd need, but I see how it could be useful in general.

Thing is, if I had a similar task, I'd create a macro that would do the right thing. There's a skill to creating macros like that, of course, but really learning to use a powerful GUI editor is a life-long experience. It just happens to have a shorter and almost infinitely less painful learning curve at the beginning than vim.

The problem is that some people (such as apparently the developer I was replying to) learn the basics and never any more. That's true of users of all editors, I'm sure. But just because 95%+ of GUI editor users don't ever go beyond the basics doesn't mean that there isn't power hidden under the surface. Maybe more vim users delve deep into its power, statistically speaking. I submit that says more about the kind of person who would use vim than it does about the power of vim relative to (modern) GUI editors.

I plateaued very quickly with TextMate. I'd say after 5 months. I'm 3+ years in with Vim and I learn new things every day.

Those numbers are obviously bothering you but they are definetely not needed. Stop focusing on that. They are only one way, largely inherited from vi's ancestry, but there are so many other ways. I don't use counts much for the same reason as you (and I find that counting breaks my train of thought) but I use search and "advanced" motions a lot and quite naturally. The ability to jump to arbitrary positions in my code and directly work (without selection) on things like inner parenthesis and other text-objects have been extremely useful in my day to day work.

Once you are used to those text-objects and motions, using any other editor is a monumental pain in the ass, however advanced and modern they are.

But, as I alluded at the end of my comment, I don't mean to convince you or anyone of the superiority of Vim because I don't care: I have no interest in the success or failure of Vim. I use Vim and a couple of IDEs in my work and I'm totaly fine with you using and prefering other tools.

This one post had me learn a lot better than any fancy game or blog post about vim.

Thank you.

Anything to spread the gospel of vim.

I do suggest although you read the "Practical Vim" book, it has some real scenarios in there.

Kids to day I first hear a similar joke and the editor in question was TECO.

The ones I find most useful while coding are

    ci"
    ca)

The i and a here are "in" and "around"

So you can be anywhere inside a quote and do "change inside quotemark" and it'll delete everything inside and leave you in insert mode. "around" would delete everything inside and the quotemarks.

These can be used with other things, parentheses, square brackets (and I think some plugins extend it to html tags and the like).

Of course, you can swap out c for d, y or any of the other verbs.

Working in clojure and deleting everything inside a particular level of nested parentheses is awesome.

One nice little extra is that your cursor doesn't even have to be inside the string for the command to work.

I use Vim but I don't understand why people try to force themselves to use it. If you are comfortable with another editor, then go ahead, keep using it. Everyones treats Vim as if it's some hallowed apex of programming ability, and that eventually you have to be weaned from your inferior Sublime or Textmate usage. Sure, Vim is awesome, but the idea that you _must_ sooner or later learn it is wrong. Unless of course you really are interested in Vim for what it offers and not just for its reputation.

I've been forcing myself to use it, but not in an unhealthy way. I just picked up a side project that excited me (new subdomain blog driven by a static site generator) and decided I'd only work on it in Vim. I'm learning lots, because that's all I've got to work with. But I think it's important to consider the circumstances under which you "force" yourself to use it. If I had decided to use it for work, I calculated that I would have lost $300 this week, which is painful even if I earn back more in saved time later. I actually did that with Linux, and the initial loss of efficiency was more than offset later by a functional knowledge of a variety of really cool software packages.

Yes of course, many people that choose to learn Vim do so because they've heard how great it is from blog posts and coworkers, and are genuinely interested in it. There is also another group of people who feel compelled to learn Vim because they've heard it's the One True Editor and no other reason than that. I'm not saying tsironakos is this way, just pointing out a trend I've noticed.

In the end, the best editor is the one you can leverage the most.

If you really want to learn vim but are worried that the learning curve will impair your productivity for a few weeks at work, why not use it at home for a while on your own projects? I still think total immersion is the fastest way, but if you can't do that, then using it away from real work is better than nothing. I did it by using vim to edit everything, including long form writing and email.

After learning vim and its keyboard shortcuts I became so used to navigating and manipulating text with them that I feel severely limited without them.

However, that's the only part of vim that I miss when not using it. I regularly use other editors that have vim keybindings. For example: Sublime Text is pleasant in Vintage mode and, and I regularly use IntelliJ IDEA with the IdeaVim plugin because of its advanced IDE features for ruby and JavaScript.

except that it can run in a terminal, which is nice on remote servers or in tmux

> but the idea that you _must_ sooner or later learn it is wrong.

I think a person who is going to do anything with UNIX/Linux owes it to him or herself to learn either Vim or Emacs, if only for the occasional editing that needs to be done over a remote terminal connection. There are other editors, of course, but these are powerful ones.

You can get away with using nano these days. In fact, invoking 'visudo' on Debian-based systems does not, in fact, use vi.

I agree with you though. Basic vi usage for quick edits is part of UNIX/Linux literacy.

Personally I think that the most persuasive part of Vim is its availability on so many Linux distributions and its accessibility over the terminal. But outside of that, fast editing and typing does not seem to be a sufficiently interesting concern.

I am definitely not a seasoned or prodigious programmer, but I find that most of my time is spent on reading, understanding, or planning code. By the time I begin coding, I will already have a strong idea of where I want to go, and I spend very little time actually typing or editing. The same is true for essay writing -- by the time I pick up the metaphorical pen, I have already finished most of the essay in my head, with only trivial details to hammer out.

Therefore, why not select the metaphorical pen which you find most enjoyable? For me, I choose Vim. And sometimes Sublime Text.

I got interested in Vim for both what it offered, and its' reputation. It took a while to get used to but now I can't live without Vim controls; it's just so efficient.

It's gotten to the point where I use a tiling window manager on my Linux distro with all controls Vim style. I have a Firefox add-on to give it Vim controls [1], and I use Vim for basic word processing. I can control almost every part of my OS, excluding Skype, purely through my keyboard with virtually no mouse involvement.

It's all very addicting once you get used to it.

1: http://5digits.org/pentadactyl/

Also check out vimperator (http://www.vimperator.org/vimperator). It is updated more often and has great support.

I really want to see some measurements of the efficiency of vim. Because we [know](http://www.asktog.com/TOI/toi06KeyboardVMouse1.html) that people's perception of time taken when using keyboard shortcuts is skewed: using keyboard shortcuts makes you perceive your actions as faster, even in those cases where they are not. Thus, I hear a lot of people say good things about vim, but it is difficult to merely take their word for it, since it might very well be that they think they are faster then they are.

Vim and using the keyboard isn't about speed. It's about precision.

Also: many text editing actions can go from conscious (using a mouse) to subconscious (using the keyboard + muscle memory).

People try to force themselves to use vim (or emacs or whatever) because they're curious about it, and they find out that they have to spend some time and effort with it before they can decide whether or not it's the right editor for them. And what makes people curious about it? Most likely the reputation has something to do with it.

I agree though that there's no reason every programmer must try and learn vim; there plenty other editors out there, and if you're productive with one, there's no reason not to stick with it. Still, people want to try because they're curious, and if vim lives up to its reputation for them, well.. good for them I guess?

The thing is, for a programmer, a programmable text editor can multiply your productivity. You can leverage your programming skills to improve your programming environment. This is increadibly powerful stuff. Neo would say that it can free your mind.

Productivity is probably too generic of a word. I would say 'typing speed'.

I switched to Vim because, as I was transitioning to Linux from Mac OSX, I needed a cross-platform alternative to TextMate. After 10 months spent trying every cross-platform (Mac OS X/Linux) editor/IDE from joe, ne, or even diakonos to NetBeans and fiends, I found Vim and Emacs to be the closest to what I wanted/needed. Ultimately, the intuitiveness (yes) of Vim's language won me over and now, 3+ years after I took the plunge, I don't regret anything.

I agree, switching to Vim just because it is fashionable is a dumb move.

For the record, if ST had been available for Linux and Mac OSX at the time I was looking around, I'm 100% sure that it would have been my choice.

In the last 15 years I remember having used as my main editor: TextPad, Vim, KEdit, Textmate, Vim (again), Sublime Text. I consider myself a decent vim user, but went back to non-modal editors, they feel more comfortable to me. My muscle memory works best with "synchronous" keyboard shortcuts (ctrl-alt-shift-whatever) rather than "fluent" vim-style commands like ciw, ct" etc, that require a mental context switch.

It's important being able to use vim, because sooner or later you'll edit some files on a remote server, but I don't understand the enthusiasm of so many people for it. Vimscript is horrible BTW.

There are other editors out there. I edit files on remote servers regularly, but I've never used vim for that.

I highly don't recommend using a starter kit, and particularly Janus. Janus started out ok but quickly morphed into an amalgamated mess of crap.

The only thing I recommend is Pathogen which keeps addons modular. From there only add things to the baseline as needed.

I agree so much with this. When someone new to Vim touches it they should start out with a blank slate.

and then you start bind and learning key patterns that are sub-optimal

Agreed I experienced this VIM, emacs...and also surprisingly linux.

I tried switching to Ubuntu from OSX as many times as I tried abandoning Textmate for VIM.

The thing that made me finally keep using Linux was using a very stripped down version called "Arch Linux". This made me appreciate the basic fundamentals of the operating system, with no fluff [1].

It was rough around the edges at first but you learn how to deal with quickly.

I eventually switched to larger and easier-to-use Linux distros like Fedora/Debian. But whenever I run into problems with them, I have the experience to understand/fix it from working with Arch.

I now have no interest in going back to OSX and use VIM obsessively.

Many comedians will say this too: the only way to get motivated to be successful is with your back against the wall. Being partially comfortable makes you complacent.

[1] https://www.archlinux.org/

Yeah, Janus is very complicated but maximum-awesome is very simple, just a vimrc and some plugins.

You definitely do not want to use Janus right out of the gate, or use a copied ~/.vimrc file. Beginners who do that have no way of knowing where default vim ends and the plugins begin. If you are learning vim I think it's counterproductive to install any plugin unless you know exactly what it does first.

That means incrementally building up your array of useful plugins and not installing them all at once. You want to be very selective about plugins in general anyway, and pay attention to which ones are the most useful to programmers who get a lot done, which will make you want to try them (I'm thinking NERDTree and Ctrl-P here).

I think vundle is a lot nicer than pathogen. It supports all addons that support pathogen and makes installing and updating them much simpler. https://github.com/gmarik/vundle

I've used both Pathogen and Vundle in the past but recently I started using NeoBundle[1] and like it a lot more. I guess you could say it is a successor to Vundle. It can compile if that's required, and lazily load plugins as needed, among other things.

1: https://github.com/Shougo/neobundle.vim

this title suggests , meh, that you lost interest in vim but the article seems to state otherwise...

Try the Vimium plugin for Chrome for a bit of fun.

https://chrome.google.com/webstore/detail/vimium/dbepggeogba...

Read Practical Vim published by the Pragmatic Bookshelf. You'll go from n00b to "pretty good". Takes a long time to work your way through the text, as it's both thick and very dense, but every single page will empower you further.

I wonder what the author didn't like about sublime text's vintage (vim) mode? I have not used vim, but i have been using vintage mode for about a month now and really love it. I grab my mouse occassionally, but mostly stay out of insert mode and navigate with movement keys. Plus I still have my sublime text environment that I've built up for the past 2 years.

I don't think I could've made it this far by diving in head first. Like it or not, I have to get work done, and when I couldn't get a motion to work right or didnt know the best way to do something, I could fall back on sublimes regular tools.

When I tried the vintage mode in Sublime Text, I already had some knowledge about vim and its behavior. I find that the vintage mode was restricting me, which exactly the opposite of what it's supposed to do.

> I don't think I could've made it this far by diving in head first.

That's exactly my point! Take it easy and don't go hardcore from the first day. You'll get annoyed right away and you'll go back to Sublime Text in 10 mins.

I wouldn't recommend using a vim distribution. They have some good features but they also tend to add bloat to your vim and make it slow. They also impose a certain workflow which might not be suitable for everyone. I have been using vim full time for more than an year now, I started with an empty vimrc. Now I have about 200 lines, and I added all of them on a need basis. Text editor is the most important piece of software in my workflow (or probably any developer's workflow), so I want it to behave exactly like I want.

I would suggest not to use anyone's configuration, add config/plugin as per your need. And yes, don't forget to take a look at learnvimscriptthehardway.stevelosh.com

So many people talk about learning vim, vim philosophy, getting proficient at vim, changing your workflow so that you can use vim better. You what this sounds like? A cult.

Vim is a (surprise surprise) text editor, not a way of life. It's perfectly ok not knowing how to use vim and being put off by how awkward it feels. It's perfectly ok to use notepad++ or sublime text or whatever else you are comfortable with.

To my knowledge nobody gets paid to use vim instead of some other editor; money comes from lines of code. It does not matter that you use vim, it does not make you a smarter person or better programmer (I should know, I often use vim at my work place).

On the same note, it does not matter how cool you think you are when you manage to persuade git to do some complicated thing in a two liner command which could be achieved in svn or hg in two words, you are just being silly. Being proficient at vim/git when your job doesn't require it is like being able to rotate your left and right eyes simultaneuosly - one clockwise, the other counterclockwise. It's very funny/interesting, but utterly useless. Forcing yourself to learn vim for vim's sake or because you read on the internet how cool vim is and how 3l1t3 vim makes you is one of the things you'd be better off avoiding. Again, I should know.

Seriously, don't drink the Kool-Aid.

You probably don't understand well enough how big a difference these tools can make in your efficiency. Of course number one priority is to know the technology, nobody argues that.

In my experience, when working with anything but very small projects vim is a liability. Vim's main feature (speed of editing) is of marginal use when you only write about 10 LOC per day (as I would say is still the case 40 years after The Mythical Man Month was published, at least on average). The time when you're not writing code (which is most of the time) is used switching back and forth between files, going to declaration/definition, debugging,(auto)refactoring, changing between project configurations and so on. All this is very difficult to do with vim since it comes naked out of the box and you need to use all sorts of crutches to make is resemble a modern IDE. And when you switch another machine all you usually get is another barebones vim.

For instance, when working on a C++ code base, vim will never come close to the ease of use of Visual C++. It might be better at "delete 2 lines starting at line #256", but that's about it. This can be improved by plugins that most of the time will not do exactly what you'd like them to do, so you will have to "adjust your workflow" to work around that.

My original point was about using tools because it's cool or because the internet said so, and there's load of stories where people buy into how good vim is and then after a few months they still don't 'get it' so they are told they're doing it wrong (or just not smart enough). Ditto for git, lisp and other silver bullets.

If you ask me, if efficiency were important people would be using hg instead of git most of the time because most of the things you can do in git you can do easier/simpler in hg - at least for the most usual cases. After a short intro to hg people will keep using it happily ever after, whereas the git user will keep coming back to StackOverflow questions to find out how to hard reset to head after rebasing from origin and rewinding. Speaking of SO, this quote matches my thoughts exactly:

"It seems to me, that people using Mercurial are not so easily impressed. This is reflected in how each system do what Linus described as "the coolest merge EVER!". In Git you can merge with an unrelated repository by doing: git fetch <project-to-union-merge> GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files) cp .git/FETCH_HEAD .git/MERGE_HEAD git commit

Those commands look quite arcane to my eye. In Mercurial we do: hg pull --force <project-to-union-merge> hg merge hg commit"

I would like to read your insights related to efficiency.

Fully agree with you.

I do know VI (there was no VIM when I learned it) and Emacs. Yet I prefer to live in the cozzy world of IDEs.

Every time I read a story like this, it resembles a macho attitude of being able to develop software in a UNIX System V world environment, talk about time travel to the 70's.

When using Visual C++ I'd use ViEmu. Other IDEs have similar vim plugins of varying strength.

To put things into perspective, in terms of productivity if given a choice between Visual Studio without ViEmu or just vim I'd pick Visual Studio. Fortunately I don't have to choose.

Part of speed of editing for me is low RAM usage. When I'm doing web development, I tend to have a few browsers open (at least Firefox and Chrome), running web servers and databases, or the same in a Vagrant-managed VM.

When you've got a browser or two and a Linux VM running, finding the extra 500Mb for an IDE can be rather taxing. I've tried IntelliJ, Eclipse and NetBeans. Always end up coming back to MacVim, saving a few hundred megs of RAM and not really getting any significant hit in productivity.

I was trying out PyCharm the other day (IntelliJ's Python IDE) and it was unable to keep up with my fingers. The text was lagging a I was typing it in. What was I getting from the IDE? Debugging? I know my way around pdb, haven't got time to work out how the IDE fucks that up. File navigation? I've got Ctrl-P. Changing between project configuration? Meh. Got Vagrant for that kind of thing anyway. That leaves autocomplete (can take it or leave it. Not bothered.) and refactoring (mostly I use Python and Ruby at work, so mostly it's a shit show anyway IDE or not).

Even on Scala projects, I've gone in thinking "IDEs are the answer" and ending up back in Vim after a few hours of flailing around trying to get the IDE to talk to the compiler.

Agreed on Mercurial though. I like Git, I like Mercurial. Both have upsides and downsides. More important is that we are finally moving away from centralised VCS.

I understand where you're coming from and I concede that you might be more efficient with your current setup, but I disagree about the debugger. Pdb, gdb and any other command-line based *db-s are what people first started using a few thousand years before entering the stone age. I've used gdb extensively and I can tell you there's no substitute for a good IDE where you can see the code, variable values, stacks, threads and watches, all at the same time; it makes life so much easier. It can be done in the old fashion way but there's nothing to gain from it.

On the other hand I haven't seen any good free Python IDE-s (like Visual C++ is for C++) and you are sometimes forced to use pdb for the lack of a better option (Python Tools for VS are decent but took me a lot of time to setup properly and I didn't like the workflow). That said, the lack of good tools doesn't mean the old ones are good, only that the language lacks good tools, mostly because people get used to the stone age tools. And sadly that is the case for a lot of programming languages.

Well, JetBrains have now made PyCharm3 Community Edition, which is free and open source, and they are charging for the premium edition with support for web frameworks like Django, Flask and Pyramid.

The RAM thing still bites. When I get a new laptop in a year or so, I'm going to go all out on RAM. :)

We agree on that it's stupid to use tools because others said so. We agree on that you don't immediately need these tools if you are just starting out or write simple code, BUT I think it's very easy to reach a point (I mean you are efficient enough in the technology itself) when you feel the need for these tools. For example I'm not quite there yet, so I use SublimeText or an IDE but every time I edit a line I just hate these tools, because they feel so slow, and in that exact moment, when I won't have to look up the manuals every time, because I don't know the framework/language/technology I will switch to Vim for sure, because I think at that point when you are a pro in the technology, an IDE will get in your way. When you can crank out hundreds of lines without even blink, Vim is the way to go. Again, for beginners this is not the case. For casual coders? They probably do it for fun, so why not do cool things? I cannot comment on Mercurial vs Git, because did not use Mercurial, I only read that with Git, you can do anything you want and with Mercurial, you can do most of the things simply.

TL; DR: There is a point in your knowledge about the technology when you simply NEED these tools. Early on, you probably don't.

> All this is very difficult to do with vim since it comes naked out of the box and you need to use all sorts of crutches to make is resemble a modern IDE.

Well, that's your problem: Vim has never been, is not and will never be an IDE.

Vim is a very powerful text editor, use it as such and you'll get a neverending smile on your face.

If you need an IDE by all means drop Vim and use an IDE. If you prefer a text editor, go with a text editor.

I use Vim for HTML/CSS/JS/PHP, learning Python and as a general purpose text editor.

I also use Flash Builder for AS3 and AndroidStudio for… Android because I have somewhat bigger needs.

I use Vim because I hate mice.

I didn't know that I get free membership in the Church of Scientology base don my choice of text editor.

You don't, but you get free membership in the Church of Emacs if you switch. http://www.emacswiki.org/emacs/ChurchOfEmacs

First mistake: starting with someone else's config.

Second mistake: using a distribution.

Third mistake: forking a distribution, itself built by amateurs, after only three months and advertizing it on the net.

Seriously, when did parents stop teaching the value of patience (among other values) to their kids?

You are the one in charge of your config, people, not some random guy on the internet.

I don't understand the hoopla about editors. It takes me eight hours to write a half page of code. That half-page is well-understood, bug-free, and accomplishes the mission. The more I learn, the less I write. I don't want tools to help me write faster. I want tools to help me understand what it is I am writing.

While I agree with most of your points it does matter to me that I can do the few editing actions I do quickly otherwise it breaks my concentration of focussing on the code.

I also need to be able to navigate the code quickly but that might be part if your "tools to help me understand" remark.

> I also need to be able to navigate the code quickly but that might be part if your "tools to help me understand" remark.

It often takes me 20-30 minutes to edit a single line of code. Understanding why I need to change the program, what the effects of making that change are, determining which line of the code to edit, figuring out whether I need to edit or refactor, spending time in a REPL to test the proposed changes...

I just use the mouse.

For me, part of getting that understanding is navigating the code and I do not always have room for another window on my screens.

It seems we have different approaches to working on code, or perhaps we just use different language. The main languages I currently work in are: Common Lisp, Python, JavaScript and C++.

One of the best resources I used to build up my vim customizations was probably this video http://www.youtube.com/watch?v=xZuy4gBghho. It's got a lot of good stuff in it

I've been a Vimp too... I knew about vim for years, sometimes trying the switch, but it never stuck.

By now, it did stick. What finally convinced me the most is that a lot of really smart people not only use it but have developed a fierce loyalty to this text editor.

I want to learn Vim, but I cannot even dream to remember even the most primitive commands.

Treat learning vim like you'd treat learning a natural language. You weren't having conversations when you were two years old, but you were learning words that you'd need later when you were ready to string them into sentences. That's how vim works.

I've been using vim for 10 years and I learn new things all the time.

That's the best thing about vim... there is always more to learn. I think it might be boring otherwise

To be honest, I found that the only way to remember the commands is to commit them to muscle memory. However, this means coding enough in vim that you look things up enough for them to just stick.

Once you know how to switch between modes, it's easy to use vim as a basic text editor using the cursor keys.

At that point I wouldn't start looking things up all the time. Just set out to learn one new command or shortcut every two days, applying it in your daily use. Usually that's enough to get them in your mid-term muscle memory, so that you continue to use when you move on to the next command. The Vim pocket guide is great to choose what's up next.

I was already fairly adept at Vim when I applied this method to teach myself less frequently used Vim commands.

the best way to learn VIM is to learn the basic commands, and then make your own

The Vim Adventures games is actually pretty useful for getting use to sticking with the keyboard and laying off the mouse.

There is definitely a basic set of commands to remember, but the real power of vim is that it forms a succinct and consistent text-editing language where complex operations can very often be synthesized from what you already know about it.

For example, there are a set of commands that move the cursor in different ways (beginning of line, end of line, first line, last line, line #x, next word, previous word, etc. (that's ^/$/gg/G/g#/w/b) ), and a set of commands that performs actions (copy, cut mostly (y/d)). The real magic is how the two sets interact.

I don't have to memorize the sequence of keys to delete a word; I know the key to cut (d), and the key to move a word forward (w). I press d, then w, and the word is gone! It's a whole world of editing possibilities.

My secret shame: since I use GUI vims almost exclusively, I've never developed the muscle memory for hjkl movement; I use the arrow keys. When I started out, I knew i, esc, and that, and I figured out the rest as I needed it.

I think the real joy of vim is in the next level, when you start depending less on movement commands in favor of text objects.

or you try to finish your HN comment with :w

Yeah, vim follows you everywhere. I'm forced to edit someone's Word document and I have to erase the vim commands that I embedded in the text. Etc.

I press d, then w, and the word is gone!

There's got to be a better reason to use vim than this. I mean...the standard for every other editor is ctrl-shift-left arrow, then the delete key and the word is gone! Whoopee.

It works in most editors, even Microsoft notepad and this textarea I'm typing in right now. I use unfashionable, clumsy old eclipse most of the time and could probably list 100 important things it does that vim never could. Things that actually matter. Maybe I'm wrong, but I doubt vim can launch and debug and continuously deploy to Apache tomcat. That sort of thing.

My fingers remember the primitive command but my mind doesnt. If you ask me for a command and its function, I will not be able to answer some of it. But if I start typing on the keyboard my fingers know what to do.

It's like when I was a kid in New York. I could walk anywhere without thinking about it, but if someone asked me for directions I had no idea how to tell him to get where he wanted to go.

Yes, it's funny how our brain works. I wouldn't be able to write down passwords that I use daily. Therein lies a pitfall - once you start think about a particular password, it becomes much harder to type it in.

Is it a big switch from ST2 with vim bindings to straight vi?

Yes. Why use vi over vim?

sorry.. I meant vim not vi.

I've been using Vim for a few weeks now, and the biggest time saver is not having to use FTP or Mac Finder. I can do everything from the terminal now.

If this is a serious comment then please be advised everyone else stopped using FTP 10 years ago. For the love of god, at least use sftp, but preferably check out http://www.scribd.com/doc/120792448/CI which is the way things are going (use git before deployment, CI handles the after). If you are just getting in to terminal stuff, then try Viscosity, SourceTree, iTerm, brew and opendiff on OSX. Once comfy, do consider moving to a desktop running a source-oriented distribution of Linux instead... despite the setup hassle, it's far superior and will force you to pick up loads of useful knowledge in a slow and manageable way. Hell, we even have Steam these days!

Everyone stopped using FTP 10 years ago? Pretty general statement, one I know to be untrue because most of my non-profit clients still use FTP.

But I take your point, and on my own projects, I stick with git, grunt, and rsync. Not a fan of SourceTree, and now that I know Vim, I can use git diff to good effect.

... and one should always remap ESC. For me this was a big improvement (from an ergonomic viewpoint). My suggestion:

imap jf <ESC>

I don't understand this nostalgia with shell editors, just move on and use something like sublime text.

Reply on news.ycombinator.com