
VIM Pays Excellent Dividends: Learn it early, if you can - pathdependent
https://medium.com/@generativist/vim-pays-excellent-dividends-814241804984#.8wqyr9ae9
======
mnm1
If I could go back in time and change one thing about my computing, it'd be to
learn proper ergonomics and posture from the beginning and avoid the pain that
came later. I often have to type slower than I can to avoid pain. I realize
now that all the frenzy to get the ideas out as quickly as possible probably
gained me very little time in exchange for a lot of pain. These days, a tool
that might increase my data entry speed by 5% doesn't even make it onto the
radar because my primary concern is my health and getting rid of RSI. Speed is
antithetical to that. Interestingly enough, whether going full speed as before
or in a more controlled manner like now, my actual productivity is the same.

------
muh_gradle
I've used vim and emacs. I can't claim to be an expert on either, but I am
somewhat comfortable with vim and it can be convenient for any unix straight
out of the box. But I found it to be fairly overrated even with all these
claims of boost in productivity. Just use Sublime Text in this day and age and
use the spare time you would've had to learn vim and do something more useful.

~~~
ndh2
I've always been wondering if there is some secret that I've been missing and
that these VIM or Emacs gurus keep to themselves which makes them "more
productive".

All these abstract claims in blog posts and on forum pages about productivity
are completely worthless. Go watch a stream where you can actually see someone
program. Maybe you'll pick something up that they do better/faster/more
elegant than you. Other than that, the best advice is to ignore these kinds of
topics.

~~~
bakul
I don't know about being more productive but I use commands like 3cwfoo<esc>
to replace the next three words with foo. Or 2cf,foo<esc> to replace
everything including the second comma on the current line. Or some : command.
I no longer even consciously think about such things as how vi works is
something I know in my fingers. Originally I learned such things only after
repeating some command multiple times, thinking there has to be a better way,
and then learning the more powerful commands. The core set of vi commands is
quite regular and once you learn something it can be applied in other
situations.

If I am working with another expert vi user it is very easy to give him
precise instructions - I can just say things like replace the second foo with
bar on every line starting with a space and he'd know to type the correct :
incantation.

The key is to pay attention to your inner voice saying "there has to be a
better way" and doing something about it! Bottom line: learn to know how to
use your everyday tools well.

------
gshulegaard
Came here to make a comment about other utilities in the same vein...but the
author already did!

> [4] Or, emacs. Or, really, any other tool that you 1) use constantly; 2) is
> almost universally applicable; and, 3) makes you more productive.

Nice to see consideration for other tools in a piece like this.

~~~
pathdependent
Thanks!

I put VIM in the title because 1) it's got a recognizable identity to pull in
readers and, 2) I use VIM. But, in a weird and almost recursive way, editor
wars are kinda like language wars. If it gets you that 5% (or more) boost,
great! But, the differences between them often washes out.

~~~
karmajunkie
Yeah, the most important thing is to know your tools of choice really, really
well. vim never made me more productive—being able to do what I needed to in
it quickly did. I could just as easily have used emacs (had I learned that
first), or atom (had that been around back then) or <insert favorite
editor/ide here>.

~~~
pathdependent
Yes.

The had-I-learned-it-first concept is something I didn't mention, but do think
is important. And, often it works in an inhibiting way. With an IDEA-like rich
IDEs -- which I think is a great tool, esp with VIM bindings! -- you get such
a boost from things like good contextual auto-complete, that you never feel
the need to learn it more deeply.

------
nxc18
This is a huge thing I've been thinking about lately.

Very recently I was a pretty staunch advocate for IDEs and thought the whole
VIM situation was crazy. It is unintuitive. It doesn't come bundled with lots
of useful tools. It takes some configuration if you want nice things (e.g.
file tree on the side).

Over winter break I decided to really commit to becoming productive in VIM. I
stopped using VSCode and I stayed away from other IDEs, even as I was learning
Java Spark and digging into some Python projects.

I didn't notice it at the time, but VIM has made me much more productive, even
with my very minimal knowledge (I learn new commands even for basic things all
the time). Ultimately, the fact of the matter seems to be that the
keyboard->mouse->keyboard transition is _really_ slow. Going to Visual Studio
(I'm learning Win32 and I don't want to do that without IntelliSense) after ~2
months in VIM is almost excruciating. I'll be loading up the VIM plugin pretty
soon

The long and short of it is, and my advice for everyone who asks is, learn VIM
(and other command line tools) as soon as you possibly can. I have no loyalty
to the UNIX philosophy or ecosystem, but take it from me, you'll be glad you
did.

~~~
omellet
I use VsVim in Visual Studio, highly recommended.

------
tetraodonpuffer
When I read articles about vi/vim being great for coders I always wonder how
you deal with having to use the same part of your brain for writing the code
you are writing and to "code vim commands"

I mean, I understand it's attractive to a programmer's mind to be able to do
fancy 'replace the next 3 words with x' and so on, and compose them in vim's
language, but if I am deep in an algorithm the last thing I want is to have to
context switch to "programming my editor"

When doing editing tasks in a more visual as opposed to programmatical way, it
feels more that my "coding brain" is free to continue working on the algorithm
at hand while some other part of my brain deals with the moving of text
around.

Keeping the right cursor key pressed for 1 second is a lot slower than doing
some fancy move to the X word in the line, but if engaging my brain to create
the composite "move to the X word" command takes me out of the "flow state" I
am in, it is way way way more expensive in the long run. In the end what you
want is to be the most productive, and the most productive could mean that you
are using the editor less efficiently because the more efficient parts of your
brain are busy doing something else.

Not sure, maybe somebody that started with vim as their first editor does not
have this context switching issue, I personally started with emacs and
remained with it and I have my emacs config full of hyper / super / meta / alt
/ control / shift shortcuts and tons of cool packages, but while I am deep in
coding flow state I still use the cursor keys with minimal package help
(outside of multiple-cursors and macros sometimes) to avoid getting
distracted.

~~~
btschaegg
I am actively using a vim-like control scheme for almost any text I write for
about 15 months now. I certainly am not the most proficient in it (in fact, I
suspect I could do much better if I weren't "confined" to VS and VSVIM at work
- I use Spacemacs privately), but I have enough "training" to make the basic
moves I need unconciously. If you come from more limited IDEs or text editors
this alone is already well worth it. And at the moment when you understand the
basic gist of macros on top of that, it basically becomes a superweapon.

I'm sure there's something to get out of being an "expert Vim user", but even
if you're starting out, there's already much to be gained from the simple
routines. I find the notion of a "Vim Kata" very compelling as a metaphor,
since it's really the repetition that teaches those "reflexes" at first.

I don't know how much an avid Emacs user could get out of it though. I guess
that comes down to personal preferences. I couldn't get myself to memorize all
the weird key combinations for example, but I quite like Spacemacs' mnemonics
system.

------
iLemming
I'm a diehard Vim fan. I use Vi-motion keybindings everywhere. System-wide. In
every single tool I use. I don't ever touch arrow keys. I don't need to. I
rarely have to use touchpad. It feels empowering to be able to do things the
way I do. I don't think anymore about how and what I need to do to get quickly
where I want to be - I just intuitively do it. This is probably how
controlling things with your mind would feel. The downside? I can't work using
one hand anymore. It just feels weird.

Vim is awesome. It's not an editor - it's a lifestyle. It's telling the
machine who's the boss. It's staying "in the zone". It's cutting through the
code like slicing butter with hot knife.

So, one day I woke up. I realized that Emacs can be better Vim than Vim. Hold
on. Before throwing stones at me do one thing: give an honest and heartfelt
try to Spacemacs. I guarantee it - you will be amazed.

------
KanyeBest
> let’s say it makes you 5% more productive > It’s an extra twenty minutes a
> day

Author presumes 100% of programming time is spent typing/editing.

Is this really the case? I'd wager it's close to 10% for most people.

~~~
ThrustVectoring
It's closer to 10%, but that just makes having a fluid and easy editing
experience more important IMO. Editing tasks are interruptions at that level,
and you want to make it as easy and quick as possible to get your mental
models re-loaded into short-term memory.

------
lowry
I moved to VIM (ideavim, vimperator) completely once I started feeling
uncomfortable in the right palm.

Reducing the number of keystrokes per days is paramount to productivity
increase for me, nowadays.

~~~
bmc7505
If you like IdeaVim and Vimperator, try using a plugin called AceJump [1].
Like Vimperator, you can map the F key in normal mode to activate AceJump,
then start typing any visible character or string on the screen. We are
working on multi-monitor support and history, and would love to get your
feedback. Full disclosure: I am a contributor.

[1]:
[https://github.com/johnlindquist/AceJump](https://github.com/johnlindquist/AceJump)

------
jogjayr
I can't claim to have ever "tried" to get into vim - in the sense of ditching
my daily driver (Sublime/VS Code) and going 100% vim. I've done the vimtutor,
I even know how to do basic text editing (cut, copy, paste, find-and-replace,
visual mode highlight) in vim, plus some of those "magic" things where you can
repeat an action multiple times (:2wi or whatever). And I'll happily fire up
vim if it's something really quick, like making a list in a plain text file or
something.

So what's kept me from going 100% vim?

1\. Plugin/add-on support - I have no clue what's going on here. There's no
clear guidance on what to use (vundle? pathogen?). I haven't really grokked
how plugins really work - where do they come from? how do I search for them?
where are they really installed? how are they organized in the install
directory? do I need to care? etc (I'm aware this is all documented somewhere,
and maybe I just need to make more of an effort). Whereas in something like
Sublime Text there's an easily installable package manager that takes care of
all these things for you. And if you really care to learn, you can drop into
one of the packages and find easy-to-understand Python and JSON. Versus
vimscript, weird config files and whatever else vim uses to configure things.

2\. Multi-file support - Sublime has a Cmd + T fuzzy filename finder right out
of the box. With vim (for a beginner) your choices are either: a) open
multiple terminal windows with a single file in each, Cmd + Tab endlessly or
b) open multiple files in the same editor and drop out of insert mode every
time you want to switch files (way more keystrokes than Cmd + T or Ctrl + Tab;
maybe there's a toggle file shortcut in Vim also). I'm aware that there exist
plugins for fuzzy-file searching in vim also, but because of 1 I don't know
how to find or install them.

3\. Buffers and marks - I'm vaguely aware they exist. I'm not sure what they
do and why they're important. Again, this one is probably on me rather than
the tool itself.

~~~
7we4cniromfce
#1

I have been using pathogen since I started using vim, I can recommend it.
(copy paste directions to install: [https://github.com/tpope/vim-
pathogen](https://github.com/tpope/vim-pathogen)) And this is where you can
find vim plug-ins: [http://vimawesome.com/](http://vimawesome.com/)

After installing pathogen, to install a plug-in:

cd ~/.vim/bundle

git clone <url>

and you are done in most cases, some require adding a few lines on ~/.vimrc.

#2

There are multiple ways to work with multiple files. There are tabs in vim,
split screens, files in buffer etc, these are all without plug-ins.

~~~
jogjayr
> I have been using pathogen since I started using vim

Thanks for the recommendation. The trouble (and again, maybe this is down to
my lack of research) is that other commenters will recommend Vundle with links
to similar resources (and I've tried both Vundle and Pathogen, sometimes one
after another, ruining my ~/.vim dir :P). I can find all of these
recommendations myself but (maybe I'm wrong here) there's no clear winner in
the vim ecosystem. There's no single de-facto manager that's used by 90% of
all vimmers. Hell, I know people who I think maintain their vim plugins and
config and scripts using only git, so maybe a package manager isn't even that
much of a priority for many users.

> There are tabs in vim, split screens, files in buffer etc, these are all
> without plug-ins.

Agreed, but cursory research tells me that you have to type multiple
characters to switch between files. For example, the documentation page on
buffers:
[http://vim.wikia.com/wiki/Vim_buffer_FAQ](http://vim.wikia.com/wiki/Vim_buffer_FAQ)
lists about 20 different buffer navigations (bNext, bnext, bprevious etc (and
why there's no bPrevious is a big fat ¯\\_(ツ)_/¯ )) but not a single command
for toggling between two open files, a pretty common use case. Whereas text
editors like Sublime leverage the already-known (from using browsers) Ctrl + T
shortcut and provide you this really necessary action in fewer keystrokes (1
vs Esc (or your Esc shortcut key) + :bNext = 7 assuming there's no shortcut
for "Next" though there probably is).

> There are multiple ways to work with multiple files.

And maybe that's the problem. There are multiple ways to do everything
(multiple files, plugin management etc) rather than one "best" or
"recommended" way that works for most users. This is understandable for a
hacker's tool; options and flags rather than intelligent defaults. But it
leaves newcomers somewhat adrift. I'm not criticizing the tool itself; Bram
Molenaar and co. are doing an amazing job and we should all be grateful for
such a high-quality tool that's freely available on practically every nix.
Something like a canonical beginner's vim config that's aggressively
maintained and _everyone_ knows about would be nice though.

EDIT: How do you type a "*"?

EDIT: Looks like switching buffers (which I think is the same as toggling
between files) is :b#, which is still 4 characters vs 1.
[http://vim.wikia.com/wiki/VimTip686#Switching_to_the_previou...](http://vim.wikia.com/wiki/VimTip686#Switching_to_the_previously_edited_buffer)

~~~
no_protocol
Watch this three minute video or view the concise notes below it for some very
nice tips on handling buffers.

[http://vimcasts.org/episodes/working-with-
buffers/](http://vimcasts.org/episodes/working-with-buffers/)

> You can quickly jump between the active buffer and the alternate buffer
> using the command <CTRL-^>. Pressing it again takes you back to where you
> were before.

If you don't like the <CTRL-^> command for this, you could map it to something
else, such as the tab key, with a line in your .vimrc:

    
    
      nnoremap <TAB> <C-^>
    

\----

> There's no single de-facto manager that's used by 90% of all vimmers.

Most recently updated plugins work with each of the managers. I use a handful
of plugins with Pathogen, but the same plugins could be used with another
manager.

However, the latest release of Vim now includes a built in plugin system, does
that satisfy your need to have one blessed version?

[https://shapeshed.com/vim-packages/](https://shapeshed.com/vim-packages/)

\----

> 20 different buffer navigations

Keep in mind, all these commands can be shortened to the smallest unique
prefix. So with `:bn` and `:bp` you can go forward and backward. But if you
don't like typing three characters, just sacrifice something else by remapping
it in your .vimrc!

\----

> toggling between two open files, a pretty common use case

When I am working on two files at once, I'll usually put them both up at the
same time. If I have "a.txt" open and I also want to work on "b.txt" I can
type `:vsp b.txt" and now I have them up side-by-side. I can switch between
them with whatever command I have set up to do that.

~~~
jogjayr
Thanks, that video was pretty good and helped me understand buffers. If you'll
indulge me a bit more though, why does Vim warn you while switching out of an
unsaved buffer (and make you use !) if it's still going to keep your changes
when you come back?

> However, the latest release of Vim now includes a built in plugin system,
> does that satisfy your need to have one blessed version?

It absolutely does. I'm going to try it out!

~~~
no_protocol
Not sure if you'll find this delayed comment, but I can give it a shot.

There is a note on the linked video page about `set hidden`, but it doesn't
spend much time explaining it. If we open Vim and type `:help hidden`, we get
the following:

    
    
      'hidden' 'hid'          boolean (default off)
                            global
                            {not in Vi}
            When off a buffer is unloaded when it is abandoned.  When on a
            buffer becomes hidden when it is abandoned.  If the buffer is still
            displayed in another window, it does not become hidden, of course.
            The commands that move through the buffer list sometimes make a buffer
            hidden although the 'hidden' option is off: When the buffer is
            modified, 'autowrite' is off or writing is not possible, and the '!'
            flag was used.  See also windows.txt.
            To only make one buffer hidden use the 'bufhidden' option.
            This option is set for one command with ":hide {command}" :hide.
            WARNING: It's easy to forget that you have changes in hidden buffers.
            Think twice when using ":q!" or ":qa!".
    

The default state of `hidden` is off, so with that in mind, the explanation
basically answers why Vim warns you about switching buffers. If you switch
away, the buffer is "hidden" \-- Vim keeps track of what is in it and doesn't
unload it. That's probably what you expect, but can lead to loss of unsaved
data if you switch away from a buffer, work on some other buffers for a while,
then close Vim without coming back to the unsaved one. So by default, Vim
wants you to be explicit when switching away from a buffer that will become
hidden. In most cases you probably want to save it first.

Turning `hidden` on would remove the warning, you could switch away from an
unsaved buffer with `:bn`.

So if you want to always work with unsaved hidden buffers floating around
(view them with `:ls`!), you could add `set hidden` to your .vimrc.
Alternatively, you could set up a command to automatically execute a save
action every time you tried to switch away from an unsaved buffer. Notice that
`autowrite` is mentioned in the help text above. Running `:help autowrite`
shows:

    
    
      'autowrite' 'aw'        boolean (default off)
                            global
            Write the contents of the file, if it has been modified, on each
            :next, :rewind, :last, :first, :previous, :stop, :suspend, :tag, :!,
            :make, CTRL-] and CTRL-^ command; and when a :buffer, CTRL-O, CTRL-I,
            '{A-Z0-9}, or `{A-Z0-9} command takes one to another file.
            Note that for some commands the 'autowrite' option is not used, see
            'autowriteall' for that.
    

So if you added `set autowrite` to your .vimrc, instead of `set hidden`, you
could avoid the warnings by automatically saving the file, rather than leaving
it unsaved.

Hope this helps! One of the pain points of vim is that many of the defaults
end up being somewhat unexpected choices. Many people get over that by just
looking up someone's post online and copying in a bunch of settings. When you
do that, you don't end up learning much about navigating vim and understanding
the configuration process. You just end up with a new set of defaults that
might also not quite be what you want. I try to keep my .vimrc pretty plain
until I realize something could be better, then spend a moment to figure out
how to do that and add it in.

~~~
jogjayr
Thanks again!

------
aanm1988
> Most of the time, you shouldn’t use the Best Paradigm (TM) that exists. You
> should use the one that is good enough and works well in the language you
> are using.[3] Clever only gets you geek cred; conventions let you
> communicate well, both to others and to yourself six months later. That
> really cool pattern you learned that one time? You may never use it, and
> even if you do, the marginal gain probably won’t be that impressive.

Aren't these all reasons to not bother learning vim?

------
icc97
I find using Vim more natural when I'm spending time in the command line. I'm
an entrenched Windows user but I love the power of the linux command tools.

Now thanks to the GNU Tools packaged with Git, you get Vim and OpenSSH as
lovely extras. It's really nice to be able to switch back and forth between
editing on Linux via SSH in Vim and then back in Windows.

If you're searching around and moving files via the DOS prompt, getting your
daily Docker/Vagrant fix it becomes much more natural just to open Vim edit
the file and close it.

Plus you can add the solarized colours to the DOS prompt and you get lovely
syntax highlighting too.

~~~
orev
You know Cygwin has been around for ages and has done this forever. You didn't
need to wait for some big bundle of git to arrive on Windows for this.

~~~
Cpoll
I don't think you need to wait for anything; I think he's describing MinGW
that comes with a Windows install of Git. It's been around for a long time.

Cygwin vs MinGW is a whole other argument, of course.

~~~
icc97
Yeah the MinGW - it's just that Git packaged them all up nicely, previously I
always found there was a few missing tools. I find it much nicer to be able to
use those inside DOS.

------
lostmsu
> it makes you 5% more productive

Is there a study, or you just feel like it?

~~~
pathdependent
Full quote, for context:

    
    
       Being conservative, let’s say it makes you 5% more productive.
    

It's subjective. I'd like to see a before and after study, but empirically
measuring code productivity is -- a hard problem.

~~~
IshKebab
It might no be too hard in this case, since you're really testing editing
speed not code productivity. You could take a random selection of (small) git
commits and time how long it takes people to recreate them. That maybe gives
Vim an unfair advantage actually since the IDE features help more while
actually composing code, rather than just editing text.

Still I think it could be measured.

~~~
Veen
I think the focus on speed is counterproductive. Increased productivity isn't
the only — or even the most important — measure of value.

I enjoy using Vim (Emacs Evil mode these days) because I can edit more fluidly
without having to shift focus and context switch. My hands stay on the
keyboard, my eyes stay on the screen, and I don't have to think about "how" to
achieve my goals — I just think about what I want to achieve and muscle memory
takes care of the rest.

I might edit more quickly, but that's a side effect of using a tool that
allows me to focus deeply and maintain that focus for longer: both of which
are vital to flow and satisfaction with my work.

------
0x6a62
Ignoring generalities. For me, there are clearly times vim is the more
efficient tool. I find that to be more often the case than not. At a minimum,
learning it allows me to think about things differently than the standard
wysiwyg editors. These both make me a better dev. But ultimately, using vim
makes me happy. That's what matters to me, and should matter to others as they
pick their tools.

------
kentt
I've been interested in using vim and am not completely useless at using it,
but I haven't quite been able to commit to it. The main reason is that I'm not
sure it's any faster than using IntelliJs products well. Last time I mentioned
to a coworker who is a vim user, that I was thinking if switching to it, he
said he was thinking of switching to Idea after seeing me use it.

~~~
pathdependent
Buried in my footnote is the real gist is: learn your editor, deeply.

IntelliJ is a great tool, too.

~~~
brootstrap
VIM'er here. I use IntelliJ-Pycharm when i'm really strappin in for a good DEV
session. Plus you get the ideaVim plugin and i've got the same VIM magic I
know and love. Plus all the fancy IDE stuff. Some will say you can upgrade VIM
to IDE level (project tree, auto complete, other fancies) which is totally
true. I dont got time for dat.

Other bonus for vi is that you are now capable of editing files on any unix
server in the world.

~~~
weaksauce
spacemacs is a pretty well integrated, community sourced configuration of
emacs that has a lot of sane defaults out of the box. add a few layers for
your favorite languages and you are off and running. magit and org mode are
both excellent reasons to use emacs. the vim bindings are some of the best i
have seen in an emulator as well.

------
nunez
agreed, 100%. I used to be a GUI diehard. Then, I was told about emacs and
became an emacs fanatic. But the difference between emacs and vi/vim is that
you can count on vim not only being on any system anywhere, but behaving in
almost the exact same way anywhere.

vim is timeless.

