
Vim Anti-Patterns (2012) - lelf
https://sanctum.geek.nz/arabesque/vim-anti-patterns/
======
csomar
Here is a trick that I used to use when I started learning VIM:

\- Write down 2-3 tricks/shortcuts in a piece of paper. Put that piece of
paper in front of you (ie: tag it to your screen).

\- Code with Vim. You'll eventually look at the piece of paper and find some
of these shortcuts helpful. So you'll use them.

\- After a while, these shortcuts will get into your muscle memory and you'll
no longer need the piece of paper.

\- When you are coding with VIM, detect annoying patterns: For example, I need
to jump code, I need to replace often, I need to be able to select some text
this way, I need GIT integration. You get the point.

\- Put these observations on a list. Pull 2-3 items (shortcuts) from this list
and tag another paper to your screen. Pull 2-3 items (plugins/functionality)
and enhance your VIM.

\- After a few years, your VIM will become extremely customized. You'll
actually have trouble writing code on any other IDE.

\- Here is mine:
[https://github.com/omarabid/vimrc](https://github.com/omarabid/vimrc)

Other bonus tips:

\- Use GIT to keep track of your VIM configuration.

\- Write a README file for your configuration. Other things that I should do:
Update the README often, and add screenshots.

ps: in case you haven't noticed, I'm a die-hard VIM fan.

~~~
kbenson
It's important to note the context these articles are usually presented in,
and also most the responses, which is Vim for developers (or at its most
general, Vim for sustained local use). The reason I bring this up is that
there's a whole other set us use that is often overlooked, which is Vim as a
standard tool for sysadmins.

Any system you connect to will have Vi, and probably Vim. This makes it an
ideal tool for sysadmins that might need to connect to tens or hundreds of
systems to know how to use, _and to have a fairly standardized behavior_. In
those cases, having a customized config can actually be more of a hindrance,
because switching from a highly customized local Vim instance to a stock
remote Vi/Vim instance can be jarring.

For anyone who is primarily a sysadmin, I would recommend sticking with the
default behavior (which is rich, and lends itself to being more and more
useful and they become familiar with more an more commands), and making a
minimum of local config changes and plugins to suit their needs (it's a trade
odd. Just choose wisely). This makes life easier when you spend a significant
portion of time on random stock Vim instances (and even if it only saved a
modicum of time, it saves a lot of aggravation as you don't feel like you're
working with missing limbs).

Then again, I've always been one to do develop scripts remotely to help with
tasks (all the easier to test int he correct environment), so other people's
experiences may differ. I'm primarily doing software engineering now, so I
load main vim instance with a fair amount of specialization (but probably less
than most).

~~~
sevensor
> I load main vim instance with a fair amount of specialization (but probably
> less than most)

Perhaps it's just that the people who diligently curate their .vimrcs are more
prone to talk about it than people who use stock or minimally configured vim.
I can tell you my .vimrc right now without looking at it.

    
    
        se sm
        se hls
        se number
        se ts=4
        se sw=4
        se expandtab
    

It's not very exciting. Nobody ever writes a blogpost on the virtues of a
vimrc that looks like this one.

~~~
kbenson
Ha, I see that your .vimrc is almost identical to mine in functionality, even
if mine is riddled with mostly superfluous additions and lots of comments.
What you've got there though is probably what I would consider the core things
I would need to set in vim to get my desired experience on a new workstation
if I didn't have my own .vimrc to download, all the way down to the number of
spaces for expanded tabs.

The rest of the stuff I have boils down to history size, a fixup for backspace
in insert, default paste mode and quick key to toggle it, how far from margins
to start scrolling, and turning off swap files so editing very large files is
easier. Oh, and the Pathogen init stuff, for which I have usually have no
modules installed (but I test out stuff occasionally), but there it sits.

------
blunte
Any tool you need to use more than a few times is worth learning properly. And
any superior tool is worth switching to and learning if you would use it
frequently.

I suppose it depends on how one's mind works. If the mind moves slowly and
holds onto ideas and abstractions easily, then the slower motor movements of
moving the hand back and forth from arrow keys to home keys, and to mouse and
back, are not really a problem. But if you're like me, and your mind is
constantly racing, you need to be fast to get your ideas out before they're
gone/replaced.

It's not just the time cost of moving the hand from home row down to find the
correct cursor key, do the presses, and then move back to typing position -
it's also the likely visual/mental cost of looking away from your screen to
aid in positioning the hand, then looking back at the screen and finding what
you were looking at before. All those movements and recalibrations take time
and involve mental context switches.

If you're spending a lot of time using a certain set of tools, there is no
reason to avoid learning those tools well. Refusing to do so is choosing to be
ignorant and subperformant.

Now, if you'll only use the tool once in a while, perhaps it's not worth the
effort. But chances are, there's some other tool you use often that you could
master for your long term benefit.

If you program, Vim (behavior) is very difficult to beat for getting whats in
your head out and into your computer VERY quickly. As a bonus, using a full
featured IDE like one of the JetBrains products, but with the Vim plugin, is
win win. You get the code editing speed of vim, plus the project navigation
and other benefits of the IDE. Totally worth the time investment.

~~~
muststopmyths
> As a bonus, using a full featured IDE like one of the JetBrains products,
> but with the Vim plugin, is win win.

I refused to use Visual Studio for code editing until ViEmu came along. These
days I use VsVim. vi is fantastic for editing/writing and using the other
niceties of Visual Studio is a win-win, as you said.

~~~
transpostmeta
This cannot be overstated. 90% of the advantages of VIM is the modal editing
interface, which can be used beautifully in Visual Studio, Visual Studio Code,
IntelliJ IDEA, and other nice IDEs.

The VIM way is a very good way of editing text. IDEs offer a lot more than
editing text. Faking an IDE within a text editor with random plugins is
terrible. Emulating VIM text editing within a real IDE is amazing. Just use
VIM keybindings in your industry standard IDE, you will be able to use all the
tips in the linked article and still not miss out on anything offered by the
IDE.

The only problem is that the VIM keybindings are integrated into direct text
editing, but not the IDE UI. For example, in Visual Studio, IntelliSense
offers you a choice of possible completions for a variable name you are
typing. You can only navigate these choices with your cursor keys, rather than
with the VIM-style jkl; keys. But it's a small price to pay for really good
text-editing qualities!

~~~
learc83
> You can only navigate these choices with your cursor keys, rather than with
> the VIM-style jkl; keys. But it's a small price to pay for really good text-
> editing qualities!

I have ctrl-j and ctrl-k mapped to down and up on my keyboard for just this
reason. If you have a keyboard that supports macros it's easy to do and it
works for all those annoying places in Visual Studio and the rest of the OS
you need to use arrow keys for.

------
blunte
These are excellent. I didn't know about gi, and that's very useful.

Today I accidentally learned that ctrl-a and ctrl-x increment or decrement the
number under the cursor. That's not terribly useful unless you're dealing with
a lot of numbers, but if you are, it will save a lot of keystrokes.

One set of movement keys the article didn't mention but which I use all the
time are H M and L (shift-h, etc.) They jump to top (high), middle, and bottom
(low) of the editor window, respectively.

~~~
h43z
Even better you don't have to be with the cursor on the number you want to
increment or decrement with Ctrl-A and Ctrl-X. It will work with the next
number to the right of the cursor.

The same goes for ci' or ci".

a = 'foo' // imagine the cursor on the letter a

Executing ci'bar will change foo to bar.

~~~
yjftsjthsd-h
> Even better you don't have to be with the cursor on the number you want to
> increment or decrement with Ctrl-A and Ctrl-X. It will work with the next
> number to the right of the cursor.

To the point that I have used c-x c-a as a stupid shortcut to jump to the next
number on a line. I'm sure there's a better way to do this, but it's fast
so...

~~~
edanm
Surprisingly, there actually isn't an out-of-the-box way to jump to numbers
that I know of!

I personally added a "number" text object, so that I can treat numbers just
like "words", and also created a "jump to number" shortcut.

------
Assossa
Ctrl-[ is a good replacement for escape but I've found it's not always
supported in every vim implementation. If I remember correctly it doesn't work
in the visual studio vim plugin.

Binding something like JJ to escape is also a good solution, but if you ever
have to edit on another machine without your vimrc, your speed will seriously
suffer. I try to not change/add any core hotkeys for this exact reason. I can
ssh into a brand new Linux install and edit with stock vi at the same speed as
on my development machine's vim install.

I discovered that Ctrl-C is another default escape alternative. It's worked on
everything I've tried so far: vi, vim, nvim, gvim, vim over ssh, vim for
visual studio, vim for IntelliJ, etc. This is what I've gotten used to using.
Another benefit is if you're using a non-vi editor and try to exit insert mode
out of habit, Ctrl-C won't actually do anything, whereas Ctrl-[ could be a
hotkey in that program and JJ will obviously insert two unwanted characters in
your document.

~~~
fwip
Ctrl-C will keep certain events from firing in vim (can't remember their names
off the top of the head, something like OnInsertLeave).

Remap caps lock to escape on your computer and it'll work in every editor and
every machine you ssh into.

~~~
sjy
But I'm using Caps Lock to type Ctrl-C!

------
xaduha
Who cares? As long as you can edit text and it doesn't get in your way it's
all fine. I can switch between using vim and vscode without any problems.

I don't use vim to its full potential and I never will, I don't know many
vscode shortcuts either. I'm not a typist, most programmers should spend more
time thinking than typing anyway.

~~~
0xEFF
I've noticed the people who work to master the tools of their trade are also
the people who master the trade itself. I've yet to meet someone who mastered
the trade without also mastering the tools they use.

~~~
atoav
I must say I disagree. Having some control over the tools is certainly of
benefit. Yet my experience certainly was, that the greatest people I met were
sometimes surprisingly slow with the tools they used.

This is because what really seems to matter is their prespective at things and
what decisions they take then. Sure knowing their tools inside out will make
them faster, but it is not the KEY thing of why you would take them over every
other person. Unless of course your job very focused on these tools (e.g. hand
crafting etc) and even there knowledge often trumps tools.

Tools are just tools. If you look at a Cameraperson at a movie set, you will
see it even more so. A young guy who knows that 50k€ Arri Alexa inside out
might be ending up making worse images than that old fart who just knows where
to put it and how to press record. That young guy would be a perfect camera
assistant tho. Making pictures is not the camera, just like writing code is
not the editor.

If I manage to get to the same thing as you, it doesn't matter if I use
notepad.exe, a typewriter or pen and paper, unless it takes me ten times as
long. But nearly none of the time consuming problems I had with code were ever
due to the fact that my editor slowed me down, but rather that I wasn't aware
of parts of my code.

I aknowledge however that people are different, and maybe it could be
distracting if your editor is to slow depending on the type of person you are.
I also like smooth workflows where things don't get in my way also in vim, but
there is a threshold above which it bascially won't matter anymore.

~~~
beatgammit
From my experience, people who are good at their trade tend to know their
tools very well. They may not use the best tools, but they use the ones they
have to their fullest. The people who aren't very good at their trade but want
to appear like they're good use the flashiest tools, but they don't know those
tools to their fullest. They may know of a lot of the features, but they don't
use them consistently.

It doesn't really matter what tools you choose, provided you know them well
and they're well suited for your work.

~~~
atoav
Now that I gave the whole thing another thought, it might be very different
for different professions.

Maybe we also got it upside down? What if experts tend to be good with their
tools, because they had a ton of experience with them and not the other way
round. So they are not experts because they use their tools well, but they use
tools well because they had a lot of time spent with these.

That is, if you are in a profession were the tools stay the same. The sound
mixers I mentioned certainly know SOME workflows inside out, but mixing desks
change and differ between manufacturers, get more modern etc. That means
judging a sound mixer purely by his ability to handle a certain mixing desk on
one point in time might not be completely representative of the man/woman’s
abilities.

For programming it is much the same. A perfectly guru programmer could have
switched to vim just months ago, while anoob could have invedted a year into
learning vim instead of gaining experience with code.

------
dang
2016:
[https://news.ycombinator.com/item?id=12643887](https://news.ycombinator.com/item?id=12643887)

2012:
[https://news.ycombinator.com/item?id=3563292](https://news.ycombinator.com/item?id=3563292)

------
darkpuma
> @@

Something somebody once showed me was

    
    
        noremap <Space> @q
    

With this, you can quickly record a macro to the q register by typing qq (and
q a final time to end the macro.) Subsequently with that binding, pressing the
space bar will execute the macro once.

With this binding I find myself making sometimes dozens of throw-away macros
an hour.

------
shmerl
_> Ctrl+F — Move forward one screenful._

 _> Ctrl+B — Move backward one screenful._

Why use such obscure combinations instead of standard PgUp / PgDn? I find this
bend on "make vim usage super fast by using completely obscure keyboard
shortcuts for common actions that already have designated keys" not to be
helpful at all. Such kind of micro-optimizations are not really what increases
productivity.

~~~
blunte
The same reason we use all the other Vim keyboard shortcuts - to keep the
hands on the home row!

I can ctrl-f way the f faster than someone who has to move their right hand
down or over to the pgdn key.

I once read a great explanation about programming language wars. The author
described a ladder of awareness, such that some languages were lower on the
ladder than others. The idea was that programmers who knew languages at or
below their level on the ladder could easily see the people below them and
recognize that their languages were inferior, but they were unable to see the
superiority of the languages above them. Of course the superiority of a
language is somewhat subjective and largely dependent upon situation, but the
concept is quite valid.

Do you use the mouse to click menus, or do you occasionally "cheat" and use a
ctrl-c, ctrl-v, ctrl-s, whatever? If you use those keyboard shortcuts, why not
other useful ones?

~~~
shmerl
I use many keyboard shortcuts, but I prefer natural usage, such as arrow keys
for one symbol / line navigation and PgUp / PgDn for page navigation. The home
row issue doesn't really bother me. Heavy focus on home row that forces such
kind of shortcuts seems a bit extreme for me personally.

~~~
blunte
I wasn't aware people were being forced to be mechanically efficient. It's an
option. You're free to drive your mouse all day if you like; in fact, you
could mouse select, right click copy, mouse click the cursor to a new spot,
right click paste, and be totally free of the burden of the home row.

~~~
shmerl
"The right vim way" proponents can be very opinionated about it, and view
those who don't follow same approach with a bit of conceit. I'm not saying
that always happens, but I've encountered such views. Not sure why this
affects specifically vim and not other editors.

------
aboutruby
> Moving one line at a time

I either go down with arrows (I know it's controversial), beginning of file
with :1, end of file with G, line number with :[line number] or search with /.
I usually don't have large files so this works very well (and I almost
exclusively go by line number on large files).

> Moving one character at a time

I use ^ for beginning of line, $ for end of line, e to move quickly in a line

> Searching for the word under the cursor

Nice, didn't know about */#, I just type what I'm searching, gonna use that.

> Deleting, then inserting

Insert mode is fine.

> Using the arrow keys

I use the arrow keys, and I don't care about all the arrow-key shamers out
there.

> Moving in insert mode

I use insert mode only while editing (makes sense). I don't get the point of
this paragraph.

> Moving to Escape

I'm fine with escape key.

> Moving to the start or end of the line, then inserting

I much prefer just going into insert mode.

> Entering insert mode, then opening a new line

I also use o quite often (as it just goes into insert mode).

> Entering insert mode to delete text

Yes, I delete with dd, de, etc. (. is also useful for that), deleting in
insert mode is painful for more than one character.

> Repeating commands or searches

Didn't know about q: and q/, pretty useful, nice.

> Repeating substitutions

I use %s/for/far/g or %s/for/far/, or for a few lines, I select them (shift-v)
(visual mode) then : (which auto-sets it to :'<,'>) then :'<,'>s/for/far/ for
instance.

Anyway, been using vim for ~5 years with a pretty light .vimrc and one thing I
would recommend is bogado/file-line plugin which lets you open a file at a
line, e.g. vim app/models/user.rb:48

My vimrc if anyone is curious:
[https://gist.github.com/localhostdotdev/aa25d1c81f3f3b67ac35...](https://gist.github.com/localhostdotdev/aa25d1c81f3f3b67ac35eccf1692f251)

~~~
vram22
>I either go down with arrows (I know it's controversial)

Probably not that controversial any more. It used to be (although I would use
the word inadvisable instead), because dumb terminals like VT-100 and some
emulators of them, would emit escape sequences when arrow keys were pressed.
Since an escape sequence starts with the Escape key and then has some other
keys following it, it would result in your going from input mode (if you
happened to be in it) back into command mode (due to the Esc key) and then the
remaining keys in the sequence would be likely interpreted as vim commands
(since many letters of the alphabet are vim commands), so any unwanted
modification could happen to the file you were editing, maybe without your
noticing. Then if you saved the file without knowing that there was some such
inadvertent change, you could have lost or mangled some of your content.

Nowadays common emulators that I have come across, don't have that issue, so
arrow key usage should be fine.

The other reason why people may comment if you use arrow keys for movement in
vim, is because if you instead use the default and recommended hjkl keys (for
left, down, up, right respectively), your fingers stay on the home row (on a
QWERTY keyboard), which may make for less finger / hand movement, so less
strain.

>beginning of file with :1, end of file with G, line number with :[line
number]

You can use 1G for beginning of file, G for end of file, and nG for going to
line n, without having to hit Enter after some of those commands as you have
to with the :[line number] method, thereby potentially saving one keystroke
many times per edit session.

>I use ^ for beginning of line, $ for end of line, e to move quickly in a line

0 goes to the real start of the line, ^ goes to the first non-blank character
on the line.

>I use the arrow keys, and I don't care about all the arrow-key shamers out
there.

Good on you.

>I also use o quite often (as it just goes into insert mode).

O (a capital O) _O_ pens a line above the cursor, o (small o) _o_ pens a line
below it.

> Repeating substitutions

>one thing I would recommend is bogado/file-line plugin which lets you open a
file at a line, e.g. vim app/models/user.rb:48

    
    
      vi(m) +n filename
    

will open filename at line n, for both vi and vim, so I'm not sure why that
plugin is needed, unless it does other stuff too.

And:

vi(m) +/pattern filename will open filename at the first occurrence of pattern
in filename.

~~~
aboutruby
Not sure if you are directing this comment at me, but I know most of these
already. Didn't know about the older terminal emulator issues with arrow keys
though.

~~~
vram22
It was partly for you and partly for other readers. It seemed to me that,
based on your comment, you may not have known about some of the points I
mentioned, like use of G with number modifiers instead of the "colon then
<number> then Enter" method. Maybe I should have been more specific, and put
the more general points in a separate comment. Also, I guess you may prefer to
use the colon method even though the G method is one key less. I know I do at
times, too :)

------
cygned
What I cannot wrap my head around is word-wise moving in code. I just never
really know where w or b takes me, let alone how many w’s it takes to get me
to the desired word. My moving is mostly based on estimating counts; nth space
(nf ) or just before third comma backwards (3T,); plus manual adjustments.

~~~
jolmg
There are 2 types of characters ignoring whitespace:

* Upper and lower case letters, numbers, and underscore. This is what one commonly refers to as word characters as they're the least common denominator of what identifiers in programming language are usually allowed to consist of.

* Everything else (punctuation and other symbols, etc.). We'll call these non-word characters.

w, b, e, etc. will work in units of consecutive characters of the same type.
So, if a consecutive set of word characters is a word, a consecutive set of
non-word characters is a non-word, and everything else is whitespace. w will
take you from the current word or non-word to the beginning of the next word
or non-word. e will take you to the end of the current word or non-word,
unless you're already there (one character word or non-words, for example),
then it will take you to the end of the next word or non-word. b will do the
same as e but to the beginning and work towards the previous.

The upper case versions of these commands, W, B, and E, treat the
aforementioned word and non-word characters as of the same type, so you move
in units of consecutive non-whitespace characters.

------
godelski
I don't suggest disabling arrow keys and mouse. But I don't suggest using them
either. (This goes for tmux as well).

The reason being is that you will frequently have to work with others. If
someone comes over to your computer (or you bring it to them), they need to be
able to look at the code. It just saves a lot of hassles. Besides, disabling
these isn't going to help you develop those patterns, what helps you develop
keeping on the keyboard is actively staying on the keyboard.

Side note: you'll notice vim users are more likely to use keyboard shortcuts
in substantially more programs than in the terminal.

~~~
thatoneuser
I don't see the point of disabling them. If you're a grown ass adult and you
want to learn the homerow movement, just use the homerow until you naturally
don't feel like using the arrows. It's not really that hard and you can always
fall back on the arrow keys if you really can't afford to guess where your
cursor will end up next.

~~~
thosakwe
I disabled mine earlier this week. After a bajillion years of using the arrow
keys (even in Vim), I needed something explicit to force me to use the
homerow.

~~~
keithnz
I think this is actually the point he was trying to make in the article, if
your instinct is to use the arrows and you want to break that, then Vim can
help you!

------
yakshaving_jgt
Another tip: Don't remap your comma (,) key to leader.

Many people suggest this — and I don't know why — but it shadows the
command(verb? motion?) to move to the previous match in a line-wise find.

Some people in this thread say they skip through a line by word with w/W/e/E,
but sometimes it's faster to see the character you want to jump to, say it's
the number 4, and do f4. If the cursor lands on an earlier occurrence of the
character that you didn't know was there, hit ; to jump to the next one. If
you skip too far, hit , to go back again.

~~~
fwip
I like <Space> as my leader key. Easy to hit and it doesn't do anything
useful.

------
waivek
I've used vim for seven years now. My vimrc is a gargantuan 122 lines of vimL.
It went from 0 lines to 300 to 750 and it's been 122 for a year now. Whenever
someone asks me for tips and tricks to learn vim I reference this tweet:

[https://twitter.com/ID_AA_Carmack/status/473247789728952321](https://twitter.com/ID_AA_Carmack/status/473247789728952321)

Just use VSCode / SublimeText / Notepad++

------
dredmorbius
See also the excellent "Your problem with Vim is that you don't grok vi" by
Jim "Linux Answer Guy" Dennis:

[http://stackoverflow.com/questions/1218390/what-is-your-
most...](http://stackoverflow.com/questions/1218390/what-is-your-most-
productive-shortcut-with-vim/1220118#1220118)

------
morningmoon
vim-adventures.com is a great way to learn vim by playing a game.

It’s worth the money if you enjoy solving puzzles and learning by doing.

~~~
mjlee
vimtutor is also a good way to get started with the basics of vim. If you have
vim installed, it probably came with it.

------
emmelaich
Some vim keys I use a lot that seem not to be mentioned too often:

{ and } to go back and forwards a "para"

^U and ^D to up and down a half a page

{ and } are particularly useful with verb keys such as y, d, < and > (outdent
and indent). And ! (bang) to reformat text with `fmt`

I cry a little inside when I see people go through pages with the j,k or up
and down keys.

~~~
therealdrag0
One I noticed missing (based on another comment here) is ctrl+o to run a
movement command while in insert mode. To me this is pretty valuable glue
between command/insert mode.

E.g. "ctrl+o 2e" to skip forward 2 words.

~~~
emmelaich
Cool. There's always stuff I didn't know about.

I think that on most terminals/vim combos the arrow keys will also move in
insert mode.

------
fanpuns
The opening of this rings true for me. Once I get a pattern ingrained, it can
be difficult to reverse it even if there is a more efficient way. To combat
this I usually pick one thing per coding session to work on. I find lists like
these helpful to check-in and see if I can add anything to my future to-work-
on lists.

When I started learning vim I read an interview where someone (Ben Orenstein
maybe?) talked about keeping notecards or a cheatsheet on their desk so they
could do the same thing and I thought they were insane (and vim was insane).
With time though, this method got me proficient at vim, then better, then
better still. Each time I learn something new or unlearn sometime inefficient
for something better I get a little bit of joy out of my daily work.

------
dredmorbius
Disclaimer: My vim knowledge has many gaps.

Understanding vim's model, what Chris Toomey of Thoughtbot calls "the Vim
Language", helps incredibly:

[https://youtube.com/watch?v=wlR5gYd6um0](https://youtube.com/watch?v=wlR5gYd6um0)

I've picked up numerous tips watching this and other of Thoughtbot's excellent
video series. More importantly, though, is that I've learned _why_ specific
vim idioms and motifs exist. They've lead me to rethink my own usage patterns,
sometimes changing them, sometimes holding them just a bit more tightly. (Say,
my practice of doing global regex pattern-replacement edits rather than
repeated vim edits or macros, generally.)

But for a tool I use for coding, data cleaning, systems administration, email,
writing, document preparation, and more, it pays to be on the lookout for more
effective, faster, reliable, and/or repeatable methods.

And no, vim's not the only editor I have, or do, use. It's not even the first
Unix editor I'd used. There's been DOS EDIT, EDLIN, MacWrite, WP51, WordStar
(me and GRR!), EDT, EVE, the ISPF editor, emacs, pico, ae, MS Word, ... you
get the idea.

But back in the 1980s, I first encountered (and balked noisily at, for a few
weeks), BSD vi. And the basic muscle memory acquired, after a brief period of
pain, has almost certainly been my best technical investment after learning to
touch-type itself. Most importantly becaue both have been remarkably _durable_
skills. No, vim is not vi, _but it builds on its core_. And over 30 years
later, I find it useful both to see what new capabilities have been added, and
where my old knowledge has holes or flaws.

And I plan to be using, and able to use, that knowledge in another 30 years.
Which I cannot say for most of the other editrs I've listed, or those listed
by others here. It's been _both_ vi/vim's utility _and_ consistent access to
it which have made it a valuable and durable tool.

Vim is a massively efficient tool for sculpting text. And that's why I use it
and continue to hone my own skill with it.

~~~
JdeBP
No Brief? Or qedit? Or E? (-:

^K^D

~~~
dredmorbius
I omitted a few. Qedit makes the list.

------
lnyng
For the advice towards ESC key, anyone uses ctrl+c for quitting insert mode? I
didn't know about the ctrl+[ combo works too.

------
Schiphol
Of all the good practices listed here, the only one I can't seem to be
bothered with is */# for searching the word under the cursor. I am curious is
this happens to others, or it's just thst my workflow is idiosyncratic in this
respect.

~~~
pvinis
I use * often. It's even more convenient nice I have * mapped to pressing a
modifier+n, so after I type * I can just hit the same key and type n, or
switch to shift+n to go backwards. The map is on my keyboard, not on vim.

(You have an interesting username!)

~~~
Schiphol
It's an interesting airport :)

------
mattrp
I will never understand why iPad keyboards do not have a proper esc key. I
know you can remap but it’s not the same. It’s almost as if apple knew this
one key would forever preserve the MacBook as a developer platform.

~~~
jjpprrrr
The current Macbook Pro with Touchbar does not have a physical Esc key either.

~~~
fjp
I find this highly annoying as it's my issued computer at work, but it took me
like one day to get used to standard ctrl + [ as an alternative

~~~
mattrp
Perhaps but shouldn’t there be a rule that if it takes more keystrokes we
shouldn’t do it? It’s like deprecating df.ix for df.iloc... why do I need to
type two more letters for essentially the same functionality?

------
ma2rten
One thing I noticed myself doing is moving my fingers from the home row alot.
For example when type "0p, I think I am supposed to only the pinky the type
the entire command, but I am using the ring finger.

------
grondilu
Glad to notice I knew all of these, apart from q: and q/

------
blunte
More tips:

If you inoremap jk to ^[ (esc), and kj to ^[ as well, you can just roll jk or
kj keys to escape back to command mode. No more reaching for the esc key.

~~~
sagartewari01
Or swap caps lock and escape. How many times did you reach for caps lock
during the last year?

~~~
blunte
I prefer CTRL to be where caps lock was. I use CTRL very often, especially
since (on macOS and Linux) many text fields use readline, which means you get
Emacs ctrl- movement keys.

Almost the only time I use ESC is in Vim, and ctrl-[ or ideally the jk/kj->ESC
mapping is really nice for me.

Now that I go the jk/kj esc mapped for .ideavimrc, I'm super psyched.

------
stevebmark
Using Vim without knowing WAY more than this article is an anti-pattern. Vim
is inefficient for editing so you have to learn a lot more than these tricks
and hacks to be proficient. If you aren't learning more about Vim's nasty
design every day then it's an anti-pattern to use Vim, because you'll be much
more efficient with less learning in any other editor. If, for example, you
don't know how to edit searches and command-line mode commands in full Vim
mode, then keep learning (press control-f in search mode). If you aren't
proficient in Vim's garbage VimL then keep learning. Obviously an IDE with
intellisense and multiple cursors is more efficient than most of Vim's
efficiency hacks. Vim's efficiency gains more apply to editing text, not
structured code.

~~~
ma2rten
I started using vim about 10 years ago. I am not an expert user, but I am
using enough of it's features that I feel crippled when I am using another
editor. I just have to think move this function to another file and my fingers
will execute the vim commands.

I don't know any Vim Script. You don't have to know it to use vim, unless you
want to write your own plugins.

I tried using an IDE recently (Clion), but it was not really worth it. Vim has
plugins for most IDE features, including autocomplete and syntax checking. The
only feature that I really miss in Vim automatic refactoring such as inlining
functions.

~~~
nwatson
You don't mention interactive debugging in vim ... and I'm not sure there's a
good story there that's better than your CLion (Jetbrain's C/C++ IDE) -- I'd
like to hear about vim interactive debugging. Perhaps there are other good
debugging solutions for C/C++ but I like to edit and debug in the same
environment.

Any Python code I write or review in Python I try to give a run-through in
PyCharm (JetBrain's Python IDE) interactively -- having a chance to step
through code lets me consider more options and corner cases and get a more
expansive view on what I'm developing or reviewing.

"vim" is my preferred editor when I'm not in an IDE, and often when writing
bash scripts, but over the last ten years especially I've rarely written
higher-level language code outside an IDE environment ... and I stick to
JetBrain's suite mostly these days.

~~~
jtms
20 year vim user here... There is a really decent VIM plugin that works with
all of the jetbrains IDEs I have used that I would recommend. It will even
read your vimrc file! I wouldn’t write Java or C# without an IDE (IntelliJ
IDEA and Rider respectively) and the vim plugin makes adjusting to them much
less painful.

~~~
sagartewari01
Can you provide the link for that plugin?

~~~
jtms
I’m not in front of my workstation right now, but I believe this is the one:
[https://plugins.jetbrains.com/plugin/164-ideavim](https://plugins.jetbrains.com/plugin/164-ideavim)

~~~
jtms
It’s not perfect, but it does visual mode and visual block mode and will use
as much of your vimrc as it can. Beats the heck out of vanilla IntelliJ that’s
for sure.

