
Vim is the worst editor, except all the other editors - dave1010uk
http://andre.arko.net/2013/09/11/vim-is-the-worst-editor/
======
lutusp
> Vim is the worst editor ... except all the other editors

Yes to the first five words, no to the rest. How many Vim users realize that
some of its more infuriating behaviors can be traced back to its predecessor
vi, which had to be able operate with a "paper terminal", essentially a roll
of paper as a display, without wasting too much paper during editing?

And how do I know this? During my time at NASA designing part of the Space
Shuttle, I was obliged to use vi and its immediate predecessor, with a roll of
paper as a display. It was bad then, and it's worse now. The difference is
there's no longer an excuse.

[http://en.wikipedia.org/wiki/Vi#History](http://en.wikipedia.org/wiki/Vi#History)

Quote: "vi was derived from a sequence of UNIX command line editors, starting
with ed, which was a line editor designed to work well on teletypes ... "

~~~
klibertp
Oh, it's you again. We talked about this some time ago. Since then I stopped
using Vim in favor of Emacs, which is modeless - I remember that having modes
was the biggest sin of Vim in your eyes.

It's been 5 months since I switched to Emacs. My .emacs.d is actually bigger
than .vim_runtime was, but it's because of more configurable features found in
Emacs plugins, so it's natural. My init.el is also longer than my .vimrc, but
this is because of much friendlier Emacs API and my love for Lisps (and
dislike for vimscript). On the whole I'm quite pleased with the switch,
although making Emacs into _my_ editor took a comparable amount of time and
code to Vim. I don't use Evil or anything like it, of course.

Emacs is better in many respects. CEDET is nice, SpeedBar and imenu with it's
syntactic extensions work wonders - TagBar in Vim comes close to SpeedBar, but
there's no imenu. auto-complete is better than omni-complete and easier to
extend. Eshell works better than conque. Icicles, ido and smex make working
with minibuffer a pleasure to the extent that Vim could never match - although
it has basic completion of commands. Of course there is more, but the
important thing to note here is that, while Emacs implements many things a bit
better, Vim has them too. And it's perfectly reasonable to prefer Vim
versions. So what I'm saying is that _I_ found Emacs better but Vim is still
really great.

Ok, so now to the modality. Emacs lacks modes, Vim has them. Last time we
talked you were saying that modes are inefficient and hard to use. I could
argue for modality then, but not against it, because I lacked experience with
non-modal editor. Now I can compare the two.

The truth is that I was suspicious of non-modal editing in Emacs. I heard and
read many rants about long sequences of modifier keys you need to press in
order to do something. Turns out these rants where right for the most part.
Some examples: C-- C-4 C-x <tab> performs hard dedent by four spaces. C-s C-w
C-s ... performs incremental search (forward) for current word (Esc # in Vim).
C-4 M-f goes four words forward (4w in Vim). There are also tricky ones, like
C-x d opening dired and much easier to type C-x C-d displaying a list of files
in current directory in a buffer.

In practice, however, with some amount of remapping, this is not an issue. But
wait, isn't pressing escape instead of some universal prefix (C-c for user
commands in emacs) not a problem in practice, too? After using Emacs and Vim I
can say that the complexity of commands in both is almost the same. In Vim I
remapped Esc to CapsLock - in Emacs I have Ctrl in place of CapsLock (although
I'm contemplating placing Alt there and Ctrl in place of Alt). The only real
difference I feel is that in Vim I could just hit the first modifier key (esc)
while in Emacs I need to keep it pressed. Emacs uses Alt (Meta), while Vim
does not, but that's a little difference, because Alt is usually in a place
that's easy to reach.

In conclusion, while I like Emacs very much, I still find your claim that
"modal editors" are for sad, handicapped individuals who just don't know any
better full of bullshit. Modality is not any worse than modeless model in
itself and Vim implements modality in a way which makes using it as convenient
as Emacs chords. While there are other things _I_ like in Emacs better,
bashing Vim because of modes alone is pure stupidity; bashing it because of
it's ancestry is an equivalent of saying that "your mama is fat" and saying it
has no X feature is most likely false anyway.

PS. Elsewhere in this thread you're saying that Vim can't use mouse and
clipboard. Of course it can - <esc>"=y copies to system clipboard instead of
local one. I admit that Emacs support for mouse events is by far superior, and
of course typesetting - colors, sizes and styles of fonts - are well supported
in Emacs and not in Vim. But reaching for the mouse is bad anyway and if you
have to, Vim supports all three mouse keys, which only makes the latter a
valid claim. It's up to everyone to decide whether they truly need different
fonts in their editor.

~~~
lutusp
> Elsewhere in this thread you're saying that Vim can't use mouse and
> clipboard. Of course it can - <esc>"=y copies to system clipboard instead of
> local one.

1\. Thanks for correcting me.

2\. Four characters. Very efficient.

3\. All to avoid using any control keys. The reason? vi must be able to work
with a keyboard that doesn't have any control keys, and vim must work exactly
like vi.

Not only do modern keyboards have control keys, but modern computers have mice
and other pointing schemes. But vi/vim lives in a permanent time warp, a warp
so profound that an old, justly retired editor I wrote in 1977 was far better
at exploiting technological advances.

Why was Apple Writer retired? Its limitations quickly became obvious,
especially once early Apple computers supported mice (which happened before
the Macintosh). No one wanted to keep using such a dinosaur in modern times,
including me.

~~~
gregjor
You repeatedly claim that vi is lame because it has to work with keyboards
with no control keys. You also say that you used vi on terminals that lacked a
control key. Your claims are simply false.

The original docs for vi, written by Bill Joy and Mark Horton, are online. You
can see quite a few places where the docs explicitly refer to control key
combinations. For example:

[http://docs.freebsd.org/44doc/usd/12.vi/paper-8.html#section...](http://docs.freebsd.org/44doc/usd/12.vi/paper-8.html#section50)

vi was developed in 1976 on the ADM-3A dumb video terminal, and that terminal
had a ctrl key. I remember because I had one. You can see the ADM-3A keyboard
here:

[http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-
keys...](http://www.catonmat.net/blog/why-vim-uses-hjkl-as-arrow-keys/)

The author of that page also explains why Bill Joy chose hjkl as movement
keys. Note that those keys have arrows printed on them to indicate that they
move the cursor when used with the ctrl key.

Although vi was never intended to work on paper terminals as you claim (having
the line-oriented ed embedded as a mode does not make vi equivalent to or
derived from ed), the most common paper-oriented terminal in use back then was
the Teletype Model 33, and it had a control key. You can clearly see it here:

[http://www.baudot.net/gil/tty-machines/pics/M33-ASR-Gil-
Keyb...](http://www.baudot.net/gil/tty-machines/pics/M33-ASR-Gil-Keyboard-
Typing-Unit.jpg)

The ADM-3A gave way to video terminals from DEC, HP, Wyse, Hazeltine, etc.,
and they all had control keys. I've worked on a lot of terminals in my time,
and I have to go back to keypunch machines to find something that didn't have
(or need) a control key.

So what machine did you use vi on that didn't have any control keys?

If such a terminal indeed existed and you were forced to use it at NASA, I'm
sorry. The experience obviously left you bitter and scarred. But please stop
making claims about vi and early terminals that are simply and obviously
false.

~~~
lutusp
> You repeatedly claim that vi is lame because it has to work with keyboards
> with no control keys. You also say that you used vi on terminals that lacked
> a control key. Your claims are simply false.

First, I never said either of those things anywhere. But, having sampled the
level of personal responsibility among the people in this thread, I won't
bother asking you to try to locate your source for those false claims.

The reason vi doesn't use control keys is because many keyboards in those days
didn't have control keys to use. Which word don't you understand? The authors
couldn't exploit keys that didn't exist, so they avoided use of an entire
keyboard filled with control keys, an unfortunate necessity.

This is not to say there were no keyboards with control keys, only that the
designers didn't want to lock out users having keyboards without control keys.
That's why vi used letter keys for arrow keys, and shifted modes by means of
something other than a control key, to make control functions possible in the
absence of control keys.

> But please stop making claims about vi and early terminals that are simply
> and obviously false.

What? I should defend statements that I never made, that you invented and then
tried to hold me responsible for? If you will stop inventing quotes, I will
stop calling you out on them. Now, as just one example among many, locate
where I said "vi is lame" ANYWHERE, FOR ANY REASON, IN ANY CONTEXT. And when
you discover that you invented it, you will apologize.

~~~
gregjor
Bill Joy's own docs and comments on the origin of vi and the terminals it was
designed for contradict your opinions.

I've given examples with supporting evidence. What evidence have you given to
back up your claims?

I didn't invent any quotes. The quotes I posted -- using the widely-accepted
quotation mark convention of English (assuming your keyboard has those!) --
are clearly indicated. The "vi is lame" statement is my own summary of your
opinions expressed in this thread, it is not attributed to you as a quote but
as a sentiment. Thus the lack of surrounding quotation marks.

But maybe let that bone go and try to produce any evidence supporting the
meager meat of your arguments about early terminals and the history of vi.

------
IanCal
1) Dump Janus, add the plugins you actually want

2) True

3) :set paste

4) Then wrap it in a function

5) I've always found ctrl-p to be snappy actually. You can replace the matcher
with ag or similar

> write the Vim configuration lines required to cause those files to be
> ignored. You have got to be kidding me.

Write a small amount of config once per project? It's no more complex than
adding things to a UI

    
    
        set wildignore+=*/tmp/*,*.so,*.swp,*.zip
    

6) No, vim can't, but plugins can. Ctrl-p has this feature
([http://superuser.com/questions/390011/fuzzy-find-within-
file...](http://superuser.com/questions/390011/fuzzy-find-within-file-in-vim))

7) Stop just navigating with j and k.

> After reading this list, feel free to tell me how I'm doing it wrong on
> twitter.

You're not googling anything to find out the answer?

Also, because occasionally people haven't heard of it, get Gundo.
[http://sjl.bitbucket.org/gundo.vim/](http://sjl.bitbucket.org/gundo.vim/)

Vim has a full tree undo, gundo makes it easy to navigate and see diffs
between changes in code.

~~~
maaaats
But that's kinda the problem with vim. Having a sane configuration takes hours
of setup and googling.

~~~
klibertp
Depending on how you define "sane" it can be months. Vim is said to be a
programming language for text editing - I wouldn't expect anything less of a
complexity from a thing like this. I recently learned Emacs and it took me two
months - that short because I already went through the process with vim some
years ago - to learn it and configure it to my liking. My Emacs config counts
983 lines with comments and whitespaces removed[1]. My .vimrc was shorter, but
mainly because I dislike vimscript and like Lisps.

[1] cat .emacs.d/config/*.el | egrep -v '^$' | egrep -v '^;;' | wc -l

------
bgar
First of all, you have to dump Janus. It is bad for you. Learn to use stock
Vim and gradually integrate plugins as needed. I recommend NeoBundle to manage
them, as it is able to compile plugins if required.

I've been using vim for years and the only plugins I use are vim-airline[1]
and vim-bufferline[2]. Of course, my editing needs may not be as complex as
yours, but in reality most things you think you need a plugin for can be done
with plain Vim. Feel free to check out my humble .vimrc[3] for some
inspiration.

1: [https://github.com/bling/vim-airline](https://github.com/bling/vim-
airline) 2: [https://github.com/bling/vim-
bufferline](https://github.com/bling/vim-bufferline) 3:
[https://github.com/wolfcore/air-
dotfiles/blob/master/.vimrc](https://github.com/wolfcore/air-
dotfiles/blob/master/.vimrc)

~~~
icambron
That may well be good advice, but it doesn't really solve the other problems
he's complaining about, right?

~~~
bgar
No, but it's a good start.

------
bpizzi
> I've been using it full-time for just over three months now.

That's it: you just need to give it more time. One simply can't expect to
fully climb vim's learning curve in just a quarter of a year. Your brain can't
adapt so rapidly to so much new shortcuts.

> Jump to CSS selector. Jump to class. Fuzzy string matching. All these things
> and more are what I am used to. Vim just can't do them.

That's one example among others: there's vim's marking system for that, and
your brain isn't just used to it now. You find it slow, broken and not user-
friendly, but it's not really, it's just that you need to give it time to
master it.

My 2c advice: it you really want to like it, keep going and give it a full
year. If you think you can't give it more time, then Vim isn't for you and
some commercial editors might do it.

I've been there, I know your current feeling. I'm a happy vimmer now but it
hasn't been the case for something like a year. There's a reward for real
vimmers: you'll never need to switch anymore to another editor, because Vim is
there, powerfull, opensource, free, multi-plateform, and you know how to use
it smoothly.

~~~
pestaa
I like the spirit, but how will Vim's marking system help me jump to a CSS
selector in an unbuffered stylesheet?

I'm really curious; missing this feature from heavyweight IDEs.

~~~
bpizzi
Been there also. _My_ solution was not to rely anymore on stuff provided by a
heavyweight IDE.

"Jumping to somewhere in an unbuffered file according to where I am in the
current buffer", that is actually depending on a background worker that knows
a very specific set of rules and use it to constantly cycle threw the
filesystem. Which bg process is usually provided by tanks like Eclipse.

With the time I've found something that matches that behavior without the
payload on the computer, and guess what, it's my brain.

I'm no more in pain of jumping to the definition of a css rule, because I know
which css file I have to invoke and I can do it _very_ quickly thanks to
Control+P, and jumping to the definition is a matter of one or two "/".

Of course you need to organize things smartly in your project if you ever want
to do that without too much thinking time, but hell, I count that on the
bright side of this solution.

------
djur
The reason there's no project-wide find and replace in vim is that vim has no
concept of a project. It's designed to be one of many tools, which works
really well for some workflows and not for others. #5 is the same deal --
they're limited by the design of vim, and that design doesn't fit anything
like TextMate's project search.

It would drive me _crazy_ if vim saved without me telling it to.

I think a lot of people suffer needlessly trying to make vim be what they want
it to be, when it never is going to meet their expectations. You'd be better
off trying to get those things you find useful about vim implemented in
TextMate or Sublime than the reverse.

~~~
jessedhillon
The only thing that drives me crazy about the save/do-you-want-to-reload
prompt is actually a git related issue. When you commit, git updates all
committed files in some way that triggers vim change detection. You go back to
vim, write some code, try to save and then you get this DANGER WILL ROBINSON
message.

It's horrible because you're not quite sure sometimes if there was a
legitimate change made in another process that you're now about to undo. Half
the time I end up copying the lines I know I added, allowing a reload, and
then pasting them back in, just to be safe.

~~~
aidos
Really? That sounds misconfigured and it certainly doesn't happen for me. Are
you on windows? Maybe it's just a problem there. I'd take a look a bit deeper
to see if I could figure that out if I were you as it does sound like a
nuisance.

Personally (regarding the original gripe in the post) I'd be horrified if my
text editor was silently ignoring edits or just updating the code under me. If
that was really a concern while I was working on my software I'd take a look
at the workflow to see what could be done about it.

------
gabemart
The issue of soft-wrapping text drives me _nuts_ , not just with editors like
vim but with programming-focused tools that can edit text in general. Github
is terrible for this. Why isn't it possible to enable soft-wraps when viewing
diffs? Hard-wrapping the text is not always a solution because it makes the
text so much less versatile in terms of what you can do with it, unless you're
willing to periodically remove the hard-wraps when you want to move the text
somewhere else. Using markdown is not a solution because markdown is
destructive; it eats blank lines and indentation.

~~~
djur
A programmer's text editor and a word processor have much different
requirements and should be different tools. There are much better options than
vim to author formatted documents.

------
rvijapurapu
Patience my dear friend, patience. I have been using Vim as my editor of
choice for over a decade, I think I barely use 10% of its features.

Your configuration is always evolving - so don't fret if a plugin or a setting
is not working for you, it just means its gotto go..

That said focus on `your productivity` over a religious choice of an editor.
You actually got to live with it for decades to come. choose the right one
which fits your use case.

------
stormbrew
Kinda sounds like this person just wants Sublime to me.

~~~
n1c
Yeah; I use Sublime in vintage mode and I think it has all those bases
covered.

------
ranza
I feel his pain! Especially the paste thing. I've been back and forth with vim
for as long as i can remember. Finally decided to switch to Sublime on my
desktop and keep a stripped down version of vim for my terminal needs. I feel
like Janus is doing more wrong then good. If you want to get into the mindset
of vim you should ditch Janus.

------
icambron
Yes! With the exception of item #5 and #6, I really strongly agree with these
items. Vim's automatic indenting, in particular, just seems systematically
broken.

On 5, ctl-p works great for me. I have it set up to use git in choosing what
to ignore and it's plenty fast. On 6, I probably just don't know any better.

------
daGrevis
If anyone is looking for sane configuration — vim-sensible is the thing you
are looking for! [https://github.com/tpope/vim-
sensible](https://github.com/tpope/vim-sensible)

------
regularfry
Why limit yourself to a single editor? They're different tools, good at
different things. It's _really_ not that hard to learn, for instance, both
emacs and vim. I've got both open right now!

------
seren
As a regular Vim user, I don't understand why some of these features, like
Ctrl-P are not implemented natively in C, rather than to have to rely on
Vimscript or Ruby plugin.

~~~
chrismorgan
Writing things in Vimscript makes for easy and entirely reliable deployment.
Ruby requires a +ruby build and Ruby to be installed, but at least avoids some
of the warts of Vimscript, while still being as simple as "put it in and use
it". (For myself, I'd prefer not to depend on Ruby, or even Python, though
it's a much safer bet.) Any plugins in C require a compilation step before you
can use it.

~~~
seren
I was maybe unclear, but I was regretting that a fuzzy find for opening files
was not part of the vim core. It seems to be a generic editor feature that
could benefit everyone.

------
jfe
Time to get out of your two-editor bubble, folks; there _are_ other options.
In my opinion, Acme puts both Emacs and Vim to shame.

------
Gonzih
I prefer Unite.vim over Ctrl-P since it can be used more than for file
matching. But yes, you need to spend some time to configure it.

------
DH61AG
The only problem with Vim is that you need to learn it. If it's too hard for
you then there is plenty of other editors.

------
chatman
Using vi is not bad, its a "penance". Emacs is the real editor! So says
Richard Stallman. :-)

~~~
markeganfuller
Normally I'd respect something RMS said and I love him for his conviction but
on this we must disagree :)

~~~
chatman
And he himself makes these remarks in a cool and snarky style, his usual
humorous self. It is never emacs vs. vi war for him. :-)

------
m2mdas
Pasting the reply I gave in r/vim

Answer to some of the points,

 _Janus_ : There are divided opinions in vim community about whether
distributions should be used or not. I am on the latter side. But still for
just checking out I installed Janus a while ago. Yes it is slow, but it turns
out that it is as slow as my then `.vimrc` configuration. I tried to track
down the problem. It is because of vim's blocking behaviour during executing
external commands. When you write a buffer or switch to a buffer, syntastic,
tagbar, powerline statusline, gitgutter, bufexplorer all execute external
command. Vim becomes more slow when `.git` repository grow larger or when
saving a large file. So how do you solve the problem? Remove those plugins and
install Unite.vim[1] with vimproc[2] asynchronous library.

 _Files that change_ : If you do external edits more frequently then I think
it is time to rethink your work-flow. I think there is a common consensus that
you should not run live edit in server.

* Indenting pastes* : There is a plugin for that [3] ?

* Opening files inside my project _: Last I checked command-t was damn fast, don 't know where slowness comes form. Another alternative is `Unite.vim` `file/async` source. It is fast at finding files but goes slow while doing ignore-pattern checking. Without the checking it is DAMN FAST. The `phpcomplete/files` source I created for my php autocomplete plugin[4] easily list 4000+ files in seconds. If you want to list files obeying the patterns in the '.gitignore' or '.hgignore' files. Checkout my unite-file-vcs[4] plugin. It adds a `file/vcs` source that lists files by issuing `git ls-files` or `hg status -c -m -u` command for `git` or `mercurial` projects respectively.

_ Navigating inside files*: Checkout unite-outline[6]. It shows live output by
parsing the current buffer. Unite.vim required. But it does not support css
files right now. Adding support should be easy.

So the summary of the story. Move to `unite.vim` and friends ;)

[1]
[https://github.com/Shougo/unite.vim/](https://github.com/Shougo/unite.vim/)

[2]
[https://github.com/Shougo/vimproc.vim](https://github.com/Shougo/vimproc.vim)

[3] [https://github.com/sickill/vim-pasta](https://github.com/sickill/vim-
pasta)

[4] [https://github.com/m2mdas/phpcomplete-
extended](https://github.com/m2mdas/phpcomplete-extended)

[5] [https://github.com/m2mdas/unite-file-
vcs](https://github.com/m2mdas/unite-file-vcs)

[6] [https://github.com/Shougo/unite-outline](https://github.com/Shougo/unite-
outline)

~~~
regularfry
> Files that change: If you do external edits more frequently then I think it
> is time to rethink your work-flow. I think there is a common consensus that
> you should not run live edit in server.

It's possible this isn't what you meant, but external edits do _not_ imply
editing code live on a server.

~~~
m2mdas
Well I made this comment in context of his editing file via pry-rescue which
at first observation looked as if he was live editing in server. Upon further
inspection it seems that pry-resque is acutlly a good debugging tool. I did
not know about it because of my very little ruby development knowledge. Sorry,
My bad :)

------
blumkvist
sublime, bruh

