
What is your most productive shortcut with Vim? - shawndumas
http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118/
======
jlgreco
Not necessarily in line with what the SO question is asking for, but this is
by far the best thing I have ever added to my .vimrc:

    
    
      " make space execute the 'q' macro (press qq to start recording, q to stop,    
      "       then [space] to execute.  super convenient)                            
      noremap <Space> @q
    

This streamlines making and executing macros to such a degree that I'll often
do that instead of merely making 3 or 4 complex series of edits manually. You
just perform the edit once, then get in a few satisfying "thwocks" on the
spacebar.

 _(Note that to effectively create macros on the fly, you need to have a firm
grasp on vi "as an editing language". If you are merely moving around with
hjkl and otherwise treating it like nano, you aren't going to get much mileage
out of this unless everything you are working on has the same number of
lines.)_

~~~
qqqw
Learning muscle memory for nonstandard mappings is a bad idea. I used "jk" as
an escape for a long time. It's nicer than using esc, but no other program
that has vim emulation supports mappings like that.

Also, you can do <num>@q (e.g. 4@q) anyways, and @@ to repeat a macro, so that
isn't that useful of a remapping anyways.

~~~
sillysaurus2
Eh, I disagree. First, vim emulation is horrific -- absolutely horrific. With
the exception of ViEmu, and possibly the new Emacs one (haven't had the chance
to try it), there's not a single good Vim emulator. Second, @@ is two
keystrokes, and it's incredibly annoying to type @@n@@n@@n@@n@@n@@n in order
to invoke the macro 6 times. " n n n n n n" is much easier.

~~~
qqqw
What do you mean by "n"? Moving to the next position in a search? You can
structure a macro to end with going to the position of next edit. Then you can
hit 100@@ or whatever and do all of the edits in one go.

~~~
sillysaurus2
Most of the time you want to individually review each instance of what the
macro is doing before invoking it, so 100@@ is rarely used. (At least by me.)

------
gamegoblin
I suppose I don't use enough of Vim's namesake improvements; I don't know if I
have ever found myself using anything outside of standard vi functionality.

That being said, I do feel gimped in other editors without vi(m) commands.
Most editors do have vim modes, but it doesn't quite feel the same.

~~~
bcrescimanno
It doesn't "feel the same" because it (almost always) isn't--at all. Editors
with "vim" modes generally boil down to "you can enable vim-like keyboard
shortcuts for the thing that this editor can do." The key problem is that the
power of vim isn't the keybindings; it's the grammar system to which those
bindings apply. Other editors lack vim's text objects and, as such, the "nouns
and verbs" metaphors can't really apply.

Really learning to use vim effectively involves learning to think about text
differently. It's about training your mind to think in terms of text objects
and exploring the various ways to manipulate those objects.

The truth is that "vim mode" generally boils down to using h,j,k,l in lieu of
arrow keys and a token nod to the idea of normal mode vs. command mode.

But, honestly, that's ok. Vim exists--why do I need another editor to behave
like vim?

~~~
johncoltrane
Fun fact: most of the commands in Sublime's vintage mode are direct API calls.
Sublime's text-manipulation engine is more powerful than what is exposed to
the user via the usual Ctrl+Alt+Shift+key combos and its WIMP UI and
activating vintage mode is the only way to use all of that power.

------
johncoltrane
Search/replace the word under the cursor in the current paragraph (for
<leader>r) or the whole buffer (for <leader>R). Beats the crap out of
"multiple cursors" in the typical "change a variable name" example:

    
    
        nnoremap ,r :'{,'}s/\<<C-r>=expand('<cword>')<CR>\>/
        nnoremap ,R :%s/\<<C-r>=expand('<cword>')<CR>\>/
    

Another approach of the typical "multiple cursors" example, using the
beautiful gn command. Hit ,x to "change" the word under the cursor then <Esc>
and repeat for the next occurrences with the dot (or n to skip):

    
    
        nnoremap ,x *``cgn
        nnoremap ,X #``cgN
    

Move to next and previous quickfix error:

    
    
        nnoremap <End>  :cnext<CR>zv
        nnoremap <Home> :cprevious<CR>zv
    

Traverse the buffer list effortlessly:

    
    
        nnoremap <PageUp>   :bp<CR>
        nnoremap <PageDown> :bn<CR>
    

In my lightweight "noplugin" vimrc (used on remote machines) I have these as
well:

    
    
        set wildcharm=<C-z>
        set path=.,**
    
        " juggling with files
        nnoremap ,f :find<Space>
        nnoremap ,s :sfind<Space>
        nnoremap ,v :vert sfind<Space>
    
        " juggling with buffers
        nnoremap ,b :buffer <C-z>
    
       " juggling with tags
       nnoremap ,t :tjump /
       nnoremap ,p :ptjump /
    

Beside all those custom mappings, macros, Ex commands, motions, text-object
and in general the whole "grammar" that ties everything are killer features.

------
hackaflocka
Is there a reason why a simple visual editor such as notepad++ cannot be used
via the terminal (e.g., for Linux administration)? I'm trying to do some LAMP
related server administration using vi and I cannot believe how many weird
commands one has to learn to do simple text editor functions. It's also
probably a hugely intimidating factor that prevents more newbies from moving
to Linux.

~~~
bcrescimanno
To do absolutely basic text editing, you really don't need to learn much at
all:

i - enter insert mode. ESC - leave insert mode. ZZ - save and quit :q! - quit
without saving.

Since, in insert mode, vim basically behaves like a simple notepad, that's
really all you need.

FYI, if you want a "simple," notepad like editor for console on linux, check
out nano.

[http://www.nano-editor.org](http://www.nano-editor.org)

~~~
lowboy
I think most people would consider copy/paste and undo/redo to be included in
"basic" text editing.

~~~
hackaflocka
If the Linux community wants to attract more newbies, they need to come up
with an easily "grokked" text editor.

~~~
jlgreco
There are plenty... nano/pico/joe if you want to work in the terminal _(though
who is trying to woo newbies with terminal based text editors?)_ , and
gedit/kate/kwrite in the GUI department. The idea that Linux is somehow
floundering because only Vi and Emacs exist and those are difficult is absurd.

Perhaps the real question is _do_ we want to attract more newbies? _Why_ do we
want to attract newbies? If more non-technical users are the solution to our
problems, then why is Android (with their _legions_ of newbies) such an
_absolute shitfest_ compared to traditional Linux distros?

------
qqqw
I feel like this has been posted 100 times on here and /r/programming.
Anyways, if you don't know vim, I wouldn't waste your time learning. It is a
better way of editing text than chord based editors, but ide's are much nicer
tools for development. And if you're using one, there's going to be
significant mousing around anyways, and none of emulation modes are that great
for the non text editing/navigation stuff.

~~~
burntsushi
> there's going to be significant mousing around anyways

Which is one of the many reasons why people (including myself) _don 't_
consider IDEs as a nicer tool for the job.

> but ide's are much nicer tools for development

Just because you think they are doesn't mean everyone else does.

~~~
qqqw
Don't get me wrong, ide's are terrible, they're just better than anything else
we have right now. And I'm someone who has programmed with vim and plugins,
bash and friends, etc. for 10+ years, so it's not like I've only used ide's.
Writing code can be fine with the more minimalist approach, but ide's are much
better for reading and navigating previously written code.

> Just because you think they are doesn't mean everyone else does.

? Of course, it's just my opinion.

~~~
burntsushi
Here's a friendly piece of advice: distinguish claims that are opinion or
personal preference from statements of fact.

This is mundane: "IDEs work much better for me."

This is controversial (and probably silly): "IDEs are the best."

Maybe the intent is obvious, but it wasn't to me and at least one other
poster.

------
lcedp
Most productive due to the sheer frequency of usage:

    
    
        inoremap jj <ESC>
        nnoremap ; :
        vnoremap ; :
    
        " Fix vim's terrible default regexp scheme
        nnoremap / /\v
        vnoremap / /\v
        vnoremap ? ?\v
        nnoremap ? ?\v
    
        nmap <silent>]c :cnext<CR>
        nmap <silent>[c :cprevious<CR>
        nmap <silent>[C :cfirst<CR>
        nmap <silent>]C :clast<CR>

~~~
cweiss
For VIM n00bs, care to explain what these do/why you use them?

~~~
johncoltrane
I'm not the parent but…

Hit jj instead of <Esc> which many people find too far.

    
    
        inoremap jj <ESC>
    

Exchange ; and : because : is used a lot and you need to press Shift (on an
american keyboard) while ; is less used and available without a modifier key:

    
    
        nnoremap ; :
        vnoremap ; :
    

\v means "use verymagic mode for the rest of the pattern", normally, you'd
have to use a lot of backslashes to escape parentheses and other "spacial"
characters but "verymagic" allows you o type less and obtain more readable
patterns. Example:

    
    
        /f\(oo\)ba\[zr\]
        /\vf(oo)ba[zr]
    

With these mappings, search-based navigation is a lot less expensive because
it use s "verymagic" by default:

    
    
        " Fix vim's terrible default regexp scheme
        nnoremap / /\v
        vnoremap / /\v
        vnoremap ? ?\v
        nnoremap ? ?\v
    

:cnext, :cprevious and friends are quickfix commands: thay allow you to
navigate through the errors displayed in the quickfix window without using the
window itself. Even in their shortened form (:cn, :cp, :cfir, :cla) they
represent a lot of typing and a good occasion to create much more useful
mappings:

    
    
        nmap <silent>]c :cnext<CR>
        nmap <silent>[c :cprevious<CR>
        nmap <silent>[C :cfirst<CR>
        nmap <silent>]C :clast<CR>
    

nmap means "normal mode mapping".

nnoremap means "non-recursive normal mode mapping", see
learnvimscriptthehardway.stevelosh.com/chapters/05.html#nonrecursive-mapping

vnoremap means "non-recursive visual and select mode mapping", it should be
xnoremap (visual mode only).

<silent> means "don't print the executed command".

~~~
lcedp
Thank you, didn't see the question to reply in time.

------
liquidise
I continue to be annoyed by the growing popularity of the word "grok". It is
synonymous with well understood (ha.) words, but for some reasons, techies and
sci-fi junkies seem to prefer a word only they know.

~~~
gknoy
Have you read "Stranger in a Strange Land"? The word originates there, and has
a more nuanced meaning than just "understand". The book is strange and
interesting. I didn't pick it up until I'd read (and enjoyed) other of
Heinlein's stuff, and after I'd read about the word in the Jargon File. I had
always thought of it as a synonym of "understand", when in reality it is more
like a superset. As a nerd and an appreciator of language, I am very glad that
I read the book and understand the word better, as it really is an interesting
idea.

It's as big of a difference as speaking German with an accent is from being
fluent (along with thinking and dreaming in the language). Understanding
"grok" is like understanding the German concept of "friend"-vs-"acquaintance"
and thinking about your own friends in the same way, rather than our American
way of "everyone's my friend". (In German culture, most people -- coworkers,
teammates, etc -- are not __friends__. They're people you know, and maybe know
well, but "friend" is much more similar to an American's concept of a "best
friend", or group thereof. (I have about three.)

... none of that explains what "grok" means as well as reading the book.
Wikipedia [1] doesn't quite even cover it, but has a good collection of newer
uses of it that help.

In the case of this article, "grok" is entirely appropriate. It might even be
the best word. As a user, I can figure out commands in vim, I can use a cheat
sheet, but until I start thinking about using the tool in a way which fully
embraces the tool in the way it was meant to be used (e.g., verbs + marks),
I'll always be a poor and dissatisfied user.

1: [http://en.wikipedia.org/wiki/Grok](http://en.wikipedia.org/wiki/Grok)

------
pycassa
personally my favourite is I mapped 'jk' and 'kj' in insert mode to Esc, to
get to the normal mode from insert mode. type 'i' to get into insert mode and
then just press my fore finger and ring finger at the same time on the home
row, it can register 'jk' or 'kj' and takes me to normal mode.

~~~
qqqw
[https://news.ycombinator.com/item?id=6579149](https://news.ycombinator.com/item?id=6579149)

~~~
jlgreco
If this was actually a problem that pycassa experienced, then I doubt he would
have the affinity for the mapping that he obviously does.

------
alfiejohn_
Without a doubt turning on the following was the biggest win for me and Vim:

    
    
      set relativenumber

~~~
justinmk
If you're doing that to move vertically, you might want to try vim-sneak[1]
instead.

Personally, I disable the line-numbers column altogether (and display the
current column:line in the status bar).

[1] [https://github.com/justinmk/vim-sneak/](https://github.com/justinmk/vim-
sneak/)

------
clarry
Wait, vi does syntax hilighting?

~~~
jlgreco
Technically no, the standard for Vi says nothing about syntax highlighting. In
practice, maybe? The 'Elvis' implementation of Vi adds syntax highlighting for
instance.

------
hackaflocka
Computer nerds showing off. The question asker's concern is valid. It's a very
difficult process to become properly speedy at using vi. There's a huge
cognitive cost involved in memorizing all those keyboard commands.

~~~
mtdewcmu
If you're a programmer you have lots of time and motivation to learn your
tools. Even IDE users learn the hotkeys, and they're no easier to learn than
vim commands.

~~~
gknoy
I think they are easier for most people. We've been conditioned to using C-C,
C-X, C-V, etc for editing, with C-arrow for faster movement, etc, from apps
like Word for many years, so that is already relatively familiar. So, learning
editor shortcuts are often just layered on top of that.

In contrast, using emacs (which I have likely outed myself as a user of, via
my above notation ;)) or vi require you to be more mindful (at first) of what
you are doing while editing text. Both tools are likely to be frustrating if
you don't think of things in a way that matches the worldview that each was
built with.

~~~
mtdewcmu
If I'm not mistaken, C-C, C-X, C-V came from windows, or maybe DOS. A lot of
Unix editors are older than that, so you can't blame them for not using those.

To be a programmer, you have to learn a programming language. Learning an
editor is easier than that. A lot of programmers probably don't invest the
time to learn an editor, but it not much time in the long run, and it's worth
learning your tools.

