vi vs. vim (sacrilege alert!)

[enk]

Dunno if this has been done before, because when I searched topic titles for "vi", I was told that each word must consist of at least 3 characters

Well, here goes:


vi sucks!


I'll get to the arguments later... meanwhile, what do you think?

[zenten]

Dunno if this has been done before, because when I searched topic titles for "vi", I was told that each word must consist of at least 3 characters

Well, here goes:


vi sucks!


I'll get to the arguments later... meanwhile, what do you think?

I agree, vim is way better. Vi? Old and busted. Vim? New hotness.

[Pobega]

Was this even worth making a topic for? Vim is obviously superior to Vi; The only argument people may have in favor of Vi is that they're used to it's quirks.

It's like saying `Which is better? Linux 1.0 or 2.6?`

[enk]

I agree, vim is way better. Vi? Old and busted. Vim? New hotness.

So.. initial agreement. Not much of a basis for a war


To get this thing off to the right start, I'd like to see verdatum, Korandder, !xobile, adlaiff6, segmentation fault, Aviatrix as well as any possible vipers-in-hiding in here to speak in favor of our forefather, the Editor of the Beast!


* edit: *

Was this even worth making a topic for?

One shouldn't think so, but the above mentioned people spoke in favor of vi in the other editor threads. So I was curious

[Korandder]

When I said vi I meant vim. I think of vim as vi since I have vim alias as vi. I need my syntax highlighting, visual mode and multiple windows.

[xyzzy]

Pfft. Emacs ftw.

Out of vi and vim, I actually tend to prefer vi, but using either is rather appalling.

[davean]

emacs

[Asleep or Wrong]

I type vi at the shell (it's an alias to vim, of course). Force of habit.

[enk]

Oh, never mind me then...

* note to self: should have made that vim vs nvi thread instead...


And @ you Emacs goons, if you find yourself forced to using vi(m), you can always type this

:!emacs %

[adlaiff6]

I would choose vim over vi, simply because on my school's solaris machine that they give everyone ssh access to, vi ends up being this shitty little program that is one row tall and only displays the line you're on (but otherwise acts exactly like normal vi), while vim is actually the program we all know and love that takes up the whole terminal and actually looks like a normal text editor. I realize the above description of vi is confusing as all get up, but that's only because the program itself that they claim to be vi is at least as confusing.

P.S. - Cheers, enk!

[davean]

I would choose vim over vi, simply because on my school's solaris machine that they give everyone ssh access to, vi ends up being this shitty little program that is one row tall and only displays the line you're on (but otherwise acts exactly like normal vi), while vim is actually the program we all know and love that takes up the whole terminal and actually looks like a normal text editor. I realize the above description of vi is confusing as all get up, but that's only because the program itself that they claim to be vi is at least as confusing.

P.S. - Cheers, enk!

Used ed?

[enk]

Out of vi and vim, I actually tend to prefer vi, but using either is rather appealing.

Fix'd.

[adlaiff6]

Used ed?

Yeah, it's kind of like using ed, but printing one line constantly.

[photosinensis]

Vim > vi. Period. I tried to use vi on an old Tru64 box to which I'd been given SSH access once. It was painful. I immediately went back to coding on my box in vim and using scp to move the files over.

[enk]

Having thought a little about it, I think some vim users should be forced encouraged to use vi for some time. Vi doesn't have visual mode, and that will force people to forget about the editing style of the Notepad-like editors and start learning counts and text objects.

The leader of the IT-dep. where I just got a job found out about my affinity for vim and asked me how to duplicate a line easily (which is of course yyp or Yp if you haven't mapped Y to y$ which you should - sometimes vim is a little too vi-compatible). He was used to select/visualize it, yank, move to next line and put it, which is clearly inefficient and clearly an injury of growing up with simple Notepad-style editors.

I also see people mapping this ggVGg? to a function key. It's a sin! The correct thing to do is ggg?G. There's no reason to select/visualize text when you know it's size or extent. Not even in mappings where you don't actually type it all out. It's a matter of principle.

Don't get me wrong, I use visual mode a lot e.g. when acting on several lines or words, but not when I could just as well use an operator and a single text object.

[illuminati1113]

I know that this topic is old, but I can't help but express my love of moded input. At least for text editing. That fact that i can perform complex manipulations of text without even moving from the alphanumeric keys is awesome.

[Amnesiasoft]

I don't use any of these things very much, but I'm pretty sure it's vim when I do use one.

[Hammer]

I would choose vim over vi, simply because on my school's solaris machine that they give everyone ssh access to, vi ends up being this shitty little program that is one row tall and only displays the line you're on

Surely that's just the term type not being set? Happens all the freaking time if you ssh from linux to solaris; the ssh sends the TERM value and there isn't an entry for "linux" or "i386" or whatever it is that linux sends in the solaris terminfo database. Easy fix is set + export TERM to something it does know about, eg TERM=ansi.

[Random832]

I would choose vim over vi, simply because on my school's solaris machine that they give everyone ssh access to, vi ends up being this shitty little program that is one row tall and only displays the line you're on

Surely that's just the term type not being set? Happens all the freaking time if you ssh from linux to solaris; the ssh sends the TERM value and there isn't an entry for "linux" or "i386" or whatever it is that linux sends in the solaris terminfo database. Easy fix is set + export TERM to something it does know about, eg TERM=ansi.

"honest-to-god vi" (not even nvi does this) has this "line mode" which is what you're talking about - on hardcopy terminals (teletypewriters) it will go to a new line whenever it needs a clean line. This is used as a fallback. most vi clones will either completely bail out if it doesn't have the minimum stuff needed, or fall back on some "semi-dumb mode" - what vim does is a semi-dumb mode where it uses _absolutely nothing_ except absolute positioning (ESC [ H to move the cursor to a spot on the screen) - which works well on "modern" systems because you have, 99% of the time an ansi-ish terminal and virtually no speed limitation (it has to output 2000 bytes to the terminal to refresh the screen)

[Stormscape]

pico! I'm a rebel without a clue!

[zenten]

I know that this topic is old, but I can't help but express my love of moded input. At least for text editing. That fact that i can perform complex manipulations of text without even moving from the alphanumeric keys is awesome.

What letter/number do you use to switch modes?

[semicolon]

question: why would i, a windows user, need to use either of these programs? if i need syntax highlighting i can just use notepad++ or something, right? why is vi/vim/emacs (i know emacs and vi are totally different) so special?

[enk]

I know that this topic is old, but I can't help but express my love of moded input. At least for text editing. That fact that i can perform complex manipulations of text without even moving from the alphanumeric keys is awesome.

What letter/number do you use to switch modes?

I'd guess he meant the keys you can reach from home row, including e.g. ctrl (and maybe esc) but not the arrow keys. I've found Ctrl-[ (which is standard) to be the nicest escape mapping. But you can certainly do complex manipulations of text without entering insert mode. Would be kind of silly though. Unless it's a challenge

question: why would i, a windows user, need to use either of these programs? if i need syntax highlighting i can just use notepad++ or something, right? why is vi/vim/emacs (i know emacs and vi are totally different) so special?

Syntax highlighting is expected in any serious editor. Both emacs and vim have a ton of features and are very customizable (I love my vimrc like a child which I nourish every day). The reason I prefer vim is the moded input. Quoting viemu.com:

with vi, your keyboard becomes a huge specialized text-editing gamepad with almost a hundred buttons. Each of them has at least two functions, shifted and unshifted, so you have almost two hundred functions at a single keypress (not counting Shift). Commands are incredibly powerful for text editing, and you can even combine them to obtain the best results. While typing some text, it is a regular keyboard, but when you're back to normal mode you have the best-designed text-editing machine there is, and it shows.

[edge walker]

why is vi/vim/emacs (i know emacs and vi are totally different) so special?

It can’t really be explained convincingly. If you can, find someone who’s been a heavy user of one of those for a while and watch him work over his shoulder. You’ll understand immediately.

[EvanED]

I have two reasons:

First, one thing that I've heard in the emacs-vi debate is that emacs is programmable. A large portion of it is written in Lisp, so it contains a Lisp interpreter, so you can write your own scripts to run and perform useful functions.

Second, the thing I miss most from Emacs when I go to other editors is the ability to quickly and almost for free create a macro to do something, then repeat it. Most of the time I was doing something pretty simple, but not always. One transformation that comes to mind was the following. I had a list of function prototypes written in C in an object-oriented style, and was making a C++ wrapper for the API. So

Code: Select all

struct state;

void stateDoOperation1(state* state, int param1);
int stateDoOperation2(state* state, int param1);
int stateDoOperation3(state* state, int param1, double param2);

and I wanted to turn them into members of a class:

Code: Select all

doOperation1(int param1);
doOperation2(int param1);
doOperation3(int param1, double param2);

What I did was something like the following:

• Go to the beginning of the "stateDoOperation1" line
• Press ctrl-(, aka C-( in emacs-speak, which tells emacs to start recording a macro
• Press C-s, which starts to search, then space; this moves the cursor ("point" in emacs-speak) to the space after "void", then press right
• Press delete five times to remove "state", then whatever the convert-to-lowercase command is, which changes the "Do" to "do"
• Press C-s then ( to move to the beginning of the parameter list (no matter how long the function name is)
• Press C-space, which sets the "mark" at the start of the first parameter; actions that operate on a block of text usually operate between the point and the mark. Think of that text as what you have selected, except that you always have something selected in emacs (unless the point and mark are in the same spot) and typing and such doesn't delete that text
• Press C-s then , which moves the point to the end of the first argument (yes, this does break if there is only the one argument, and yes, it did break ), then right so the point was on the other side of the comma
• Press C-w to kill the text between the point and mark, which is the entire first argument
• Press C-a (or home) to return to the beginning of the line, then down so that the point was at the beginning of the next line, ready to run the macro again
• Press C-) to end the macro

Then if there were 10 functions, you can press alt-10 (M-10 in emacs-speak) C-x C-e to run that macro 10 times. Because each invocation sets up the next, it will just go down the list boom-boom-boom.

(Okay, in this example comments between the functions made it so it wouldn't work. But most of the time that technique works for me.)

It's possible that I even starting making the actual bodies of the new method (which were just wrappers around the old one) by copying the prototype, changing the return type to the token "return", and inserting braces around it.

Someone who has much better regex-foo than me could do most of the stuff that I use macros for (another common one is just inserting something at the beginning of each line, e.g. s/$/$foo / or something), but I don't have that knowledge.

[enk]

I'm happy to see emacs can do that. I haven't looked much into it, but I'd probably use it if it wasn't for Vim


In Vim, I'd do the above like this:

Code: Select all

qqdfe~fsdf,x^Mq2@q

qq                   start recording macro to register 'q'
  dfe                delete to next 'e' (the end of "state")
     ~               invert case of letter under cursor (the 'D' in "Do")
      fs             move cursor to next 's' (the beginning of "state")
        df,          delete to next ','
           x         delete (the space after the ',')
            ^M       move to beginning of next line (it's a return)
              q      stop recording
               2@q   replay macro q two times


Edit: I copied the code before/after here for reference.

Code: Select all

void stateDoOperation1(state* state, int param1);
int stateDoOperation2(state* state, int param1);
int stateDoOperation3(state* state, int param1, double param2);

doOperation1(int param1);
doOperation2(int param1);
doOperation3(int param1, double param2);


and in vim, the regex substitution could be:

Code: Select all

s/\v^.{-}e(.*\().{-}, (.*)$/\l\1\2


performed with those lines selected. Notice the ending, where the \l (backslash-ell) makes the next char lowercase (the 'D' of "Do")

Btw, the macro was faster to do

[EvanED]

Yeah, I may poke fun at vi users in the holy war tradition, but I don't actually harbor any idea that there is something that emacs does clearly better than vi (except maybe Lisp editing), and vi does seem faster in the hands of someone who's skilled. But it also seems that emacs is faster in the hands of someone who isn't particularly skilled at it, so I will stick with it . I would have been terribly surprised if vi didn't have something comparable.

But both have editing power beyond anything else I've used... I find myself wanting some emacs features when I'm working in Visual Studio (mostly macros, and to a lesser extent incremental search). (That said, the parts of the IDE for code browsing and such in a real IDE more than make up for the decrease in raw text editing power IMHO. But that's another thread.)

[edge walker]

Pity you’re in the Emacs camp then, ’cause there’s a vi emulation for Visual Studio… Unfortunately it costs $$$, but I’m pretty sure I have seen a component to embed Vim into VS somewhere.

However, they do have a good page about why anyone would be so crazy to want to use an old and weird editor like vi today.

[You, sir, name?]

While on the subjects, there is a firefox extension that allows you to control it like vim.

vimperator.mozdev.org

It's not perfect. Unfortunately you don't get a vim window in the text boxes. But it's a hell of a lot better than regular firefox. You can control the vimperator without ever letting go of the home row, let alone touching the mouse...

[enk]

While on the subjects, there is a firefox extension that allows you to control it like vim.

vimperator.mozdev.org

It's not perfect. Unfortunately you don't get a vim window in the text boxes. But it's a hell of a lot better than regular firefox.

mozex can let you do that.

You can control the vimperator without ever letting go of the home row, let alone touching the mouse...

You can do a lot with vanilla Firefox and a keyboard and for that I love it. It means I am not totally handicapped when using someone else's computer (I am of course talking about the apostrophe link-quick-search).

[hotaru]

the real vi is much better than vim.

• vim lacks open mode. sometimes visual mode just doesn't work (over a slow connection or with a buggy terminal), and vi in open mode is a lot easier to use than ed.
• vim is huge. elvis has most of the fancier features of vim plus it supports open mode, and it's less than a third the size of vim.
  

  Code: Select all

  hotaru@olorin$ ls -ShrlL `which vi` `which nvi` `which elvis` `which vim` < ~ >
-rwxr-xr-t  1 root  wheel   186K Jun 13 02:40 /usr/local/bin/vi
-r-xr-xr-x  6 root  wheel   305K May 12 06:23 /usr/bin/nvi
-r-xr-xr-x  1 root  wheel   473K Apr 24 21:43 /usr/local/bin/elvis
-rwxr-xr-x  1 root  wheel   1.6M May  1 22:29 /usr/local/bin/vim

• vim is slow. vi and nvi can open an empty file and then exit in 0.01 seconds. elvis takes 0.06 seconds. vim takes over 2 seconds. 2 whole seconds just to open an empty file and then quit!
  

  Code: Select all

  hotaru@olorin$ rm empty_file.txt                                          < ~ >
rm: empty_file.txt: No such file or directory
hotaru@olorin$ touch empty_file.txt                                       < ~ >
hotaru@olorin$ /usr/bin/time -h vi +q empty_file.txt >/dev/null           < ~ >
        0.01s real              0.00s user              0.01s sys
hotaru@olorin$ /usr/bin/time -h nvi +q empty_file.txt >/dev/null          < ~ >
        0.01s real              0.00s user              0.01s sys
hotaru@olorin$ /usr/bin/time -h elvis +q empty_file.txt >/dev/null        < ~ >
Read empty_file.txt, 0 lines, 0 chars
        0.06s real              0.03s user              0.02s sys
hotaru@olorin$ /usr/bin/time -h vim +q empty_file.txt >/dev/null          < ~ >
Vim: Warning: Output is not to a terminal
        2.14s real              0.03s user              0.06s sys

• vim is licensed under a non-free license (GPL). vi, nvi, and elvis are all licensed under less restrictive licenses:
  
  • vi is licensed under a BSD-style license.
  • nvi is licensed under the BSD license.
  • elvis is licensed under the clarified artistic license

nvi is a lot better than vim, but it's still a lot bigger than vi and nvi doesn't seem to support utf-8, which vi does support.
elvis is only a tiny bit bigger than nvi, has most of the fancy (useless) features that vi doesn't have, and has open mode.

[enk]

@Hotaru: I think your arguments, while valid, are somewhat obsolete.

First, I'd say sizes alone are irrelevant today when they are that small, only loading time matters. And your benchmark doesn't reflect a real usage scenario (apparently the redirect confuses vim, but you don't do that much in real usage anyway). Try time vim +q empty_file.txt instead, that is what it actually feels like when using it - and below one second on most machines. I don't find that a problem compared to the extra features I get in vim over vi (multiple documents, undo history, syntax highlighting...). And on newer machines it's <100 msek anyway.

Open mode... again, slow connections and buggy terminals aren't everyday stuff for me. Sounds interesting, though.

And I'm not that into licenses - but as far as I can tell, you can get the vim source and distribute modified copies of it. That's free enough for me.


I'd prefer utf-8 capability, so I don't think I'd like nvi. And vim has the advantage of being available on most *nix boxes, but otherwise elvis sounds like it's worth a try.


Btw, thanks for making the first real input to this debate

[Rysto]

hotaru, if you want to debate software licenses, there's a thread for that(and if there isn't, then start it).

[EvanED]

hotaru, if you want to debate software licenses, there's a thread for that(and if there isn't, then start it).

I don't remember one actually, and there isn't one with either "license" or "GPL" in the title, so I think you'll have to do the starting one thing. That said, while general discussions as to the merits of the licenses do belong in another thread, specific statements of the sort that "I prefer vi because of the license" or "I'm license-agnostic so that doesn't provide a reason to choose one or the other" are on topic here. (At least assuming they don't start overwhelming the rest of the discussion.)

[Rysto]

It's on page three and it's called "BSD vs GNU" or "GNU vs BSD".

Ah, I was wrong and chose the wrong search terms. Here's the link. -Evan

[hotaru]

First, I'd say sizes alone are irrelevant today when they are that small, only loading time matters. And your benchmark doesn't reflect a real usage scenario (apparently the redirect confuses vim, but you don't do that much in real usage anyway). Try time vim +q empty_file.txt instead, that is what it actually feels like when using it - and below one second on most machines. I don't find that a problem compared to the extra features I get in vim over vi (multiple documents, undo history, syntax highlighting...). And on newer machines it's <100 msek anyway.

Code: Select all

        0.13s real              0.04s user              0.05s sys

still more than twice as much time as elvis, and if you're opening a file with actual content, like UnicodeData.txt, instead of an empty file, then it can take a lot longer:

Code: Select all

"UnicodeData.txt" 19336 lines, 1117369 characters
        0.20s real              0.09s user              0.05s sys

whereas with vi, opening that same file is still faster than opening an empty file in vim:

Code: Select all

        0.10s real              0.03s user              0.05s sys

sure, 0.20s isn't very long, but it's a noticeable delay.
also, what the heck is vim doing that slows it down so much when i redirect standard output? vi, nvi, and elvis don't have that problem.

multiple documents isn't really necessary because i can run multiple vi sessions in screen. unless you're referring to the ability to specify several documents on the command line and then use :n to go to the next one, which vi can do just fine, but i rarely use that. multiple undo isn't really necessary either because usually when i need to undo something i realize that i need to undo it before i've done anything else.
syntax highlighting isn't really very useful either, unless you're one of those people who refuse to use any white space in their code.

[enk]

Yes, 0.2s are noticeable, but it's not enough to bother me.


Advantages of using multiple documents over multiple vi instances in screen:

• :argdo / :bufdo / :tabdo / :windo
• Vertically split screen (with synchronized scrolling if you'd like - useful for diffs) (actually, you can have as many windows in a tab as you'd like, but more than two are rarely useful).
• Word completion reads other opened files as well (never mind... vi doesn't do word completion at all)

I find syntax highlighting makes it easier to spot control flow statements and declarations (maybe that makes up for the 0.2s I lost while opening vim? (but that is another religious war altogether)).


Other stuff I use regularly, that vi doesn't have (in order of importance):

• command line history
• visual mode
• word completion
• * and # search commands
• command line completion
• scripting/plugins

Stuff I use once in a while, that I'd also miss in vi:

• regexes
• built-in help system
• macro recording
• code folding

[hotaru]

Advantages of using multiple documents over multiple vi instances in screen:

• :argdo / :bufdo / :tabdo / :windo
• Vertically split screen (with synchronized scrolling if you'd like - useful for diffs) (actually, you can have as many windows in a tab as you'd like, but more than two are rarely useful).
• Word completion reads other opened files as well (never mind... vi doesn't do word completion at all)

i can see how that might be useful for some things, but not really anything i'd use very often.

I find syntax highlighting makes it easier to spot control flow statements and declarations (maybe that makes up for the 0.2s I lost while opening vim? (but that is another religious war altogether)).

i suppose if you're editing obfuscated code then it could be useful, but at least in well written c code, control flow statements and declarations are pretty easy to spot.

Other stuff I use regularly, that vi doesn't have (in order of importance):

• command line history
• visual mode
• word completion
• * and # search commands
• command line completion
• scripting/plugins

vi does have visual mode.
sure, the rest of those would be nice, but i don't think they're really worth the noticeable delay in starting the editor, since i'd rarely use any of them.

Stuff I use once in a while, that I'd also miss in vi:

• regexes
• built-in help system
• macro recording
• code folding

vi has regexes and macros.
why have a built-in help system when you can use screen to have whatever documentation you want open while you're using the editor?
i've used editors that had code folding before, and it seemed pretty neat at first, but after a few hours the novelty wore off and i realized that folding and unfolding code all the time was a lot slower than just scrolling past it.

[enk]

Hmm... seems I was a little too fast with denying vi's features. I just tried some random stuff that didn't work.

With regex searches, I couldn't use .\+ (one-or-more chars) or .\{-} (non-greedy matching), but I now see .* works. So it's a weaker form of regexes, apparently.

And I also see now that I can write a macro, then yank it to a register and use it. But I can't record it, which makes the whole thing a lot less sexy.

And how do you enter visual mode in vi? I don't mean doing :vi in ex, I mean the mode in vim where you visually select text character-wise (v), line-wise (V) or block-wise (^V) (and where "o" changes what end of the selection you're moving around - that feature alone just kills so many other editors).


The built-in help is nice because you can look something up with just ":h whatever" without switching to another term and digging out some help text. And with command line completion you can usually find what you're looking for even if you don't know its full name. And the help text has got neat tags (i.e. links) to other parts of the documentation.

[recurve boy]

why is vi/vim/emacs (i know emacs and vi are totally different) so special?

It can’t really be explained convincingly. If you can, find someone who’s been a heavy user of one of those for a while and watch him work over his shoulder. You’ll understand immediately.

I use vim all the time. I still hate most of the commands. A lot of it doesn't make any sense at all.

The big advantage however, is the way vim let's you navigate and manipulate text and the whole modal thing. I think this is the main advantage. I don't know about you, but when I code, it's super handy to be able to highlight text and manipulate it with a few keystrokes. Say you want to remove the first 'advantage' above :

/adv <- search, this accepts regex
d <- delete
w <- word

To copy a line:
yy

Delete a line:
dd

cc does the same thing but then puts you in insert mode. They should really just stick to d for delete and c for copy rather than yank for copy. Vi is really dumb that way.

Steep learning curve, but once you are used to it, you'll find that the whole modal thing plus motions is actually really handy is you are a programmer. And you'll eventually remember the really stupid commands Eg. q for record. r is replace a single letter, R is replace until you escape. r is really not that useful. And I (capital i) is not bound. i is insert. So why not I for replace? You can also do i <insert> to go into replace mode. But noooo.

Yeah, useful once you're good at it. But yet another example of programmers should never be allowed to design user interfaces.

I don't know about vi v vim though. The things I use often at the same between the both I think. Stop the super nerdery.