Vi Sucks
Vi SucksPlease insert EdIsTheStandardTextEditor where appropriate. Thank you.
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)
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.
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.
-- 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.
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 Word b move Backward one word e move forward to the End of the next word H move to the Highest/Home (top) of the screen M move to the Middle of the screen L move to the Lowest line of the screen ^d scroll Down a half screen ^u scroll Up a half screen ^f scroll Forward a full screen ^b scroll Backward a full screen ^n synonym: alternate way to move to Next line (taken from emacs) ^p synonym: alternate way to move to Previous line (from emacs) G Go 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 vis greatest strength;
[ to be continued ]
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?
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
EditText of this page
(last edited November 28, 2011)
or FindPage with title or text search