Hacker News new | past | comments | ask | show | jobs | submit login
Vim After 11 Years (statico.github.com)
405 points by statico on Feb 19, 2013 | hide | past | favorite | 239 comments

Lots of people seem to declare ; or , to be useless keys and remap them. They're two of my most used movement keys in certain circumstances.

I used to have , remapped to <leader> but switched back when I realised what I was missing out on. I'd advise anybody else to reconsider if they've made the same mistake I did.

Usually I use a method that I found on some Emacs-related website. It said to use text search for navigating around the file. That's why I use / pretty often. I use f, t, and related movements as arguments to actions.

I love using search interactive to navigate text. But however, getting the point to the right spot after that still feels cumbersome, in particular, moving to the beginning of the matched word doesn't seem easy.

No, if I remember correctly it was somewhere on http://emacswiki.org which is a great resource by the way.

I've had ; mapped to : forever.

Is there a use for `;` I'm missing out on? `;` just seems to be for stuff like "`fp` -- Oh wait, I didn't see all the p's between my cursor and the p I wanted. ; ; ; ;."

Now I use easymotion.vim which obviates that scenario.

I created vim-seek exactly for this reason, it's like f but takes always two characters, way faster than easymotion within the line (though I still use easymotion for longer distances) http://github.com/goldfeld/vim-seek

Cool! Until I found easymotion.vim, I was sort of doing a poor man's vim-seek with `/` and two chars.

For me it's often fp <something> ;. ;. ;. ;.

For example if I have a longer line I would like I could do something like f,a<cr><esc>k,.k,.k,.k,.k,.k,.

g; will move the cursor to the line of your last edit (and further through your edit history). I find it useful as a move command but also use it to remind myself of what and where my last edit was.

I have the spacebar as my <leader>: doesn't clobber a useful mapping and much easier to hit than '\'.

On a related note, I think that f and t become ever more awesome if you use fanfingtastic: https://github.com/dahu/vim-fanfingtastic

I use \ for <leader>, doesn't seem to clash with anything I do on a regular basis (but I'm not a power user by any means)

It doesn't clash with anything at all, as it is the default <leader>.

Ah, I had no idea. I saw it explicitly defined in someone's vimrc and thought, hey that's a good key to use.

I use ; quite a lot after "f"orward, but I rarely use ,. Just doesn't come up much in every-day work.

What is the default behavior for ","?

It's ";" in reverse, i.e repeat the latest f,F,t or T backwards.

PG is there a way to have HN present the subdomain for github submissions?

Yes, this has been a bit of annoyance for me too.

I'm using http://userscripts.org/scripts/review/121512, works very well.

Doesn't work in chrome :/

"Apps, extensions, and user scripts cannot be added from this website"

You can make it work in Chrome; there’s a way around the warning. Instructions are in “Steps on adding extensions from other websites” on the Chrome help page linked from that warning: http://support.google.com/chrome_webstore/bin/answer.py?hl=e.... In short, to add the user script, open Tools > Extensions, then drag and drop your downloaded 121512.user.js file into the Extensions tab.

Some small vim tweaks I've recently been using myself that I find very nice:

nmap <CR> :write<CR>

cabbrev w nope

Re-map enter to save the file. If you try to do a :w it will yell at you until you take out the cabbrev so you can retrain your muscle memory. Took me about a day to retrain.

let g:EasyMotion_leader_key = ';'

nmap s ;w

nmap S ;b

Remap s and S to be easymotion forward and backward. I never use s, since it's largely a redundant command, and didn't like having to do a two key command for easymotion. (You can set the leader key to whatever here, the nmap's are the important part.)

noremap <C-H> <C-W>h

noremap <C-L> <C-W>l

noremap <C-J> <C-W>j

noremap <C-K> <C-W>k

Move between panes with motion keys with control held down.

Also the YouCompleteMe plugin got some HN airtime but it really needs to get more. It's amazing.


And as others have mentioned using vim inside of tmux is very nice. It's especially helpful to remap the entire tmux keymap to be vim-like.

Also, does anyone have any suggestions for what to re-map Space to? I am amazed Enter and Space in command mode both do relatively useless things. Remapping space to page down is OK but I use ctrl-f/b which is just as fast imho.

I use space as my easymotion leader key. So <space>-w goes forward by word, <space>down does easymotion down, etc.

I used to use space as my "clear all searches and clear the echo-line" command, but decided space is too big and easymotion is too good to not pair them. I now use <leader><leader> to do the all-clear command.

I use space for toggling folding:

  " space toggles the fold state under the cursor.
  nnoremap <silent><space> :exe 'normal! za'.(foldlevel('.')?'':'l')<cr>
  " <leader>space expands with zO
  map <leader><space> zO

same here, but use

   nnoremap <Space> za   
   vnoremap <Space> za
also, for folding in general I'd recommend using

  set foldmethod=marker
which has the benefit of making folds more 'transparent' in your code, and also persistent across vim sessions

Space is my leader key.

Same, and return is my BufExplorer. Lightning fast.



YouCompleteMe claims to work with omnifunc-based completion engine, but I couldn't get that to work. Can't tell if it's YCM or foreplay that's dropping the ball, but they don't seem to work together (i.e. I get foreplay completions when I trigger omni completion, but not dynamically via YCM).

EDIT: disregard me, it was a stupid configuration error (both plugins mapped the same key for completion, and foreplay won)

I have space mapped to execute the macro in 'q':

  noremap <Space> @q
This lets me set a macro by first wacking qq, then q to finish, and then replay it by wacking space. I find myself using quick throw-away macros that only have a use for maybe 10 seconds far more often with this setup. (Plus wailing on the spacebar to get work done can be really satisfying ;)

This ain't bad but you know you can re-execute last macro with @@? So it ends up being @q and then hold down the @ key to repeat.

Yeah, that's how I use macros that I anticipate remaining useful longer.

Why do people keep suggesting iTerm2? The built-in terminal app on the Mac does Unicode and 256 colors just fine.

Historical. Terminal has improved greatly since Leopard/SL

Split panes is pretty much the main reason I need iTerm2. That, combined with system-wide hotkey toggling (which I used to get on Terminal with Visor), and Send Commands to All Sessions mode (cmd-ctrl-i, I think) makes me a happy command liner.

It's the little things which makes me use iTerm2

- easier to change the default darkblue to be readable on black - can configure double-click on filename behaviour (cmd+alt click in Terminal) - can have auto-copy-to-clipboard on selection

In short, it's more like terminal applications on other OSes I'm familiar with.

iTerm2 has few other fancy features, like horizontal and vertical splitting or Guake-like top-down terminal [0].

[0] http://ivanvillareal.com/osx/setup-iterm2-to-behave-like-gua...

I've used visor/simbl in leopard and snow leopard for years to get the top-down effect in terminal: http://visor.binaryage.com/

Multi-pane input via cmd-shift-i, and saved pane/window configurations through cmd-shift-s and cmd-shift-r also come in handy.

I personally enjoy being able to split panes vertically with iTerm2

Indeed. iTerm2 has replaced tmux for me for local development.

Why not both? http://code.google.com/p/iterm2/wiki/TmuxIntegration

iTerm2 can intelligently communicate with tmux in order to present splits and windows are handled by iTerm2, rather than within the single terminal window.

iTerm2 has an absolutely amazing history playback, amongst other nice features.

Am I the only one who doesn't like iTerm 2 because it feels slow to use? Example: Open up a file in vim, then scroll up and down quickly. The refresh on iTerm 2 is noticeably sluggish compared to Terminal.app.

The "step back in time" feature is sort of gimmicky, but does mean you can rewind even Curses terminal applications. Rarely actually useful, but it has saved me a huge amount of hassle a few times.

Vim also has history via the undo-branches feature. e.g. ":earlier 15m" to go back 15 minutes.

And the Gundo plugin extends that even more with a history graph and preview pane that shows diffs. A must-have plugin for me.

iterm2 supports mouse input, terminal.app does not.

Using a mouse? In Vim?

Absolutely. I use a mouse in vim to resize windows. Much less tedious than doing that with a keyboard.

Good mouse support in a terminal is also nice for elinks, which several of my vim shortcuts trigger (company wide code/wiki searches, or similar).

Vim sure, more for tmux for me to be honest. Its quicker to resize panes/select things with the mouse at times.

People that take keyboard only to the extreme strike me as adhering to the letter of the law rather than the intent. Whichever works faster for a person is better.

Yes, vim in terminal works really good with a mouse!

In terminal.

Why for?

Here are few things how I use it:

- scrolling with a mouse wheel

- selecting/resizing a split window

- jumping to a specific place in the code

- making a selection

I think the key is having the option to use the mouse, in addition to normal Vim keyboard shortcuts. If I'm switching back and forth between Vim and a browser, for instance, I have my right hand on the mouse already, and I can scroll with the wheel, select a tmux pane, copy and paste things, etc. very easily. If I didn't have that option, I'd have to switch back to the keyboard. If I have both hands on the keyboard already, I'm probably not going to use the mouse.

All of that can be done much more efficiently without the mouse:

- scrolling with a mouse wheel

    :h scroll.txt
- selecting/resizing a split window

    :h window-resize
    :h window-move-cursor
- jumping to a specific place in the code

or the myriad of cool things in

    :h motion.txt
- making a selection


> All of that can be done much more efficiently without the mouse:

Surely we don't need to get into this sort of thing here.

If you don't know how to do it without the mouse, then it's more efficient to do it with the mouse. If you don't remember how to do it without the mouse, then it's more efficient to do it with the mouse. If you just like using the mouse better, then ….

Anyway, and perhaps more importantly, it doesn't hurt any of us if anyone else values ease of use (even if it's illusory or temporary!) over efficiency.

It doesn't hurt these "anyone" to be pointed at better ways to do what they do.

There is no "better", young padawan.

Yes, there is. "Best" is a harder subject to tackle, but there's always "better".

di{ is obviously both quicker and more precise than reaching to the mouse, pointing at the beginning of the code block, extending the selection until the end of the code block and hitting backspace.

One may think these keybindings are awkward or hard to remember (I did, at first, they are not) but they are both faster, more efficient and more deterministic by nature. But I may be a control freak. :-)

It's a subjective experience. I, too, prefer to use the keyboard as much as possible but I've also encountered doofuses that mock that position because the mouse is "so convenient" and "there's no way it's faster to use the keyboard entirely". So I guess their better is different from my better.

Good luck beaming your vim registers from a remote vim into the local clipboard.

That's why I prefer to use my local Vim (Emacs with evil-mode) and its remote editing features (Tramp).

>All of that can be done much more efficiently without the mouse

No. All this can be made with an extra cognitive overload provided by the use of keyboard shortcuts that makes you think you're doing something useful and/or faster than with the mouse.

Especially if you don't need to have your hand at the keyboard at all times (i.e you're just browsing code and not writing), scrolling with the mouse is way faster.

Keyboard shortcuts give me precision and efficiency, not speed, and that cognitive overload you talk about is a small price to pay.

For you. But you don't get to make that decision for everyone else. Stop trying to impose your value system on others. It's clear you don't like using a mouse. Then don't. Keep using a 1970s keyboard if it suits you. Bon a petite.

Yes, openly criticizing someone's opinion (or in this case, simply stating another opinion) on a public forum is exactly the same as trying to impose my value system on that person.

By the way, you totally missed the "me" in

> Keyboard shortcuts give me precision and efficiency, not speed, and that cognitive overload you talk about is a small price to pay.

which quite clearly means that this is a subjective matter.

Thanks for helping policing the internet: we clearly don't need to debate about anything.

I agree on most points, but there is no way that wacking Ctrl-W +/-/>/< is more pleasant than just moving either your index finger or your thumb a half an inch to use a trackpoint or trackpad and instantly get the window proportions you want.

You can of course make nicer mappings, but even then it isn't as nice.

All these commands take a count:

But I tend to keep windows at equal width anyway.

I don't count columns, I resize to taste.

I also resize often, particularly when using vimdiff, because I often use smaller screens (either because I am watching other things in tmux panes at the same time, or because I am working on my eeepc).


  "narrower window
  map - <C-W><
  "wider window
  map + <C-W>>
  "shorter window
  map _ <C-W>-
  "taller window
  map = <C-W>+

You seem to be conflating Vim and Terminal.

Vim is just one of the many things you can run in a terminal, and just one of the many things you can do with a terminal.

No. I know what the difference is between the two.

And I know that I never use mouse in one or the other. I don't use it for scrolling, I don't use it for pointing and clicking, I don't use for selecting stuff…

REPL? no use for the mouse. htop? no use for the mouse. git/svn/hg? no use for the mouse.

How do you select text then? I'm sure there are ways, but they are certainly not intuitive and I've never bothered to look them up since I don't do this task as often.

Do you mean "select text from whatever is displayed in the terminal" or "select text in Vim"?

I never select or copy anything from the terminal: pbcopy on the Mac OS X and xclip on Linux are what I use to get stuff from the shell into the system clipboard.

I don't think that's what you ask, but in Vim, visual selection is done by hitting v (character-wise), V (line-wise) and Ctrl-v (block-wise) followed by a motion or a text-object: va{, vit and so on.

Yes, I asked about terminal (this whole subthread was about mouse use in terminal). Thanks.

iterm2 does not let me go forward/backward by word (with the option key). anyone know how to fix this?

This can be fixed by editing the keybindings for your shell. Bash by default on OS X? If so Google for ".inputrc", mine looks like this:

  # See http://www.reddit.com/r/commandline/comments/kbeoe/you_can_make_readline_and_bash_much_more_user/
  "\eOd": backward-word
  "\e[5D": backward-word  # for OS X
  "\eOc": forward-word
  "\e[5C": forward-word   # for OS X
  "\C-f": reverse-search-history
  "\C-F": reverse-search-history  # for OS X
  #Control-F: reverse-search-history
  #Control-j: menu-complete
  #Control-k: menu-complete-backward
  set bell-style none
  set completion-ignore-case on
  set completion-prefix-display-length 2
  set show-all-if-ambiguous on
  set show-all-if-unmodified on

I might as well answer seeing as I found this out yesterday. Go to the profile options then the keys tab. Then there is an option for left/right option key acting as normal meta or +esc. While meta sounds correct for this, esc+ was recommended and works.

Yep, and xterm is also aware of them...

I recently switched to Vundle from Pathogen and it is a joy to use. Best part: you can bootstrap[1] Vundle from your .vimrc, turning the two-part "vimrc & plugins" configuration into a one-part "vimrc" configuration.


I have a similar, yet different approach.

My approach also works even if git doesn't exist (by skipping vundler).

I need this since sometimes I work on systems that don't have every bell-and-whistle I could want.


Thanks! This was always a pain, figured there must be an easy way to setup a fresh dotfile pull.

No you can't, you still need to have vundle installed.

Nope, I've done it quite a few times--you can bootstrap it from your vimrc like so:

  if !isdirectory(expand(root, 1).'/vundle')
    exec '!git clone '.src.' '.shellescape(root, 1).'/vundle'


I'm not sure why the author advocates job control (ie ctrl-z/fg/bg) instead of using tmux/screen. A multiplexer offers far more flexibility, and most importantly does not lose state even if your session ends (eg ssh connection drops).

While that's true, clipboard interaction through tmux is awful.

I didn't mean for them to come across as mutually exclusive. The ^Z/fg approach is great for keeping context: Go to a directory, run something, edit something, suspend editing to run something else, resume editing, finish back at the command prompt.

With tmux I'd need to create a new pane, navigate to the same directory, and reinitialize any environment stuff like virtualenv.

Use both! :)

nohup master race.

Just kidding, tmux for life.

> Emacs has a useful mode which highlights hexidecimal colors in CSS and SASS with the color represented by the text.


> The biggest hole, however, is the lack of refactoring and smart completion.


> http://www.vim.org/scripts/script.php?script_id=2937

This one doesn't need gVim, with rgb() and rgba() support https://github.com/ap/vim-css-color

For Python, there is a choice of the jedi library or the rope library to do refactoring and smart completion. This in addition to ctags and the like. I imagine other languages have similar things.

Jedi is pretty good actually. Initially it would sometimes be slow and mess up buffers, but that didn't happen for a long time.

Smart completion is fine to me, but the refactoring is a potential problems. It seems there isn't an open source refactoring tools as good as PyCharm for python.

Is there a nice sublime plugin for this perhaps? A very excellent idea.


Thanks for the CSS script link!

I would suggest using the https://github.com/ap/vim-css-color instead.

My single greatest tip to make vim even more amazing is to run it in a tmux session: It makes it super easy to split panes and create new windows for related things you need to do (git stuff, compilation, running tests, running a REPL, etc.)

For anyone using tmux and vim, I recommend having a look at vimux (https://github.com/benmills/vimux). It lets you control your tmux pane from within vim.

I use two tmux windows, one of each of my screens. One is code and the other runs `make && ./test blah blah` whenever I hit F5 in vim. To get vimux to use windows (as opposed to just panes) there's a fork under pull requests (disclaimer: I wrote it).

You can easily split panes (called windows in vim) within vim. You can also create new tabs within vim for related things you need to do.

I still use tmux or screen to do other things which aren't convenient or elegant to do within vim, but splitting windows and creating tabs can be done just fine within vim itself (or, in my case, within gvim, which I prefer due to the increased color gamut and keybinding abilities over terminal vim).

His/her point is to use tmux for splitting the editor and terminal windows, because vim sucks at subshells.

When I said split panes in tmux, I meant to put shells, repls, or servers. I also use split panes and tabs within vim for extra buffers.

you should take a look at https://github.com/jpalardy/vim-slime , very handy for sending code from vim sessions to other tmux panes

This is my setup as well. I open two terminal windows: the one on the left is used for "control" stuff, and the one on the right is for code. Then in each terminal I run tmux. For a Rails project, I have separate tmux windows for models, controllers, views, stylesheets, a psql prompt, etc. I've done it long enough that I know which window has which stuff, and each vim session only has a few files open, so it's easy to `:ls` and `:e #3` around. My scripts to launch tmux look like this:

    # ~/bin/ss-ctrl
    cd ~/src/${long_name}/site && \
    tmux new-session -d -s ${short_name}-${env_name} && \
    tmux rename-window -t ${short_name}-${env_name}:1 git && \
    tmux new-window -t ${short_name}-${env_name}:2 -n log 'RAILS_ENV=development rails s -p 3009; bash -i' && \
    tmux new-window -t ${short_name}-${env_name}:3 -n db 'ssdb; bash -i ' && \
    tmux new-window -t ${short_name}-${env_name}:4 -n misc && \
    tmux new-window -t ${short_name}-${env_name}:5 -n redis 'cd ~/src/redis-2.6.0-rc8/src && ./redis-server && date && bash -i' && \
    tmux new-window -t ${short_name}-${env_name}:6 -n sidekiq 'RAILS_ENV=development bundle exec sidekiq | tee log/sidekiq.log; date; bash -i' && \
    tmux select-window -t ${short_name}-${env_name}:1 && \
    tmux -2 attach-session -t ${short_name}-${env_name}

    # ~/bin/ss-code
    cd ~/src/${long_name}/site/app/models && \
    tmux new-session -d -s ${short_name}-${env_name} && \
    tmux rename-window -t ${short_name}-${env_name}:1 models 
    cd ~/src/${long_name}/site/app/controllers && \
    tmux new-window -t ${short_name}-${env_name}:2 -n controllers

    cd ~/src/${long_name}/site/app/views && \
    tmux new-window -t ${short_name}-${env_name}:3 -n views
    cd ~/src/${long_name}/site/app/assets/stylesheets && \
    tmux new-window -t ${short_name}-${env_name}:4 -n css
    cd ~/src/${long_name}/site/app/assets/javascripts && \
    tmux new-window -t ${short_name}-${env_name}:5 -n js
    cd ~/src/${long_name}/site/app/workers && \
    tmux new-window -t ${short_name}-${env_name}:6 -n workers
    tmux select-window -t ${short_name}-${env_name}:1 && \
    tmux -2 attach-session -t ${short_name}-${env_name}

Personally I have a mapping <leader>x that starts a terminal emulator when running under X or drops to the shell otherwise. When I work on a project I cd into its directory. Executing commands is just a matter of hitting <leader>x, doing what's necessary, and closing the terminal.

tmux is fantastic, especially for remote development. However, you can't change a single pane's font size, nor is it easy to select an entire line of text using the mouse (with vertical panes). Thus I suggest iTerm2 for local development if on a Mac.

If you haven't tried multiple panes with multiple font sizes — e.g., smaller font for logs/compiling/long-running, bigger for editing — then that's a world I don't want to live in. (j/k ;)

i use terminator for that. works wonderfully.


The author mentioned CtrlP for fuzzy filename matching. Its great because it's in pure Vimscript, but in my experience it becomes unusably slow for moderately sized projects. A month or two ago, I switched back to CommandT (requires Vim to be compiled with Ruby support, engine written in C) and haven't thought twice about it since then.

I have a repo with 3000+ files and I can't notice any delay searching with CtrlP. I have the following custom file listing command in my vimrc:

    let g:ctrlp_user_command = {
      \ 'types': {
        \ 1: ['.git/', 'cd %s && git ls-files'],
        \ 2: ['.hg/', 'hg --cwd %s locate -I .'],
        \ },
      \ 'fallback': 'find %s -type f'
      \ }

Just made my CtrlP use ag[1], it's awesome now :-)

let g:ctrlp_user_command = 'ag --nogroup --nobreak --noheading --nocolor -g "" %s '

[1] https://github.com/ggreer/the_silver_searcher

It's fine with many files, the only issue is when it indexes, which can't easily be automated. I just checked and it gets through about 2000 files a second on my MBP.

I've been meaning to try out matcher[0] for usage with CtrlP, I'm not sure how well it works but it's written in C and is purported to speed up search. Not sure if it's still being maintained, however...

[0] https://github.com/burke/matcher

It works quite well. The only negative I've found is that using matcher seems to disable CtrlP's usual highlighting of which letters in a search result are matched.

In the end, though, I went back to Command-T.

There's not much to maintain. I ported the matcher from Command-T out of its ruby-C wrapper, and it more or less just works. I use it dozens or hundreds of times a day.

I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either.

I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke.

[0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project.

[1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.

I use CommandT primarily on my main machine but I also have CtrlP installed and they are both mapped to the same key (<leader>f) in a conditional. If I'm on a machine that has Vim compiled with Ruby, I get CommandT, otherwise CtrlP. Best of both worlds.

You won't see the 'indexing' as much if you keep indexes between runs of vim:

let g:ctrlp_clear_cache_on_exit=0

How large is "moderately sized" ?

One of Vim’s strengths is that it starts lightning fast, so starting Vim from the terminal is trivial. With a modern, 256-color terminal like iTerm2 or Gnome Terminal, it will even look like gVim. But the best part is that you can drop into the command line at any time with Ctrl-Z, which suspends Vim, and your working directory is where you left off.

Is there any reason to do this instead of !sh within Vim to drop into a shell?

You end up creating a new session each time when you do !sh. backgrounding Vim lets you use the same shell instance.

The other issue I have in general with the ! form is that some applications mess up osx vim. For example, try dropping into a node session (!node) and then quitting.

You can do `:sh` instead of `:!sh`.

Ctrl+z suspends Vim so that you are back to where you were when you started Vim.

:sh starts a new shell in Vim's current directory.

Both options have their use.

have your terminal map Ctrl-Z to fg, and you can cycle in and out of the shell almost instantly from vim with that key.

How can you do that? For me, this just doesn't work...

  bind '"\C-z":"fg\n"'
  bind -x '"\C-z":"fg"'
  echo 'Control-z: "fg\n"' >> ~/.inputrc
If I replace "z" with "a", it works.

C-z works otherwise, e.g. C-v C-z prints ^Z in shell, and C-z suspends programs (e.g. vim). Is it a bash thing or a terminal thing (I'm using iTerm2)?


  set bind-tty-special-chars Off
in your .inputrc, before you do the bind on C-z.

The readline man page is a little misleading:

  bind-tty-special-chars (On)
    If set to On, readline attempts to bind the control characters treated 
    specially by the kernel's terminal driver to their readline equivalents.
Disabling it doesn't actually stop readline from binding those control characters. It just enables you to override those default readline binds. If the variable is set to On (the default), that's not possible.

This does not work for me, unfortunately...

Also, another thing I have noticed, is that I cannot catch the SIGTSTP (Control-Z) signal with the `trap` command. I can catch other standard signals, e.g. SIGINT (Control-C), but not SIGTSTP (along with SIGSTOP and SIGKILL, obviously).

As in Ctrl-z to background, and Ctrl-Z to fg back into vim from the shell?

I'm sure they mean `map fg <c-z>` in Vim so that `fg` from Vim lines up with `fg` from shell and you can repeat the same stroke to easily "toggle" Vim.


:!sh will work, but it puts you in an entirely new context (environment and CWD). :sh is just plain awful and doesn't emulate anything correctly.

I recommended ^Z/fg/bg because it's the fastest, easiest way to get to a good, functional shell if you're not using a multiplexer (tmux/iTerm2). If you map ^Z in your shell to "fg\n" then switching is lightning fast.

IIRC, !sh starts a new shell- so it depends on your context I suppose.

I think this is the explanation, I usually only find myself wanting to temporarily "stop" Vim and do something on the shell for quick one-off commands that are fine in a subshell - not to keep a backgrounded Vim instance around for longer than that. The blog author seems to have a different use in mind.

That's pretty much it. See above comments regarding context.

I can live without Vim but cannot without Vim mode.

All apps I have used since learning Vim has some kind of Vim bindings - Visual Studio, Eclipse, PyCharm and ST2. I also rely on browser vim plugins (vimium, vimperator).

It seems Vim mode is becoming ubiquitous in my apps.

Can vim do the following?

I'm editing some project with 10000 C++ files.

There is some C++ file I currently don't have open, say "palette.cpp" which is in a subdirectory "project/graphics/algorithms/color/".

Now I want to open palette.cpp without ever having to type, not even with tab autocompletion, that path.

IntelliJ (which I do use for C++ ;)) can do this easily: just press CTRL+R, then palette.cpp, ENTER, and there you are in that file.

Another thing: Some IDE's and editors have this feature where if you change lines, it marks it with some color on the left, as well as colors in the scrollbar, to immediately see which parts of the file were changed compared to git and/or the last time you opened it. Can Vim do this?


The CtrlP plugin will make opening these files a breeze. If you just trigger it and type palette.cpp, it should be the first match.

Better, you can type palete.cpp and it should still be the first match.

with your cursor on a filename that is a legitimate relative path, you can just press 'gf' to open the file from command mode. there is also a mirrored command of '^xf' in insert mode. slightly different work flow...

^o and ^i get used a lot in conjunction with 'gf', and are also pretty handy in general.

1. It is done like this:

    :e **/palette.cpp<CR>
2. You can try http://www.vim.org/scripts/script.php?script_id=3052 but I'm positive there are other implementations.

It seems "find" will do you what you need. Source: http://stackoverflow.com/a/3407288

Not sure if this helps but FuzzyFinder: http://www.vim.org/scripts/script.php?script_id=1984

Source: http://stackoverflow.com/a/573097

CtrlP takes care of that. Ctrl+P and then Ctrl+F (cycle to buffers list—you can also map this to anything you want) and it will list buffers with a + next to the buffers with local edits. Ctrl+D and it will change from full path to file name search. You can cycle between buffers, files, mru files and even more (tags, etc.) with extensions.

I've mapped Ctrl+T to open CtrlP in tag mode.

I do a large amount of my developing in vimdiff which, coupled with version control, does what you ask.

> Some IDE's and editors have this feature where if you change lines, it marks it with some color on the left, as well as colors in the scrollbar, to immediately see which parts of the file were changed compared to git and/or the last time you opened it.

This does that: https://github.com/airblade/vim-gitgutter

Most of the things of such kind are available as vim plugins (for the 'open file without path' thing, see e.g. http://www.vim.org/scripts/script.php?script_id=858) - you can then remap those new commands to keys/shortcuts.

> if you change lines, it marks it with some color on the left

This is the feature that I miss the most in Vim, after working 5+ years in IDEs like Visual Studio. There are some Vim plugins addressing this (at least a year or so ago, when I searched), but nothing as elegant and seamless as in IDEs.

re: git changes, after seeing such a plugin for sublime (https://github.com/jisaacks/GitGutter) I went ahead and implemented the same thing for Vim (https://bitbucket.org/sirpengi/iwilldiffer). The plugin is still in beta status yet with compatibility, and I should make it easier to install with the various plugin managers as well as make the feature async (right now, the UI blocks waiting on the diff command). But otherwise, I'm using it daily and it supports mercurial as well as git.

> IntelliJ (which I do use for C++ ;))

If I may ask, how do you use it? The C/C++ plugin was unusable, last time I tried it.

The C++ plugin is totally unusable and I uninstalled it immediately after trying.

But I just made a manual set of syntax highlighting rules for C++, and that's good enough for me.

The git integration and other IntelliJ features make up for the missing C++ navigation and refactoring features for me.

I do everything related to compiling, debugging, and stuff (as well as all git committing and stuff, the IntelliJ git integration is about showing changed lines) from a terminal.

I have vim as my EDITOR, then cscope does this and more.


Every time I read an article like this, it's how a power user installs an array of plugins and customizations to really soup up Vim, which to me kind of misses the point. If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever.

I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment). I've tried this with Vim and it's surprisingly nice [0]. You have to read the code more closely, and think more carefully about what's on screen, and this has the effect of focussing me more. Simplifying my environment, making it more sparse, but always having the power of Vim available, makes for a really potent, semi-distraction-free environment.

[0] Well, mostly. I leave it on in order to have three colors used: a good contrast color for code, a second contrast color for strings, and a third, very low-contrast color for comments and line numbers so that, if I want to see those things, I can look for/at them, but if I don't, they're easy to ignore. Likewise, visually distinguishing between strings and code continues to be really useful.

Customizing your editor to do what you want doesn't miss the point. It is the point. If my editor does exactly what I want, I have no need of Coda or Sublime Text 2 or Eclipse or whatever.

You can turn off colors. That's your customization because you like it. Good. Other people want other customizations.

"If you want that level whiz-bang, use Coda or Sublime Text 2 or Eclipse or whatever. I don't recall where I saw this, but someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment)."

Perhaps you might enjoy using ed...

  From: patl@athena.mit.edu (Patrick J. LoPresti)
  Sender: news@athena.mit.edu (News system)
  Subject: The True Path (long)
  Date: 11 Jul 91 03:17:31 GMT
  Newsgroups: alt.religion.emacs,alt.slack
  When I log into my Xenix system with my 110 baud teletype, both vi
  *and* Emacs are just too damn slow.  They print useless messages like,
  'C-h for help' and '"foo" File is read only'.  So I use the editor
  that doesn't waste my VALUABLE time.
  Ed, man!  !man ed
  ED(1)               UNIX Programmer's Manual                ED(1)
       ed - text editor
       ed [ - ] [ -x ] [ name ]
       Ed is the standard text editor.
  Computer Scientists love ed, not just because it comes first
  alphabetically, but because it's the standard.  Everyone else loves ed
  because it's ED!
  "Ed is the standard text editor."
  And ed doesn't waste space on my Timex Sinclair.  Just look:
  -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
  -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
  -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs
  Of course, on the system *I* administrate, vi is symlinked to ed.
  Emacs has been replaced by a shell script which 1) Generates a syslog
  message at level LOG_EMERG; 2) reduces the user's disk quota by 100K;
  and 3) RUNS ED!!!!!!
  "Ed is the standard text editor."
  Let's look at a typical novice's session with the mighty ed:
  golem> ed
  eat flaming death
  Note the consistent user interface and error reportage.  Ed is
  generous enough to flag errors, yet prudent enough not to overwhelm
  the novice with verbosity.
  "Ed is the standard text editor."
  Ed, the greatest WYGIWYG editor of all.
  When I use an editor, I don't want eight extra KILOBYTES of worthless
  help screens and cursor positioning code!  I just want an EDitor!!
  Not a "viitor".  Not a "emacsitor".  Those aren't even WORDS!!!! ED!
  When IBM, in its ever-present omnipotence, needed to base their
  "edlin" on a UNIX standard, did they mimic vi?  No.  Emacs?  Surely
  you jest.  They chose the most karmic editor of all.  The standard.
  Ed is for those who can *remember* what they are working on.  If you
  are an idiot, you should use Emacs.  If you are an Emacs, you should
  not be vi.  If you use ED, you are on THE PATH TO REDEMPTION.  THE

This made me remember http://xkcd.com/378/

I actually had to go look at the real man page to make sure.

That's awesome.

... and it's from the Emacs distribution ($EMACS_SRC/etc/JOKES)... :]

He said he tried using Eclipse, and his Vim setup was more productive. Apparently that means that Vim can not only beat Eclipse at being a sparse minimalistic editor, but also at being a whiz-bang IDE.

In short, according to the OP, if you want that level whiz-bang, you should switch from Eclipse (and presumably Coda or Sublime Text 2) to Vim.

A lot of us do development on remote servers. Using vim in a terminal on the server is a heck of a lot snappier than a local editor over a remote connection. Also makes reconnecting your dev environment as easy as tmux a -d and allows me to do so from multiple machines.

It is 2013, why are you doing "development" on a remote server? Is remote debugging now not a thing?

That can happen when the dev environment is too complex / heavy to setup on a local machine.

someone advised disabling syntax coloring in your editor to remove a crutch (and, secondarily, to visually simplify your environment) ... You have to read the code more closely, and think more carefully about what's on screen

I don't want to have to think more carefully about things that don't matter like syntax. Highlighting gives you visual clues so you can get meaning from code more quickly and get on with it, instead of having to read everything carefully.

Plus: pretty colors.

It is funny, I use vim pretty much everyday for a decade. I install vim, I use "write", "close", "quit". I semi pretty vimrc file with line numbers and syntax highlighting.

I am still not very good at opening multiple buffers, I just close vim and open the other file.

But that is about it. I felt I have doing it wrong. But I can get work done and it is easier everytime I install a new server.

How did you configure vim to use only three colors? Did you create your own colorscheme or is there another way to do it?

Wow. I wish I had this exact setup. I have never been good at configuring Vim and the SPF-13 VIM distro is wonky.

Would save me from buying Sublime

Try using Vundle to add one plugin at a time!

Good idea. Thanks for the idea.

In Star Trek the next generation; as different users interacted with different physical platforms (tablets, desk consoles, wall panels, tablets, voice activated devices, "desktops", etc), the work space would adapt to it's physical medium....so....I'm sold!

My new favorite toy: http://gh.codehum.com/nosami/Omnisharp/

It's 'real' intellisense for Vim/C#. It's fairly new and rough around the edges, but works great once you get it going.

I've been looking for something like this for months. I've also never heard of easymotion or YouCompleteMe. How is it that I've been out of the loop for all these things ??

I'd love something like this for java...

Thanks for this!

netrw comes by default. No need to install NERDTree.

I was just typing out an email to the author of netrw regarding a problem I was experiencing.

Maybe someone here could help me out.


- Lubuntu 12.10 64,

- LXterminal as well as UXTerm,

- GVim/Vim 7.3.547,

- both passive and active ftp,

- a local ftp server and http://secureftp-test.com/ to test it.

When I try to access a remote ftp directory, I can only open the directory that I typed in a path to. As soon as I navigate through the listed directories and hit enter on any, the screen splits into two horizontal panes and the top pane reads "File not found".

I tried this from Windows 7 Gvim/Vim (don't have the version handy but it was 7.3+) and it worked as expected.

From what I gather it just doesn't seem to look for the right directory after I hit enter in the list I think. Maybe it skips an extra forward slash somewhere or something?

I understand we're not really on the netrw/vim mailing list but any response would be appreciated!

I've recently uninstalled NERDTree in favor of netrw and I've been presently surprised at how little I miss NERDTree and how much more productive I am on default vim installations.

I used NERDTree when I was starting Vim, but uninstalling and hating it were essential steps towards Vim nirvana.

Because then I found out about ctrlp.vim and :E, two things that makes NERDTree completely useless to me.

Was NERDTree making you unproductive? How?

It's not that NERDTree makes one unproductive. It's that using NetRW on default vim installations allows you to get going without installing NERDTree.

Knowledge of the ability to use netrw as a local directory browser seems to not be very widespread.

Thanks to bloggers everywhere.

One thing NERDTree does that netrw doesn't (IIRC, haven't looked very deeply into this) is open files you select in a different window than the one that contains the file listing. I happen to find that convenient, YMMV, of course.

o does that. :h netrw-browse-maps

Almost, but not quite. o opens a new window with the selected file, while nerdtree opens the file in the most recently used non-nerdtree window.

Also, there doesn't seem to be a way to tell netrw to create a vertical split rather than a horizontal split, which is inconvenient on modern wide screen monitors.

Did you actually read :h netrw before giving up?

opens the file in the most recent non netrw window.

opens the file in a vertical split and

opens netw in a vertical split.

Good suggestion. In the article, I failed to point out that the advantage of NERDTree is its hierarchal folder view. When a project's directory structure become gigantic it's useful to see the directory structure as you edit.

netrw does that too: hit i to cycle through all the available listing style or add this line to your ~/.vimrc if you want the "tree" style by default:

    let g:netrw_liststyle = 4

Oh, cool! I'll give it a try, thanks!

Vimcasts has an episode on netrw. http://vimcasts.org/episodes/the-file-explorer/

And yet, almost everyone does.

Thanks to the hundreds of blog posts that tell them to do so.

Pretty much--I actually had no idea netrw existed since everyone always just points to NERDTree.

Instead of NERDTree you might want to try Vimpanel, it's based on NERDTree but much more evolved, and instead of using :bprev/:bnext you might want to try Bufstop, it uses history instead of the buffer list to get you to the previous buffer. I made these to get around some limitations for some plugins that everyone seems to suggest.

https://github.com/mihaifm/vimpanel https://github.com/mihaifm/bufstop

Am I the only who tries not to override default commands? It's not like I use them all, but I might learn it at some point, and I want to have them available.

As a rule of thumb you are right, but in the particular case of s, S I think it's OK. They are pretty darn redundant.

My vimrc file with step-by-step instructions for installation:


Some features in my vimrc file:

* Code folding for bracket or indention based languages

* Edit multiple files in tabs using minibufexpl plugin

* Using the Solarized color scheme

* Using Vundle for plugin management (apt-get for Vim plugins)

* Common swp, backup, & view directories (No more ~ files left around)

* Useful defaults (spaces instead of tabs, remove trailing newlines, etc.)

I use MacVim for editing files locally on my Mac: http://code.google.com/p/macvim/

> With a modern, 256-color terminal like iTerm2 or Gnome Terminal, it will even look like gVim

Uh, I use xterm...

It's obsolete, I know, but it's still the fastest.

Fastest? Like I'd realize the speed difference between xterm, urxvt or even Gnome Terminal.

Trust me, when you have really crappy hardware (Intel Atom 1.3GHz w/ 512MB mem), you will notice the difference. Execution of commands that takes 2-3 seconds on Gnome Terminal will be nearly instant on xterm.

Is rxvt slower? Recently I switched from xterm to rxvt-unicode and it's really great!

Not sure... I'll have to give it a go to see if it really is.

Xterm will do 256-colors too. It's the setup I use.

Also, Terminology. Faster than xterm or rxvt.

rxvt-unicode? st?

Here are my 2 cents

set undofile " This creates a undo file that persists your undo history when the file gets closed

imap >> <ESC> " Double right arrow to escape from insertion mode. This is faster and more comfortable (at least for me) than to reach for tab key for some people

set clipboard=unnamed " This is bridges between your Vim yanks and your system clipboard

undofile sounds great! I didn't know about it.

Some people use jj to go to the normal mode. Personally I remapped Caps Lock to Escape in my whole system, so I can go to normal mode easily.

You can yank to the system clipboard by providing appropriate register to yank into. You do that by pressing "* before the yank command (e.g. "*yy to yank the current line).

I have some code to keep the undo/backup/swaps in a sane place... http://stackoverflow.com/questions/4331776/change-vim-swap-b...

Recently, I made the switch to vim from Sublime Text and I have installed some of the same tools. So far, I've committed to vim, but I have found that the plugins for file searching, linting, etc. are easier to use, more intuitive, and less painful to setup in Sublime Text.

Does any vim plugin support context sensitive auto-complete like Visual Studio (auto-complete only with variables that are alive in the current block of code)? I code in perl and am currently using ctags for autocomplete, but it doesnt autocomplete based on the context.

My .vimrc does this. I haven't used it much in perl (mainly bash, ruby, and python) but it should work fine.


The important bits are vim's built-in omnicomplete and neocachecompl

Omnicomplete by itself isn't bad. I haven't seen any excellent documentation explaining how it all works, but even without my .vimrc I use C-X-f a lot to complete filenames.


Minor nitpick, but can any terminals do squiggly underlines or is that still a gVim only feature?

Squiggly underlines? What, do you mean:

    1 class Hello
Like that? Of course; heck, even xterm does that fine. If you were referring to something else, I'm not too sure...


Never mind, now I know what you're talking about. No, I don't think you can get those in terminal vim, but I'm pretty sure there is a plugin for it.

iTerm2, at least, can show underlines where you'd expect squiggly lines in GUI vim. It's not as nice as the squigglies but it's pretty functional in practice.

I can recommend CtrlP (or Command-T). I can't imagine navigating in a project without them. They also have great buffer navigation. Personally I mapped <leader>t to CtrlP file search, and <leader>b to CtrlP buffer search (:CtrlPBuffer).

My favourite ones:

" Make Y behave like other capitals

nnoremap Y y$

" Reselect visual block after indent/outdent

vnoremap < <gv

vnoremap > >gv

Curious - what's the point of retaining the selection after indenting?

Sometimes you want to indent more than once. This remap is fine, but the idiomatic way to do this is just to use a period to repeat the last command. It doesn't hurt to get used to that.

Enter a number then any command to repeat it as many times as you want.

Sometimes it's easier to see things line up.

I'm disappointed no one's mentioned digraphs yet. I've used emacs for years, but I'm starting to use vim now because ctrl-k G* etc is just so easy (I type a lot of math).

If that's your only reason, stick with emacs but use evil-mode. I flip-flop between liking evil-mode (when I'm mostly just editing stuff) and preferring standard emacs keybindings (when I'm switching a lot between shells, dired, interactive sessions, etc.)

With other people's code I prefer to use something like http://astyle.sourceforge.net/ on the command line.

One of the things that I really love about Vim is that it's the same on every platform, including Windows. Hell, it's the same on my Android device.

Has top level windows been implemented yet. It's been on the todo for a long time so has a lot other new feature requests.

Basically can you create one vim server and make multiple connections to it, sharing the same session and buffers. Like how emacsclient works.

No Command-T!? FAIL.

That's what CtrlP is for.

I use nvi, and have tried to switch to vim a dozen or so times over the years. But there are so many irritating little quirks and misfeatures and annoyances that I can never manage to fix. Does anyone know of a guide to getting a sane, non-broken vim working with some basic plugins like syntastic? Last time I tried I couldn't bind F-keys for some reason, I couldn't get syntastic's error marking column to stay on instead of shifting my text back and forth all the time, I couldn't get auto-complete mapped to tab properly, and a few other things I can't remember now. I eventually gave up again as the extra functionality of vim ends up being counter-productive when none of it works right.

>> Does anyone know of a guide to getting a sane, non-broken vim working with some basic plugins like syntastic

There are a number of vim-setups that are popular. janus (https://github.com/carlhuda/janus), spf13 (https://github.com/spf13/spf13-vim) are pretty popular ones.

>>Last time I tried I couldn't bind F-keys for some reason F keys bind fine for me, using OS X Terminal, and gnome-shell in linux. Are you using an esoteric term?

>> I couldn't get syntastic's error marking column to stay on instead of shifting my text back and forth all the time That is using the SignColumn part of vim. As far as I know, vim doesn't allow you to force the existance of SignColumn. You can open up a bug report at their Google Code repo if you think its worthwhile

>> I couldn't get auto-complete mapped to tab properly Depending on your language, YouCompleteMe (https://github.com/Valloric/YouCompleteMe) is amazing, but if you don't do C based stuff NeoComplCache is great too (http://www.vim.org/scripts/script.php?script_id=2620)

>> the extra functionality of vim ends up being counter-productive when none of it works right To be fair, thats true of any tool.

It sounds like you want vim features. But vi compatibility mode is probably not consistent with these. Mapping f-keys should work fine in a GUI vim, but in a terminal F-keys may depend on configuring the terminal. You don't have to use syntastic if it doesn't work right for you, you can just use individual checker plugins or set makeprg and use :make. Mapping auto-complete to tab depends on not having multiple plugins fighting over the key. Most of this is a matter of particular plugins, not vim itself.

Right, I want some of the vim features, mainly plugins. I don't enable vi compatibility, it isn't even remotely vi compatible and it just breaks stuff. I want syntastic, that's the primary motivation for trying to get vim working. I just want it to be helpful instead of irritating. No plugins are messing with tab, I am just trying to get it to work using a normal mapping.

>> I couldn't get syntastic's error marking column to stay on instead of shifting my text back and forth all the time

Try this:

    augroup syn_gutter
        au BufWinEnter * sign define mysign
        au BufWinEnter * exe "sign place 1337 line=1 name=mysign buffer=" . bufnr('%')
    augroup END
Bonus fancy character bling: let g:syntastic_error_symbol='✗' let g:syntastic_warning_symbol='⚠'

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact