
Why, oh why, do those nutheads use vi? (2007) - chdir
http://www.viemu.com/a-why-vi-vim.html
======
pinkunicorn
I basically started learning Vim because.. well it was a hipster thing. The
first two years, I really did not know how to actually learn it. All I would
do is enter insert mode, move around with arrows and ":wq". But then after 6
months, I started with basic commands, like "55gg" to move to the 55th line
etc, "G" to the last line and "gg" to the first line. Then came buffers, I
started opening multiple files and started using minibufexplorer(my entry
point into plugins). This went on for another 6 months. Next came actions and
boy oh boy, I became the hipster vim user in college. While editing CSV
files(like deleting all instances of a particular row having text "abc"), I
used Vim instead of awk/sed just because I wanted to learn more. Fast forward
a year, I call myself a basic vimmer and superior to others at my workplace by
just knowing search, moving around, actions, buffers, a cool autocomplete
plugin and other plugins here and there.

Throughout the learning process one thing I observed was that, its just not
enough to read about a cool article about Vim and leave it there. I would keep
repeating the sequence of actions mentioned in the article atleast ten times
every day and would find some usage for it during programming. I would
intentionally force myself to use it, until at some point, the action I just
learnt magically comes in as a replacement for a dumb action I was about to
do. At that point I would know I've mastered it.

~~~
p0nce
I'm still stuck in the first step because I have simply no interest in
learning vim. I only know a small subset of commands. No I feel a bit like
missing out.

~~~
jqm
I'm guessing a small subset of commands is about all that many productive Vim
users know. You don't have to know everything to make good use of the tool.

------
Illniyar
Frankly I find vim an hindrance to the type of projects I work on.

One of the most common things I use an IDE for is navigation (between files)
and vim is not very good at it compared to IDEs, here's why:

* no tabs

* no project structure

* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition

* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...

when I find myself actually writing code, it's usually a line or two in each
of several files (because modern programming paradigms tell us we should split
code as much as possible), or modifying some copy pasted snippet I found on
google - so navigation is extremely important even when editing.

beyond that, there are simply some things that help writing code that a text
editor cannot do:

* auto-complete(with annotation to tell you what the function variables are)

* debug inside your IDE

* run code-lint, auto-build on typing to detect errors, etc...

* auto refactor (I.E. extract method, move variable, extract class etc...)

* format all your files according to your pre-specified project guideline.

* sharing you IDE configuration with other contributors

* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.

There are probably projects out there where a full-featured text editor is a
real game-changer and is worth the days/weeks it'll take to use it
intuitively, but I never worked or know anyone who worked on such a project
(even when I started projects from scratch);

~~~
StevePerkins
Eh, half of this list actually IS possible with Vim, either through a plugin
or simply out-of-the-box keyboard shortcuts. The other half are features that
separate IDE's from text editors in general.

I do agree that I'm infinitely more productive in an IDE than I ever would be
with any plain text editor (e.g. autocomplete-hints, refactoring support, etc
etc). After discovering the JetBrains suite of IDE's some years ago, I can't
imagine using anything else for application development.

However, the point of vi/Vim is not so much the editor application itself...
but rather its keybindings and modal editing approach in the abstract. Those
concepts are decoupled from the actual editor, because every major IDE has
plugins which make them available in its environment as well. The "IdeaVim"
plugin for JetBrains IDE's is amazing, letting you mix-and-match between Vim
commands and normal JetBrains shortcuts in a very intuitive way (or at least
intuitive if you're familiar with Vim).

If you're happy with your current working environment, then rock on. But if
you're fluent with vi/Vim (and it _is_ a significant learning curve), then you
can absolutely have the best of both worlds. To me, arguing about whether to
use an IDE or an editor is pretty silly. But the question of whether or not to
use modal editing and a suite of standard shortcut commands _within_ an IDE is
a much more interesting matter.

~~~
lfowles
My biggest problem with vim is that I can get it configured with all of the
plugins to emulate a GUI IDE, but it does nothing to help if I can't remember
the shortcuts. Off by one character? Whoops, you activated the RootNuker
Plugin on Buffer 3. Discoverability is terrible, one of the few things that I
feel is actually faster with a mouse.

~~~
aidos
There's no doubt, vim isn't big on making it easy to find your way around.

I don't think that matters so long as you're methodical in your approach to
learning it. It's important to master the basics and then add new tools one at
a time.

The amazing thing about vim is that each new command can be composed with your
existing knowledge set, so just learning what, say, 's' does gives you a whole
lot more power.

Also, while the discoverability might suck, the built in manual is just
incredible.

~~~
lfowles
This doesn't apply to plugins however, which constitute most of what would
make Vim an IDE. Most of the core commands are pretty well thought out and I
have a nice keyboard map printed out just in case.

------
weego
_Yes, there are definite reasons why the vi /vim editing model is just
superior to any other out there_

Zealots trying to convert unbelievers is plain obnoxious. Your choice of
editor isn't a religion so use what you use and I'll use what I use and you
don't have to worry that what I'm using isn't what you are.

~~~
ai_ja_nai
Probably it's just driven by the use cases: most vi users (probably) come from
server side, where you don't have a mouse. Vi is particularly effective in
those circumstances

~~~
stephenr
If you're editing files live on the server, you're doing it wrong.

This argument ("Oh I use <insert console based editor> because I can use it on
my laptop or via SSH on the server") is fucking stupid.

If you can learn how to use fucking vim or emacs, you can learn how to use
configuration management - either through a "full blown" tool like
puppet/chef/ansible/etc or through config packages (if you're on debian) or
even through plain old shell scripts.

~~~
pas
Yes, yes, conf. mgmt. Yes, yes.

Except when it's not really your call. And you have to poke around files so
far down behind God's back through a shared desktop Enterprise VPN IE-only
plugin-fest, that you don't even know which way is 127.0.0.1, then you're
happy that you have vim on Dear Client's pointlessly supported RHEL boxes by
default.

And othertimes, when you want to debug something that only happens on a
live/production server.

Editing files on the server live is - in itself - not right or wrong. Doing it
as a regular workflow is what's bad.

~~~
AnimalMuppet
That's a long way from original claim that "the vi/vim editing model is just
superior to any other out there", though. "You may need it in some crippled
environments, so it's handy to know" is a considerably weaker claim...

------
pinzlert
I've been using Vim for about 2 years now, mostly because I can't figure out
how to exit it. ;)

~~~
pavlov
Isn't that one of the formative Unix moments for every newbie: some program
throws you into vi and you have no idea how to get out.

It's like getting your head stuffed into a toilet bowl at a boys' boarding
school. Afterwards, you feel like part of the gang.

~~~
hk__2
Emacs is the same: when you don’t know it you can’t guess you have to type
^X^C to exit it.

~~~
wz1000
Most people use the X client for Emacs, so you can just close the window in
most cases.

------
xixixao
For the article: If you try to argue for superiority, you should probably
check the alternatives first and give an example where your preferred choice
is obviously superior - the example of adding an empty body to each method is
a great example where Sublime with multiple cursors beats vim (sure you can
get them in vim to, but it doesn't show vim being superior).

For vim itself: I have seen friends trying to learn it. I have seen PhDs and
postdocs use it. I have seen coworkers use it. The only people who I could see
were editing text as fast as friends/PhDs/coworkers using Sublime were my tech
leads. The smartest most proficient and effective programmers I have ever met.
Everyone else was slower, at times wrestled with the editor (by this I mean
that they executed commands and had to redo them because they didn't do what
they wanted). I guess the conclusion is that people can learn to use vim as
proficiently as Sublime, but most will fail or it will take them years (and I
mean 5 or 10 years).

Actually, two of my tech leads, when I showed them some trick in Sublime were
like: I should look into this. Maybe I'll just boldly argue that vim is
inferior after all :).

~~~
jostylr
I started with Textmate, liked it, but then the community lost interest. I
followed them to Sublime. I never got comfortable with Sublime though it is
hard to recollect why. I just kept getting frustrated with it.

Then people started talking about Sublime 3, Atom, and all that editor
hotness. I wanted something stable, something I could learn once and be
comfortable with it being around for a long time. I had tried Emacs years ago
and found it unpleasant, to say the least.

I looked into Vim. It became very addictive but it does take a bit of time to
learn. I love the action followed by motion idea. I found the built in
tutorial decent as well as Painless Vim to be a decent starting point:
[https://leanpub.com/painless_vim](https://leanpub.com/painless_vim)

About a year into my Vim conversion, I get around decently and love doing the
editing stuff. But I do feel that I need to go over tricks and tips again.

------
fit2rule
I've been a vi user for 25 or so years, and I really only know a few commands
- how to search/replace, repeat last operation, search for the thing under the
cursor, yank/paste, #[cmd], block mode, set mouse=a, and so on. In that
capacity I have supported myself as a software developer, productively, with
much satisfaction in my selection of editing tool.

So I'm often quite delighted at learning new things with it, even still! And
to be frank, I think this is one of the things I most like about vim - even
though I've been using it for years, there are still undiscovered treats yet
to be revealed to me, over and over. When I discovered cscope integration,
some 10 years ago, it was like getting an OS upgrade .. in my editor! :)

------
wz1000
The vim commandline together with the power of regexs make it very convenient
to convert text from one format to another. It works something like
this([https://vimeo.com/15443936](https://vimeo.com/15443936)). I don't know
how many hours I've saved on things like this due to vim.

~~~
raverbashing
It would be good if they used extended regexes, but oh well...

~~~
jmcomets
Use \v after the first slash to turn on extended regexes. ;)

------
bsaul
funny how people pay attention to how fast it is to change a piece of text in
a editor. Most of my time programming is spent on a piece of paper or a
whiteboard designing my data structures and algorithms. Actual typing ,
especially with an ide providing auto completion, is the thing that takes me
the least amount of time, by far.

~~~
toxik
I don't believe that to be true, and I have never met a developer who thought
that to be true. Sketches and diagrams can design a large system, but at the
end of the day, unless you're a systems architect or something, you're going
to have to get your hands dirty.

~~~
edejong
The best and lowest-maintenance pieces of code our team has written were
carefully designed and thought out before a line of code was written. I'd say
20% of the actual work was coding, 30%/30% for design and testing and 10%/10%
for requirements analysis and deployment.

However, often we know that we don't know how to properly design something and
we start implementing too early. The end result is sth like: 50% coding, 30%
testing and the rest is squeezed into testing, deployment and requirements
analysis.

~~~
bsaul
Starting on a paper instead of coding directly is really the key to the best
quality software i've done.

Funilly i realized that very early at university, where i had to perform a
code exercice while on holidays, but forgot to take my computer with my me. I
did it on paper, then typed it when coming back home, and got the best grade.

------
Anthony-G
As a long-time vi/Vim user, I thought this article provides an excellent
explanation for non-vi/Vim users for the reasons why enthusiasts choose to use
such an old and unusual (for those coming from a GUI background) editor.

In particular, the author emphasises that you leave Insert mode as soon as
you've stopped typing. When I first started using Vim, I used to spend too
much time in Insert mode while moving around using the arrow keys.

 __What I learned from the article: __If you 're not positioned on a
parenthesis, the `%` command will “scan character by character to the right,
until the first one is found, and then moving to the character matching that
one”. Until now, I’d always been using one of the `f`, `;`, `T` family of
commands to move to a parenthesis or equivalent character. This will be a real
time saver.

------
father_of_two
I started using vi in the 90s and got very used to it. It's still my standard
text editor (the nvi implementation, that is).

I've never grasped vim. It was too slow at the time and the extended command
set consumed all the free keys I use to have available to do my own macros
(eg: 'q' 'g').

I reckon vim grew to be much more than an editor, it is now an editing
plataform, capable of so many things, and contains lots of shortcuts /
builtins for common text-editing situations.

The article above contains many vim-only commands. For example 'di>' ("delete
inner angle-block") doesn't exist on standard vi, neither the '>aB' ("indent a
Block").

~~~
geocar
vim is _very_ slow; "classic" vi, and more reasonable clones like nvi are much
faster _and that seems completely wrong to me_. It also has terrible defaults
(like kindergarden-useless syntax highlighting which only make it slower!).

I have hopes that neovim will sort some of that out -- it makes a certain
amount of sense that vim is slow because of some baggage it carries, but I'll
admit they aren't very high hopes: I've been using emacs recently.

How funny is that? That I use emacs because vim is too slow!

~~~
cturner
Haha. When I first this, I thought your problems might be from editing large
files with syntax highlighting switched on. Or doing PHP or JSP, which I've
found to struggle in the past. But then I saw the username.

Indeed, if you're writing lots of code with hardly any newlines (like k lang),
you will probably have performance issues with vim.

    
    
        > It also has terrible defaults
    

This can vary from distribution-to-distribution. Certainly the default debian
setup comes with annoyingly intrusive defaults, some of them used to have an
impact on speed. Three settings you probably want in your $HOME/.vimrc on
debian:

    
    
        filetype indent off
        filetype plugin off
        filetype plugin indent off
    

[this might be obsolete - that config is more than a decade old]

------
rekoros
I once worked at a company where I had to use Visual Studio. Now I can't
believe I cared that much about it, but I basically refused to write code
without vi. ViEmu saved the day, it was absolute magic.

I also really wanted vi bindings for navigation in team chat (isn't it the
most obvious thing ever?), so that's how we made it work in Kato
([https://kato.im/articles/en/power-users/keyboard-
control](https://kato.im/articles/en/power-users/keyboard-control))

------
bootload
Vi vs Emacs again?

 _" No, they are not dinosaurs who don't want to catch up with the times - the
community of vi users just keeps growing: myself, I only got started 2 years
ago"_

Using batch to write FORTRAN, the editor was a card punch. On the Deck-writers
(teletype) and VT100 terminals, I used to write Pascal, Ed was the only
choice. Early Linux use forced your hand, Ed (again? NO) or Vi. This is
because Emacs is a 30Mb download and where space was a premium. [0] Try using
anything but Vi or Ed with Busybox. [1]

So I stick to Vi(m). I _can_ use any cli editor but with much time and effort
in Vi usage why change? I can but why?

[0] esr, _" A Tale of Five Editors"_,
[http://catb.org/~esr/writings/taoup/html/ch13s02.html](http://catb.org/~esr/writings/taoup/html/ch13s02.html)

[1] grep "emacs" here ~
[http://www.busybox.net/downloads/BusyBox.html](http://www.busybox.net/downloads/BusyBox.html)

------
thomasahle
Admittedly I haven't been using vim more than a few months, but I wonder why
all the move commands are based on text structures, such as lines, spaces etc.

Wouldn't it be more useful to have commands for going to expressions, blocks,
scopes and other code level structures?

I see vim people suggesting always leaving blank lines around functions, so
you may use paragraph shortcuts to move them around. Why?

~~~
Anthony-G
Some users also use Vim for editing plain English. I compose most of my emails
in Vim and am currently (re-)acquainting myself with Mutt to avoid switching
back and forth between GUI windows -- though maybe I just have a masochistic
streak.

~~~
thomasahle
That makes somewhat sense, though it does feel like coding takes up 95% of vim
usage demonstrated in blog posts.

------
joezydeco
Embedded developer here. A lot of times I need to edit a file on the target
and I can easily put vi on the target system through busybox. Having the same
editor on both sides is a nice thing.

------
daemonk
I mainly use vi for working remotely on a server. It's just easier than using
X or something.

But I use sublime or some other graphical editor when I am on my own computer.

~~~
AlexeyBrin
You can use Sublime to do remote editing if you wish.

~~~
jsmeaton
I'll bite. What's the best way of doing this?

~~~
AlexeyBrin
Personally I use Sublime with rmate
[https://github.com/textmate/rmate](https://github.com/textmate/rmate) (works
with TextMate and Sublime), but there are alternatives like sftp
[http://wbond.net/sublime_packages/sftp](http://wbond.net/sublime_packages/sftp)

------
TazeTSchnitzel
For me, vim didn't have a steep learning curve. I've barely scratched the
surface of its command set and basically know very little of it, but I didn't
need it to be incredible, just better than TextMate.

------
lqdc13
I love vim. vimscript on the other hand...

Also it's gimped without addons which you very much miss when using someone
else's machine.

And if they happened to not have compiled with clipboard support, you're in a
world of hurt.

~~~
arianvanp
And that's where neovim comes in. I makes me so excited. You can write plugins
in any language. which is just plain awesome. I switched to the neovim alpha
in archlinux last week. Wasn't the most painless process but it worked. pacaur
hung installing it so I had to makepkg the package manually and get the
dependencies manually. But hey it works. The dependencies seem to change quite
often as well so sometimes you end up with dangling dependencies that you
don't need anymore. But apart from that, once it's installed, You won't even
notice you're not using vim. + The fact that it has a fully fledged terminal
emulator built in is pretty slick.

~~~
Svenstaro
Don't you worry, I'm going to pull neovim into Arch once there has been a
stable release. This should make it much simpler to install.

------
erokar
<esc>:q!

------
gargarplex
I was exposed to vi 15 years ago but not until recently have I decided to get
better at it. This article was great and helped a lot. It's a fun skill to
improve.

------
scotty79
I wonder if you could bind mouse gestures to vim normal mode commands and use
left hand for typing stuff and right hand to do magic.

------
Theodores
> Correct-conception #1: steep learning curve

I was fortunate to learn vi by rote, in a series of lectures where there was
no computer in the room. Yep, copying the likes of ':wq' from the hand-written
blackboard to A4 paper, along with all of the other 'handy' commands, some of
which such as 'yank' I do not use to this day. This was a whole different way
of learning with the notes referred to rather than things getting 'Googled'.
Was this a better way to learn vi?

I don't meet so many 'vi' experts these days, if anything I feel embarrassed
to be using 'vi' and associated command line tools like 'grep' when everyone
else has some auto-completing high-speed IDE instead. I have to 'psr-fix' my
code to make it sufficiently elegant. The problem for me is that I can do most
things in 'vi' without having to hunt around for menus etc. Therefore, moving
to the new is hard for me. In some ways I am like a secretary knowing
'Wordperfect' 25 years ago and unable to adapt to 'MS Word 2.0c' due to the
same UI problem and convenience of known tools (Wordperfect, Vim).

I also do not feel that 'vi' works well in a team, people with Mac-gui-
loveliness computers just can't edit things on your computer on an ad-hoc
basis, some visual editor has to be found just for them.

If you are a vim person then these funny new-fangled 'gui' editors are really
dangerous. It is far to easy for the document to end up with mystery 'j'
characters added to the first line, ':wq!' added somewhere at the end, maybe
with some randon 'ijk's' in the middle. If you are a vim person then every
editor should have an 'insert' and 'normal' mode, not just 'insert'. The rest
of the world doesn't see that though.

With people that do use 'vim' I have noticed that everyone does things
differently. Some people will regularly use a feature that you never use, to
make you wonder why you don't know that trick. Life without the correct,
personalised '.vimrc' file is also quite hard, however, I have found some of
these that others use to be overly 'souped up', for instance the search, I
really do not like the search-as-you-type option, old-school is better, where
you need to press enter.

So everyone finds their own dialect of 'vim'. Like car drivers, everyone
thinks they are a good 'vim driver' apart from those that haven't learnt to
drive. And they shouldn't. Amazing that vim is, it is a relic of former times,
there are better tools with better 'UX paradigms'. In my field none of the
'programming gods' use 'vim' as they can't get to their productivity levels
with it, so they use modern IDE's for their work, retaining enough 'vim' for
any server side config file editing.

~~~
mercurial
> If you are a vim person then these funny new-fangled 'gui' editors are
> really dangerous. It is far to easy for the document to end up with mystery
> 'j' characters added to the first line, ':wq!' added somewhere at the end,
> maybe with some randon 'ijk's' in the middle. If you are a vim person then
> every editor should have an 'insert' and 'normal' mode, not just 'insert'.
> The rest of the world doesn't see that though.

Turns that many of these (including IDEs like Visual Studio or Eclipse) have
add-ons or built-in modes which emulate a useful subset of vim's behaviour.

> Life without the correct, personalised '.vimrc' file is also quite hard

Is it? For server-side work, I have a "light" vimrc of a few lines with
sensible settings (status bar, nohidden, expandtab, this kind of thing). It is
trivial to recreate if I don't have a copy. I have a longer vimrc and quite a
few add-ons, but it's for more specialized work, not really anything I need
for editing a remote configuration file.

> In my field none of the 'programming gods' use 'vim' as they can't get to
> their productivity levels with it, so they use modern IDE's for their work,
> retaining enough 'vim' for any server side config file editing.

In a large part, it depends on the language you use. Nobody sensible would
work on a mid-size Java project in vim.

