''Please insert EdIsTheStandardTextEditor where appropriate. Thank you.''
* That's a classic and funny-enough humor piece that I think I'll just go ahead and give it primacy here at the top of page where you mention it. :-)
----
ViSucks. Just not as bad as the other editors. VimSucksEvenBetter.
----
"There's even a version of vi for the DOS world, although giving some poor DOS user a copy of vi is like throwing an extra pair of handcuffs on an already-shackled prisoner." (Chuck Musciano)

"Emacs rules. vi drools"(Chuck Musciano)

  All the vi users are angrily sending e-mail that reads something like this:

	You are a blithering idiot! Emacs is the worst editor ever
	invented! I learned vi and I've never needed anything else!
	:wq!
	^[kdd:w!q!ZZ
	^C^D.exit
	quit
	logout

  (Chuck Musciano)

[Given that some people pronounce "vi" as "six":] The plural of vi is 666. (Luis Fernandes)
--------
"The command keyboard mappings make no sense, and even worse, you can't modify the basic keyboard maps." (Chuck Musciano, 1995 SunWorld article)
* False on both counts, although it's true that it is not '''as''' modifiable as e.g. emacs. (Keystroke map choice explained below)

"Buffer management is barely capable of editing multiple files, and viewing multiple buffers is impossible. There is little support for language-based editing and the lack of general extensibility makes it impossible to extend vi to handle other languages."
* All true! Of the original, "classic" vi, that is. Although it's very important to note that classic vi always had regular expression search and replace (thanks to ed), which emacs did not add for many years. Anyway, it was '''impossible''' to do more. '''vi''' ran on a 64K RAM system!
* (nitpick: actually 64K RAM of data and a separate 64K of instructions, and the first vi ran on a PDP 11/70 with '''core''' memory, which is in fact a kind of RandomAccessMemory, but "RAM" is more often used to mean "semiconductor RAM", and back then, was contrasted with "core". Core memory, btw, was a grid of wires with each row and column of wires threading through a toroidal two-state magnet (the "ferrite core"), each holding a single bit).
* So '''vi''' didn't have the space for extra features, even though some of them existed in e.g. Emacs at the time, and BillJoy was aware of that. But Emacs ran at the time on a DEC 10 (a.k.a. PDP 10), a '''much''' larger and expensive system (it used a PDP 11 just to control its front panel switches and blinky lights!) - it had a 36 bit word (compared to the PDP 11's 16 bit word) and 4000 Kbytes (4.0 Mbytes) of RAM (compared, again, to the PDP 11's 128 Kbytes / 0.1 Mbytes of RAM, ran at about 1.5 MIPS compared to PDP 11 0.67 MIPS (http://www.jcmit.com/cpu-performance.htm), and cost a million bucks and up, compared to PDP 11/70 at more like $100K and up.
* Bill at one point removed some word processing/text formatting features, and when I complained, he said that after various bug fixes and such, he only had '''eight bytes''' of instruction space left, and invited me to find a way to make room for any features I wanted.
More recently this has become an issue of making a virtue of necessity; many dislike emacs' attempts to be all programs for all purposes all rolled into one bloated monster.
--------

The root principle of Usability (as a discipline for designing HumanMachineInteractions) is this: A UserInterface shall be easy for newbies to learn, and shall not interfere with proficient user repeatedly accessing advanced features. 

Vi fails both sides of the bargain, not because its keystrokes differ from the magic CommonUserAccess, but because they are inconsistent within themselves.

* Positively false on the second account.  While I will agree that Vi is not trivial for a newbie to learn, to claim that those of us who have learned it and become proficient with it cannot do so without "interference" is just plain wrong.  Wrong!  It is so wrong that it defies further explanation to support my position.  I mean, command set orthogonality is, umm, ''orthogonal'' to the capabilities of the human mind.  We're talking about night versus trees, cars versus leather, and apples versus chairs.  The comparison is so far off as to be utterly nonsensical.  --SamuelFalvo

Only MuscleMemory permits proficient users to accommodate the many ways Vi cannot even make up its own mind about the nature of text editing. The editor is inconsistent even about simple concepts like whether a text cursor operates on the left or right side of its character.

* Again, false.  When in command-mode, the cursor points '''at the character to be operated upon.'''  When in insert-mode, it points to where '''the next character you type goes.'''

When you type A for Append, you move the right side, and I for Insert gives you the left side. It only does that because it doesn't always treat \n as a character, so A fails at the beginning of a line, and they added I to compensate. This would be almost harmless, except that after typing new text, Vi remembers its confusion for you, and Escape will move the text cursor to the left if Vi remembers you typed an A. 

* How convenient of you to make a generalization that is factually wrong.  The A versus I issue (don't forget their shifted variants too!) is a matter of convenience.  Why type "li" when I can just type "a" for append?  I mean, doesn't ''append'' mean to tack something onto the end of something?  Like, oh, say, the current character?  And their shifted versions do similar things on whole lines.  Shift-A will append to the line (instead of the current character), while shift-I inserts at the beginning of the line.  See how nice and consistent?  You are correct that Vi has inconsistencies, but please at least research what they are first.  --SamuelFalvo

Typing quickly without constantly readjusting your mental model of the editor's state requires you to subconsciously remember and accommodate many minor inconsistencies like these. 2 of my 4 years using Vi were with Vi classic, the kind that did not even support a modern keyboard's cursor keys.

* I already told you this last phrase is just '''factually''' wrong, and I'm certainly in a position to know. You are in a position to check, since the ancient first versions of vi's documentation is these days available online. I also explain the likely reason that you (and various others) were likely to have gotten that misimpression.  --AnonymousDonor

I have seen people type, faster than I ever could, in classic mode on modern Vim. It's a scary sight, and a reminder that complete Vi proficiency is inaccessible to many people, even if only in terms of their aptitude for menial keyboarding prowess.

* Yes, just like complete mastery of Microsoft Word is unattainable to many.  And did I remind you that the GnuEmacs book is, what something like 2.5 to 3.0" thick?  I ''sure as hell'' will not read a book that thick to use an editor.  Not saying you ''have'' to -- very few people I know have books on either Vi or Emacs.  But, let's face it, you ascribe to Vi something that is equally ascribable to MS Word, Emacs, and I'm sure so many other programs as well.  IntellijIdea is equally opaque to me in many ways.  --SamuelFalvo, happily editing his responses to you in, you guessed it, Vim.

-- PhlIp

''moved back from EmacsVsVi because Emacs sucks too. StockholmSyndrom reduced...''

Note added later: I have almost 2 years flight time on ''vi''-classic. The bad old days. I was as proficient then as I am now on my favorite editor. I am not a newb complaining the editor is newb-hostile (though that is also a legitimate complaint...).

When you navigate to the beginning of a line and tap <left>, or its (QWERTY-bound) equivalent, and when the text caret does not go to the end of the previous line, this is nothing but a ''bug''. The editor threw away a keystroke, not because it would be "inconsistent", but because the original SystemMetaphor for the project had no consistent pattern for treating text as a string of beads.

* No, actually, it betrays you clearly as a ''newbie'' to Vi.  It's not a bug.  It's how it's been designed, and I'm sure for very good reasons.  BTW, are you aware that modern versions (at least as of 1985) implementations of Vi can be configured to allow the string-of-beads model?

Now I will go back to work, on MacOsx, where the <End> key either does nothing, or does something you rarely want, all because SteveJobs's CultOfPersonality is more important than putting the most-needed keystrokes onto unshifted keys... >elaborate sigh<

-- PhlIp

Since ''someone'' deleted my previous comment without reason, here's one that will hopefully not suffer DisagreeByDeleting.

No, Vi does not work like Notepad, nor Emacs. Vi follows the convention of most other Unix tools, which is that text is treated as a series of lines, and not a "string of beads", in tools above system programming.

You ''do'' have to use an entire three keystrokes (k$) in order to get to the end of the previous line, even if you are on the first character of the line. Boo-hoo. I don't need to do that anywhere near often enough to need the feature you're talking about. In fact, I appreciate the supposed 'bug' because I can reach the beginning or end of a line without learning the ^ or $ commands (which I didn't until recently), simply by whacking the directional keys until I get there. The "fix" that would make it work ''your'' way would make things harder for me. Calling it a ''bug'' because it doesn't please you is egomanical. --JesseMillikan


----

'''Briefly''': vi is nowhere near as inconsistent as you claim; it's actually quite consistent - and consistency is a rule of thumb to assist the actual goal of usability, anyway, not an absolute. And vi is not confused; each thing you have a distaste for was done for a specific usability reason, whether that's apparent to you or not.

'''Addressing your one specific example:'''

You said it's "inconsistent even about simple concepts like whether a text cursor operates on the left or right side of its character. When you type A for Append, you move the right side, and I for Insert gives you the left side. It only does that because it doesn't always treat \n as a character, so A fails at the beginning of a line, and they added I to compensate. This would be almost harmless, except that after typing new text, Vi remembers its confusion for you, and Escape will move the text cursor to the left if Vi remembers you typed an A."

This is literally just wrong, since "A" means append at the end of the current line, and "I" means insert at the start of the current line. But you probably are misremembering, and meant to be talking about "a" and "i". It is still false that "it only does that" because it isn't fond of \n; the latter is true, this is a '''line editor''' we're talking about, not a '''character editor''' (each style of editor has their points depending on one's purpose, but neither style is outright wrong). The rest doesn't follow, though. The "i" inserts before the current character and the "a" afterwards, in the middle of a line, at the start of a line, and at the end of a line; the \n issues are not even involved here unless you insist that all editors must be character editors and that you should be allowed to put the cursor on top of the invisible \n. In the middle of the line, it's obvious this is a strawman; it's merely useful to be able to insert either before or after the current point.

Your final point in the quoted text above, about '''vi''' moving the cursor left, is very confusingly worded, but ultimately not totally incorrect about what '''vi''' is doing, but it's still incorrect to say that '''vi''' is "confused" or "inconsistent" here. It is being completely consistent: after each character inserted, the cursor of course moves rightward, and then at the end of the insertion, the cursor is moved backwards one place, so that the cursor is always left sitting on top of the last inserted character. There's nothing confused or inconsistent about this, even if '''vi''' were indeed a character editor.

There '''is''' one issue in this area, that you may not completely remember but that perhaps fueled your annoyance on the general subject: if you enter insert mode (with either 'a' or 'i') but change your mind and leave insert mode without entering new text, '''vi''' will nonetheless still move the cursor backwards one place. Repeating such a sequence will sequentially move the cursor further and further leftward while nothing else happens. I personally regard this as an oddball anomaly (that one quickly gets used to), but still easily arguable as a bug from a CHI perspective - but it's certainly not a bug of inconsistency (nor confusion), it is the opposite, it is a foolish consistency, that '''vi''' behaves precisely the same way whether you actually add new text or not.

That's a perfect example of why "consistency" is absolutely not a primary rule of CHI. Here, I'm complaining (as many do) that '''vi''' is being annoyingly consistent rather than taking into account the fact that I didn't type text. But if it did what I would prefer, then the (vast, vast number) of absolute consistency advocates would then complain, because it would not being absolutely consistent. In this sense, you can't win.

'''And in depth, on vi's design and design philosophy''':

Re: "Vi fails both sides of the bargain,"

You contradict yourself, since you end up saying expert users do amazing things (a common observation, btw), so at most it fails just one side of the bargain you propose.

Studies on the subject contradict the other side of it. Anecdotally there are plenty of people who say they found it hard to learn, but actual observations and formal studies show little difference in learnability between vi and an array of other editors.

	 :	I'd love to see these studies... 

Re: "...not because its keystrokes differ from the magic CommonUserAccess"

It's absurd to bring that up, since (A) surely you know that vi and its keystrokes pre-date IBM's PC CUA "standard" by a decade, and (B) it was a literal "standard" only in the IBM PC market, and as I recall, was strictly observed only in OS/2, although it was more casually influential elsewhere in the PC world - but in any case, the Unix world has seldom cared about what's standard in the PC/IBM/Microsoft world, so that's irrelevant. And (C) I deny that CUA is any sort of ideal in terms of CHI.

Re: "but because they are inconsistent within themselves."

Not true, but first: aiming for consistency as an end in itself misses the point; consistency often makes interfaces easier to learn, easier to remember, and easier to use for both simple and complex tasks - '''but''' if there is an exception, then consistency should be discarded in favor of the the actual goal of CHI usability. Consistency is just a rule of thumb, not the end goal.

"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day. 'Ah, so you shall be sure to be misunderstood.' Is it so bad, then, to be misunderstood? Pythagoras was misunderstood, and Socrates, and Jesus, and Luther, and Copernicus, and Galileo, and Newton, and every pure and wise spirit that ever took flesh. To be great is to be misunderstood." -- Ralph Waldo Emerson, "Self Reliance"

'''vi''' is in any case more consistent than it is usually given credit for, and its inconsistencies are generally quite conscious and designed to achieve a very particular usability goal. Bill studied and experimented with existing display editors (e.g. Teco Emacs and the windowing Rand editor) as he designed and implemented vi - where vi differs from e.g. emacs, it was for particular reasons, not out of ignorance - and he experimented with various keystroke possibilities in vi, and never hesitated to make backward-incompatible changes to increase its usability when he noticed problems. I argued with him continually about the issues involved, and he was generally persuasive about his reasoning, but was always open to criticism in those areas where he did not have a usability counter-argument.

As background, Bill was an extremely fast touch-typist (as were all of his early users), and strongly believed that editors should not get in the way of fast touch-typing. Even you apparently believe he achieved that particular goal.

Inescapable implications well-known simply from the ergonomics of typing, never mind computers: the users' fingers should '''never''' be unnecessarily forced to leave the touch-typing "home" position. (Modern GUIs that '''require''' frequent use of the mouse during editing fail on this count.) This means no required use of extraneous keys like function keys, cursor keys, numeric pad keys, etc. Use of shift keys (and even more so computer shift keys like control, alt, meta-bucky, etc) should be minimized, since it has been known (studied to *death*) since the early days of the 20th century that shifting (a) slows typing, and (b) increases fatigue (possibly RSI, too).

The Caps-Lock was invented on typewriters for a reason, and that was it: if a long sequence of capital letters must be typed, using shift for each is much slower and much more fatiguing (and therefore highly annoying to the user). Caps-Lock enters a '''mode''', generally considered in recent decades by purists to be an inherent evil. Purists are wrong; they are intellectualizing rather than going through the pain themselves. Let them type an entire book in capital letters using only shift, not Caps-Lock, and they will see the error of their ways and admit that modal interfaces have their place.

Back to vi: the above considerations '''require''' the two modalities of "insert mode" versus "command mode"; the only alternative is to make heavy use of shift keys, as does Emacs' control and meta shifts (which achieve the intellectual goal of modelessness, in this one narrow sense anyway, but which are awkward, slow, and fatiguing).

BTW the non-printing ESCAPE key is/was the only non-printing key standardly available on computer keyboards, and is in range of touch typing, so Bill naturally made use of it in vi, to switch between insert and command modes. It was a forced choice. It had an unfortunate side effect, though: many terminals (and all that follow the more recent ANSI standard for terminal control) use ESCAPE as the introducer for terminal control sequences, particularly including cursor keys. Bill was thus in the awkward position of needing to tell the difference between a user-typed ESCAPE versus one sent automatically as part of a cursor control sequence from the terminal. To his credit, he didn't punt on the problem, he solved it very early on. Unfortunately the only possible solution is timing-based, which means that terminals with misconfigured termcap/terminfo entries can break that mechanism, causing cursor keys to fail, explaining your previous impression that they weren't supported.

In the above article: "To make sure I wasn't missing some fundamental feature of vi, I queried several long-time vi users in regards to vi's best feature. They all gave the same answer: consistency and availability." - I.e. '''vi''' fans find vi to be consistent; maybe they have a better mental model of what's going on than do vi foes.

First look at moving around on the screen/in the file. Some people are irked that vi uses h, l, j, k for cursor left/right/up/down, since these keys seem randomly chosen with no mnemonic. However, apparently-random clusters of keys like that are still in strong favor even today in e.g. many first person shooter games, where rapid control is essential. This pretty much proves this to be a non-issue right away.

However, originally these keys ''were'' mnemonic: vi was originally used only on Lear Siegler ADM-3A terminals, for which those keys were in fact the cursor keys, and the keyboard labeled them appropriately with left/right/up/down arrows (originally one needed to do control-H/control-L etc, later Bill removed the requirement of using control). Lear Siegler's choices were in turn also mnemonically motivated: control-H is ascii BACKSPACE (move left), control-J is ascii LINEFEED (move down), control-K and control-L could simply be chosen following that as conveniently clustered, however they too have some mnemonic value: control-K is ascii VERTICAL-TAB (reasonably interpreted as move up), and control-L is ascii FORMFEED (lineprinter page break/feed/newpage/move forward one page, reasonably mnemonic for move forward one character). That's just BTW, since it's not very well known.

Next, vi was built on top of the venerable ed editor, which is a whole separate topic, but for the moment let me note that this was a very, very good thing, and still to this day, those "ex" features are still very important and powerful; this is not a matter of primitive avativism due only to random historical reasons and needless backward compatability.

That said, ed/ex regular expression search uses (as the whole world has come to know due to borrowings elsewhere) ^ to mean "start of line" and $ to mean "end of line" and / to mean "search lines forward" and ? to mean "search lines backwards. '''vi''' borrows these 4 characters, with the same meaning, in command mode, beyond their use in ex commands, so these 4 are mnemonic because, both back then as well as today, basically everyone knows them for other reasons.

Then there are other ways of moving around, each quite mnemonic and consistent (at least to the extent that you can't find a more consistent choice without sacrificing something in the process):
  w  move forward one '''W'''ord
  b  move '''B'''ackward one word
  e  move forward to the '''E'''nd of the next word
  H  move to the '''High'''est/'''H'''ome (top) of the screen
  M  move to the '''M'''iddle of the screen
  L  move to the '''L'''owest line of the screen
 ^d  scroll '''D'''own a half screen
 ^u  scroll '''U'''p a half screen
 ^f  scroll '''F'''orward a full screen
 ^b  scroll '''B'''ackward a full screen
 ^n  synonym: alternate way to move to '''N'''ext line (taken from emacs)
 ^p  synonym: alternate way to move to '''P'''revious line (from emacs)
  G  '''G'''o to a specified line number (or end of file if none specified) 

Given that the goal is to have commands be a single character, these are all perfectly reasonable choices, since they all have a motivating mnemonic. Some have complained that 'b' should be "back one char", not "back one word", etc, etc, etc, but when it comes right down to it, there is nothing compelling about similar but different assignments, aside from idiosyncratic tastes.

Capital 'G' is used rather than lower case 'g' because the latter originally (starting in ex version 1.1) meant "grab" - which eventually went away, leaving 'g' unused in late versions of classic '''vi''', but meanwhile users had incorporated 'G' into muscle memory, and 'G' is still mnemonic anyway.

'''Modular composition of commands'''

This is '''vi'''s greatest strength;

[ to be continued ]

* Only MuscleMemory permits proficient users to accommodate the many ways Vi cannot even make up its own mind about the nature of text editing. The editor is inconsistent even about simple concepts like whether a text cursor operates on the left or right side of its character. When you type A for Append, you move the right side, and I for Insert gives you the left side. It only does that because it doesn't always treat \n as a character, so A fails at the beginning of a line, and they added I to compensate. This would be almost harmless, except that after typing new text, Vi remembers its confusion for you, and Escape will move the text cursor to the left if Vi remembers you typed an A.

Re: "The root principle of Usability...: A UserInterface shall be easy for newbies to learn, and shall not interfere with proficient user repeatedly accessing advanced features."

There are plenty of CHI experts who would disagree that that is '''the''' root principle, as opposed to a simple rule of thumb. The phrasing isn't right, either, since it e.g. allows for dirt simple editors that don't even have advanced features to start with.

A popular quote that is closer to the spirit (and also closer to being part of the core root principles rather than a rule of thumb) is "Simple things should be simple to do, and complex things should be possible to do."

Note "to do", not '''necessarily''' "to learn". There's no point in something being needlessly difficult to learn, but sometimes there are perfectly valid, or even unavoidable, reasons for something being difficult to learn. General Relativity is an obvious example; it requires learning (sometimes concurrently) differential geometry and tensor calculus, which have their own respective prerequisites, which amounts to a high enough barrier to learning that extremely few outside the profession (physics or math) ever do.

----

You say Caps Lock is necessary. I totally disagree and have mapped it to control on my PowerBook. Why? Because it gets in the way and is sometimes mistakenly pressed and I never actually need it. I can't imagine why anyone would want to write long passages of text in only capital letters, but even then it makes sense to just select the text and chose something like "Capitalize" from a menu. Caps Lock may have had its uses in typewriters which lacked any kind of sophistication, but it is not needed in a modern computer and keyboard should get rid of it. -- KristofferLawson


You're misunderstanding by taking the comment out of context. I despise CapsLock on PC keyboards. It's a great evil, for the reason you note, but 95% of the problem is that the PC industry (due to IBM) put it in an idiotic place... the place where the rest of the industry used to be fond of putting CONTROL. It's idiotic to put it there not because of taste, but because it was, and is, un-ergonomic. It is, for almost everyone, at best an infrequently used key, yet it was given one of '''the''' most accessible places on the keyboard, on the left of the home row. That was and is just a mistake. There's no good reason for it to be there.

The original point and context that you are missing is that it was about '''TYPEWRITERS''' in the early 20th century, decades before the first computer - various law/business offices needed a lot of caps, and it made sense then ergonomically, given that long sequences of caps were typed. It would make sense today (in a different keyboard position!), too, if long sequences of caps needed to be typed. (Discussing menus for CapsLock, or anything else, is getting too far off-topic; move CapsLock, absolutely; delete it rather than move it, different issues.)

Taking CapsLock as an item in isolation misses the original point of why it was brought up: people today tend to think ergonomics was invented about 20 years ago, but no, it's an old field, and quite a bit was known about the ergonomics of typing before the computer era, and CapsLock was invented for a reason back *then*, and quite similar issues still apply '''to things other than CAP''' today.

(Someone will be tempted, upon seeing "ergonomics" and "typewriter" and "early 20th century" to have the usual knee-jerk reaction of raising the myths (often) and truths (infrequently) of qwerty vs dvorak. Please don't. This is not the page for such, and the topic has been adequately covered on c2 and elsewhere, anyway.) -- DougMerritt
----
Fact: those good with sed are good with vi. This speaks volumes.

Fact: those good with lisp are good with emacs.  Emacs can emulate vi. Can vi emulate emacs?
*No, and that is TheWayGodIntended.  What is it with Emacs users and their incessant, insipid, disgusting need to judge everything they see by its ability to emulate everything under the sun?  Criminy, you're worse than JehovaWitness''''''es knocking on people's doors at dinner time.
Fact: Only those with genitalia implants, lots of cash, or who use Emacs think they have something to prove to the rest of the world.

Fact: You don't.

65 percent of vi users are more than casually involved in the Society for Creative Anachronism, in contrast to 34 percent of emacs users. (Ok I made that one up but it makes sense.)  ''But the remaining 66% of Emacs users are involved in Civil War re-enactments, so where's the difference?''

Last Save By: Shahzeb Abbasi