
Ten Years of Vim - omn1
https://matthias-endler.de/2018/ten-years-of-Vim/
======
linsomniac
One thing google can do that blows most peoples mind when I show them: Did you
know vim supports time travel undo?

Sometimes you do some things then undo and redo trying to get back to a
certain point in time. In vim you can step forward and back through all this
by doing "g-" or "g+" to travel backwards or forwards in time. Or you can say
":earlier 50s" to go back to where you were 50 seconds ago.

Most editors treat undo as a linear thing, you undo and you redo. But once you
undo and then do some things, it starts looking more like a tree than a line.
It's not frequent, but sometimes I just need to say "I know what I had was
what I wanted 5 minutes ago."

~~~
giancarlostoro
All the JetBrains IDE's keep a history of your edits, I accidentally rm -rf'd
the wrong dir and reverted my code back thanks to JetBrains. I can't imagine
vim saving your old files that have yet to be checked in to SVN / git
(breaking changes anyone?) that you've not yet opened on vim.

Funny you mention that though, a coworker opens files in vim and does changes
and tests but keeps it open if he's going to try something else so he can
always go back to those other changes (guessing he reverts the code, then
opens yet another vim window). I work with a lot of VI(M) coders but they
barely take full advantage of VI(M). I just use IDE's or Emacs / VS Code (w/ X
Forwarding more recently) personally makes it easier to find the fancy
features with a UI.

I'll share that time travel feature to my VIM coworkers maybe it'll save their
tail sometime.

~~~
chongli
Vim also has persistent undo. Check out the options:

    
    
        undofile
        undodir
    

These will cause vim to store all file histories into files within that
directory. Now you can close and reopen vim and continue undoing as much as
you want!

~~~
marcoperaza
Do you know if there’s a way to make “normal undo” stop at the beginning of
the current session, then have some special command or confirmation that I
indeed want to move further back? I almost never want to undo past the current
session, but occasionally I do.

------
pera
OP should consider using buffers: you can _:ls_ to display the list of buffers
(which I have mapped to _gl_ ) and then _:bn_ (where _n_ is a buffer number)
to go to some specific buffer. Also, in the same fashion of _gt_ and _gT_ for
tabs, I mapped _gb_ to go to the next buffer, _gB_ to the previous one, and _g
space_ to go to the last one. IIRC all these key bindings are unused by
default. In my opinion tabs are more useful/interesting when you work with
multiple windows layouts.

[https://github.com/pera/vim/blob/master/.vimrc](https://github.com/pera/vim/blob/master/.vimrc)

~~~
haberman
I use CTRL-j and CTRL-k to cycle through my tabs. It's like j/k except for
tabs instead of lines:

    
    
        map <C-j> :tabn<CR>
        map <C-k> :tabp<CR>
    

I also alias ":split" to ":tabe", because my fingers will be forever wired to
type ":split <filename>" when I want to open a new file.

    
    
        cnoreabbrev split tabe

------
bArray
I use (Vim IMproved - not vi) vim all the time. I find it interesting to see
what features other people tend to use in vim, there seems to be some minor
differences in their workflows, but it's not clear who "wins" the productivity
battle.

I only use a _very_ small number of it's features:

* `:tabe` Create a new tab

* `:e .` Start browsing files in that tab

* `:w` Write the file

* `:q` Quit the file (`:q!`, seriously, please do quit the file)

* CTRIL+SHIFT+UP/DOWN To switch tab (doesn't reliably work on every machine)

* `/WORD` To search for something

* `:NUM` To go to a specific line

* `i` To insert

* SHIFT+V to select lines

* `d` To delete lines

* `x` To extract lines

* `y` To "yank" (copy) lines

* `p` To paste lines

>Here are a few things I wish I could do better:

I don't have a great memory, so memorizing more than what I use every day is a
little too much. One thing that I'm working on remembering is the ability to
replace strings (although I don't really like regex).

>Would I learn Vim again?

I'm yet to experience anything compelling enough to stray me away. The
advanced features are there if I ever need them, but for the most part I am
free to have a lightweight editor.

~~~
johnboyer
>Vim IMproved

Oh, so you are using an improved version of Vi IMproved? ;)

~~~
imiric
Emacs + evil-mode, presumably. :)

~~~
tom_mellior
I need to use Emacs rather than vim for some things (Proof General, mostly),
and I was surprised how well evil-mode works. It's only undo that I don't get.
From vim I'm used to be able to undo as many editing steps as I want. In evil-
mode, I find that if I type "u" too many times, it runs out of undos to do and
starts undoing the undos (i.e., it starts _re_ doing things I want to go
away).

Also, search uses different word separators from vim: In vim "foo_bar" is a
single word that will be skipped by pressing "w". But in evil-mode the "_" is
a word separator, so the above is _three_ words. That breaks my flow every
time.

Some of this might not be due to vanilla evil but due to the fact that I'm
using it through Spacemacs.

This is my two cents. If by any chance anyone would know off the top of their
head how to fix these, I'd be greatful.

~~~
triska
For linear undo and undo branches, undo-tree.el is required:

[https://www.emacswiki.org/emacs/UndoTree](https://www.emacswiki.org/emacs/UndoTree)

Regarding "_", you can set up Emacs to treat _ as _word constituent_ by
modifying the _syntax table_. For example:

    
    
        (modify-syntax-entry ?_ "w")
    

For more information, please see:

[https://www.gnu.org/software/emacs/manual/html_node/elisp/Sy...](https://www.gnu.org/software/emacs/manual/html_node/elisp/Syntax-
Table-Functions.html)

~~~
tom_mellior
Awesome, thanks! I'll try these.

------
darthlucio
I know you said that you like maintaining a super minimal .vimrc, but fwiw
there's a couple of plugins that really helped me with the workflow issues you
mentioned struggling with:

> Jumping around in longer texts: I know the basics, like searching (/),
> jumping to a matching bracket (%) or jumping to specific lines (for line 10,
> type 10G), but I still could use symbols more often for navigation.

vim-sneak is real nice for this, and has turned into one of my most-used
movement commands [https://github.com/justinmk/vim-
sneak](https://github.com/justinmk/vim-sneak)

> Using visual mode for moving text around: Sometimes it can be quite
> complicated to type the right combination of letters to cut (delete) the
> text I want to move around. That's where visual mode (v) shines. It
> highlights the selected text. I should use it more often.

vim-move was a game changer for me [https://github.com/matze/vim-
move](https://github.com/matze/vim-move)

> Tabs: I know how tabs work, but all the typing feels clunky. That's why I
> never extensively used them. Instead, I mostly use multiple terminal tabs or
> an IDE with Vim bindings for bigger projects.

This is worth a read: [https://joshldavis.com/2014/04/05/vim-tab-madness-
buffers-vs...](https://joshldavis.com/2014/04/05/vim-tab-madness-buffers-vs-
tabs/). Buffers + vim fzf is a really nice workflow
[https://github.com/junegunn/fzf.vim](https://github.com/junegunn/fzf.vim)

~~~
omn1
OP here. Thanks for the tips. I've used vim-sneak for quite a while (it's even
built into Visual Studio Code's Vim plugin), but it just didn't work with me.
I'm more of an easymotion ([https://github.com/easymotion/vim-
easymotion](https://github.com/easymotion/vim-easymotion)) type of guy. But
even easymotion vanished from my workflow, because `/` works almost equally
well for me and easymotion is not available on every system I use.

I guess what I'm trying to say is that I became more and more conservative
about what external dependencies to rely on, because as soon as they become
part of my workflow, I can't easily go back because they become part of muscle
memory.

For vim-move I use `V` + `j,k` for the selection followed by `d` to delete and
`p` for paste. Works quite well for me. The problem that I have with visual
selections is, that I often want to "grow" a selection from inside of my
current position. Say my cursor is inside parentheses, I'd like to hit a key
repeatedly to select an ever growing region of text: first the entire content
inside the parentheses, then including the parenthesis, then the entire line,
then the entire function and so on. Is there a plugin for that?

Thanks for your article on buffers. Looks like a great workflow. What I'd like
to have on top of that is a way to open a buffer based on the contents of a
file. Say I have a file somewhere that contains a specific function,
`myFunction()`. I'd love to just start typing `myFu` and vim would suggest the
correct file to open. Bonus points for handling typos, e.g. `ymFu` should also
work.

~~~
edanm
I think vim-expand-region ([https://github.com/terryma/vim-expand-
region](https://github.com/terryma/vim-expand-region)) is what you're looking
for.

It allows you to repeatedly 'v' to select ever larger parts of text.

~~~
omn1
Well that's exactly what I was looking for. Thank you!

------
JepZ
After using vim for a few years now, I noticed how I changed from thinking
about text as characters to thinking about text as lines, which lets me create
much cleaner code (independently from pretty printers).

When I selected code via mouse in the past, I selected it from character to
character. In vim I tend to think line-wise so I can yank, paste, delete code
per line which makes sense in many scenarios.

~~~
hzhou321
I have been noticing this effect as well, and I was thinking that there needs
to be a change in how we design programming languages. The old programming
languages are treating characters or words as atomic units, but human mind
does not really work at words. We work at sentences or lines. Each line can
have its own context and can host more flexible syntax. On one hand, the
programming languages can be more expressive when designed toward line units
-- lines naturally can host more vocabulary than isolated words; on the other
hand, the compilers and parsers can actually be simpler or smarter, as lines
pose boundary of syntax and errors may be confined and easy to recover.

~~~
earenndil
Lisp?

~~~
ludston
Yes and no. In my experience vim is great for manipulating s-expressions
because it has expressions like da( which means "delete everything between the
parens wrapping the cursor".

But no, many lisp dialects have a tendency towards nesting expressions which
will force them accross many lines which doesn't match up with ^^'s idea of
keeping lines context free.

~~~
earenndil
Sure, but then you just say that the atomic unit is not the line, but rather a
list.

------
rjkennedy98
Surprised to see that he's gone back to an empty vimrc after years with high
customization. To me customization is such a great part of vim that I can't
imagine being without it. For instance, I have shortcuts to find and replace
on visual selection. I also have at least 5 plugins in my vimrc that are
absolutely necessary for my workflow. Pure vim is nice if you need to
occasionally edit files, but if you use it as your prime editor its not enough
without customization.

~~~
aaachilless
My experience has also been with a decaying amount of customization. As I get
better with Vim I learn more and more how to do things in a "Vim-native"
manner which I had previously needed plugins for. For example, when I first
started using Vim, I relied heavily on NERDTree. These days, netrw works
perfectly fine for me.

~~~
kqr
This is what I tend to hear from Emacs people too. Not an absence of
cpnfiguration, just a surprisingly minimal amount because to them, the
defaults start making sense. I have no idea if this is because the human
learns the editor, or if it is the editor shaping the thoughts of the human,
but it sounds nice and I sort of wish I would get there soon.

------
markrian
One built-in feature (not enabled by default) that I absolutely love is
persistent undo. _Love_ it.

Basically, undo trees can be persisted across vim sessions. Have a read via
":help undo-persistence".

~~~
nitemice
Pairing this with undotree[1] is really handy, as it allows you to see your
full edit history, branches and all, and jump back and forth.

[1] [https://github.com/mbbill/undotree](https://github.com/mbbill/undotree)

------
Theodores
One current problem I have with Vim is those linux distributions where someone
- maybe the VPS vendor/hosting company - put in some mystery .vimrc file
somewhere that makes the editor apparently more friendly for new users. So you
copy and paste a line to your mysql config file, to restart the database
service and find that nothing has changed. So then you edit the file again and
discover that the mystery .vimrc file has added a '#' at the start of the
line.

Another one that gets commonly messed with is the search. If you use '/' then
you should expect the search to begin when you press the enter key, with the
usual 'n' to go to the next match. But no, some mystery .vimrc file has made
this more newbie friendly, so the search happens before pressing enter. Which
is not what you want if standard, expected behaviour is expected.

For reasons of teamworking I have moved away from vim plugins in the IDE, for
this I have had to buy a new keyboard. Normally I do not use a full keyboard
as that number block on the right hand side has no value whatsoever to me. If
I was right handed and did accounts then sure, that would be a handy feature,
but the number pad is really just not helping for me, most of the time,
particularly on a laptop where the numpad skews the keyboard off to the left
hand side. I want the spacebar in the centre, not an inch or so off skewed to
one side.

So my new discovery - the gaming keyboards that have the home/end and arrow
keys but no number block - I think they are called 87 key keyboards. These are
great if 'moving away from vim' as the 'home/end' keys make it easy to get to
a start/end of a line. Under normal circumstances with vim there is no need
for these extra keys, to add to the end of a line or the start is just a
matter of using the right keystroke, just 'o' or 'a' is all that is needed
with the magic that is vim.

Moving away from vim is quite dangerous, for a while you find programs
breaking because there is a block of 'kkjjj' or an 'i' embedded in there
somewhere!

~~~
wibble10
This can almost certainly be avoided by typing “:set paste” before entering
insert mode and pasting. Give it a try!

------
keithnz
The point in the article is that the Vim keyboard bindings are most useful.
Most editors have an option or plugin for that. That's what I use mainly. For
instance I use Visual Studio + Resharper + VsVim ( + AceJump +
RelativeLineNumbers) as my main development enviroment. I also use webstorm
configured in a similar fashion. Visual Studio and R# understands the code and
how to manipulate code far better than anything in the Vim world does, but I
use it in combo with Vim keyboard bindings and it becomes incredibly quick to
do things.

I don't actually use Vim itself very much ( I still use it for various things,
but its not my main editor ). Its nicest attribute is for quick editing tasks
it loads quick and can load very large files.

------
bitofhope
Vim user here. One thing I rarely see discussed is the idea that vim is not
about speed. It's about comfort.

Maybe hjkl is a little faster than arrow keys. I don't care. I just like doing
my editing with less hand movement.

I'm sure that I could perform many operations faster with a mouse. Select
text, drag it a little below. Probably faster than d}}p even. The point is,
mouse is finicky and annoying. The context switch between typing and moving
the mouse breaks flow. Aiming the pointer is hell, and even worse if the
target is small or the mouse of low quality. Anyone who plays click-heavy
video games (RTS, many MMOs, 4X) can probably understand the pain of dragging
the cursor between two points and clicking repeatedly.

Vim is terrible. It takes a while to learn and when you've learned it well
enough you're spoiled and everything else feels painful. Vim is the closest I
can get with current technology to a neurally linked brain-controlled editor.
It feels like the cursor obeys my thoughts, not the limits of my manual
dexterity. The next step would be an editor actually wired to my brain where I
just think what the text should look like.

------
daenz
One thing I noticed when working with people who are only familiar with IDEs
for coding and GUIs for version control: they're helpless on remote servers.
If they need to jump on a box and debug an issue live, they just can't do it.
For me, using tmux + vim + git cli locally, my workflow remains exactly the
same remotely.

Tools are nice, but don't let them make you weaker.

------
JoshMnem
Tabs are great for organizing groups of related files. They are different from
other editors that only let you have one file per tab.

With Vim you could split a tab with a frontend HTML and CSS file, and have a
couple of backend files in another tab. Then `gt` or `gT` to switch between
the groups.

If you use nerdtree, `t` opens a file in a new tab, so you don't need to type
`:tabnew` often.

------
FreeFull
Nowadays, I prefer Kakoune ( [http://kakoune.org/](http://kakoune.org/) ) to
vim. Being based on selections rather than movements feels much nicer. It
feels a bit like always being in a kind of visual mode. That said, there are
the following caveats:

* Vim tends to be installed/available almost everywhere, Kakoune isn't

* Vim has a much bigger ecosystem

* There are some very advanced features hidden in vim that most people don't know about. If you depend on those, substituting vim with another editor can be hard.

~~~
majewsky
I've been meaning to look into Kakoune for some time now. How steep is the
learning curve for a long-time vim user?

~~~
FreeFull
Some of the keys match up, but many are different. The actual way of thinking
and composing actions while you're editing is similar, although I'd say
thinking in terms of selections rather than movements makes things easier.

------
cgag
It's highly overstated how hard it is to learn imo. I would learn it again
without a doubt.

~~~
mattbreeden
I ran 'vimtutor' twice and felt comfortable enough to switch. I think the only
reason people think it's so difficult is they maybe try to go too deep too
fast?

~~~
didymospl
I repeated vimtutor for a few days in a row trying to following this nice Vim
learning plan [1] I saw on HN and I gave up trying to switch to Vim as my main
text editor after that. Even though I knew how to perform most of the basic
operations, the fact I had to switch to normal mode to do anything more
complex than editing of the current line felt just too unusual to me. I mean,
I'm comfortable editing files on remote servers in Vim now but I don't think
I'd ever be considerably more productive in Vim than in IntelliJ/Sublime.

[1] [https://medium.com/actualize-network/how-to-learn-vim-a-
four...](https://medium.com/actualize-network/how-to-learn-vim-a-four-week-
plan-cd8b376a9b85)

------
gwn7
> I don't use arrow keys to move around in text anymore but forced myself to
> use h, j, k, l. Many people say that this is faster. After trying this for a
> few years, I don't think that is true (at least for me). I now just stick to
> it out of habit.

Sounds like he's not a touch-typist.

And as a general note; learning and mastering vim can hardly be a pleasant
activity for non touch-typists, or otherwise typing heroes.

~~~
mcjiggerlog
I don't see why that means he's not a touch typist?

I actually use both hjkl and the arrow keys. Arrow keys are useful for moving
the cursor in insert mode.

~~~
gwn7
Because the hjkl key bindings are invented by touch typists for touch typists.

Touch typists are more comfortable with using hjkl than the arrow keys as the
hjkl keys reside in the home row; so they are extremely cheaper to press than
the arrow keys for touch typists.

And, you don't need to move the cursor in insert mode. vim and more generally
the modal editing concept is invented just so you don't do that. I'm not sure
if you are a rookie vim user or have a niche use case that requires moving the
cursor in the insert mode.

I think it is funny that vim supports arrow keys at all. It's probably to
reach a wider audience, and for compatibility. And a related fact is that the
original vi doesn't support using arrow keys in insert mode in the way you
expect.

------
Zelphyr
I read an article a few years ago, the name of which escapes me. It was
something like “Idiomatic Vim” or “Linguistic Vim”. I would love to find that
article again, if anyone happens to know based on the sparse info I’ve just
provided, I would greatly appreciate it.

One of the things I learned was that you can do things like yank to a
character. In other words, if your cursor is at the beginning of “The quick
brown fox jumped over the lazy dog” you can type ‘ytx’ (Yank To to the “x”
next “x” character) and it’ll yank “The quick brown fo”. That’s really handy
with code, I find.

~~~
Lio
To sure about your article but this sort of thing is the subject
[https://pragprog.com/book/dnvim/practical-
vim](https://pragprog.com/book/dnvim/practical-vim)

It’s full of tips on doing things “the Vim” way without plugins.

------
spicyusername
All of the points in the "Some things I wish I could do better" section are
the reason I use a regular memorization free-ish IDE.

Out of the box the things I want to do are easy (multiple files, manipulating
structure of blocks of text, searching and manipulating information across my
project simultaneously) and the things that aren't are rare (Add a dollar sign
at the beginning of the next 13 lines).

I know how to use vim solely because it's necessary to edit files in a
terminal.

~~~
gwn7
> Out of the box the things I want to do are easy

Easy what? Easy to learn or easy to do?

They are arguably easier to do in vim once you learn the proper method. Just
not as easy to learn.

That a common trade-off shared by rather elaborate tools.

~~~
hungerstrike
Yeah "once you learn the proper method" is the key phrase here. The proper
method being "use rote memorization to learn about things which could have
easily been made available via some discoverable visual mechanism".

GUIs make things easy to learn and easy to do. Especially on an OS like
Windows where you can drive the entire UI with just the keyboard and about a
handful of well-known keyboard shortcuts.

So what's your point? Perhaps you're using a Mac or some other barely usable
desktop system that has crappy keyboard acceleration for the UI?

~~~
gwn7
> The proper method being "use rote memorization to learn about things which
> could have easily been made available via some discoverable visual
> mechanism"

I already said that this is a trade-off. Nobody's claiming that the vim way is
the "right way" to do text editing. If you prefer a discoverable visual
mechanism, you can go with it.

But some people clearly prefer to "use rote memorization" because they
obviously gain something out of it.

And believe it or not, "rote memorization" is an essential part of our
everyday life. Without it, you can do nothing. I don't see any harm in
somebody deciding to apply it to text editing as well. Obviously thousands of
people decided to do that, looking at vim's popularity.

And lastly, the memory we are talking about here is the muscle memory. You put
something there once and it's done. Using vim is very much like riding a
bicyle in that sense.

Would you prefer to have a bike that has labels on the pedals, brakes, gears;
and prefer to go through those labels each the you need to use one of them?

Memorization allows you to do things without thinking. The mantra of vim and
similar tools is to enable you to become one with the tool just like you
become one with your bike, your tennis racket, your sword (!), whatever. Touch
typing really helps here as well.

You can't understand that without investing enough time to that. (You don't
have to. But you don't have to criticize it without really knowing what you
are talking about either.)

I use Arch Linux. Keyboard accelaration is perfect.

~~~
hungerstrike
Define rote: mechanical or habitual repetition of something to be learned.
This is not something that is part of every day life at all. After school the
only time I had to repeat something over and over with any kind of frequency
at all was when I was learning vim.

> Would you prefer to have a bike that has labels on the pedals, brakes,
> gears; and prefer to go through those labels each the you need to use one of
> them?

That's not a really good analogy because my memory also works for GUI apps.
However, I didn't have to use a rote method to get there. I just use the GUI
with its labels and visuals helping me along the way. If I don't use something
for a while, the labels and other visual elements are there to help me out.

> Memorization allows you to do things without thinking.

Yes and your memory works with GUIs too. But again, I didn't have to put
myself through weeks of exercises to use a GUI.

> You put something there once and it's done.

I don't think so. Time is a thing and particularly with regards to lesser used
features - you'll find yourself looking up things that you once knew.

> I use Arch Linux. Keyboard accelaration is perfect.

Sure it does... at least until the next update amirite?

~~~
gwn7
> Define rote: mechanical or habitual repetition of something to be learned.
> This is not something that is part of every day life at all.

I can understand that. It was already clear that you are not the type to give
time to learn about rather elaborate tools that have higher learning curves
than the average. That's ok. It may not be a part of YOUR everyday life. But
not everybody is living your life.

The difference between you and me is that you are implying that vim is
pointless and wrong. I'm saying that everybody should go with whatever works
best for them and that every approach has their benefits.

Also, attacking my operating system has nothing to do with this discussion.
Not a very effective rhetorical method.

~~~
hungerstrike
I agree that everybody should use what works best for them. So there’s
definitely value in that.

Typically when I pose an argument in a thread like this, about a technology
that I don’t prefer, it’s due to the fact that a multitude of users have
badgered me over my own preferences elsewhere, saying that their technology is
clearly superior.

I use Windows, Linux and Mac in that order of frequency and I like them all
for different reasons and I dislike them all for different reasons. A ton of
users on HN react badly to anyone who isn’t just like them. So, I was being a
bit defensive sorry.

------
archi42
Regarding tabs: I bound F2 to previous tab, F3 to next tab and F4 to new tab.
Besides highlighting the current line, I think this is my most important
customisation.

~~~
pault
Isn't `gt` and `gT` faster? You don't have to move your hands!

~~~
JoshMnem
I like `gt` and `gT`, because they are available out of the box on remote
servers too.

~~~
Lio
Also you can use <num>gt to jumpe to, say, second tab.

------
eadmund
Wait until he discovers emacs!

I don't mean that rudely, it's just that emacs can do everything vim does &
far more.

~~~
falcolas
To paraphrase the OP's own words, he likes vim because it treats editing as a
first class citizen. Editing in emacs, without something like evil mode, is a
second class citizen - it requires key chords to do.

And, if I put on my snark mask for a moment, at the point you're using key
chords to do your editing, why limit yourself to emacs? A fully programmable
editor is now the norm, not the extraordinary.

Taking my snark mask back off, I realize there are no editors currently which
are as fast an extensible as emacs yet; Atom is close, but bloated and slow in
comparison.

------
hajderr
Long time Vim user here. Just switched to Emacs primarily. Use Vim for small
tasks

------
nurettin
Only 10 years? Feels old, man.

------
KasianFranks
Vi

------
hungerstrike
Whenever vim comes up I see someone trying to sell the audience on some
"amazing", obscure and rarely used feature that users of other editors should
be jealous of... However, it seems to me that if anyone _actually wanted_
those features then they'd be standard in other text editors and we'd have
them already.

But what I find really hilarious is that whenever these features are mentioned
I see people who have been using the thing for a decade say "I never knew
that!" or they dicker about what the commands actually are.

------
alexandernst
"And I still can't find how to quit"

~~~
bagol
Did you mean, "It's hard to quit from using vim once you get accustomed to
it."? :)

