mike@whuxl.UUCP (BALDWIN) (10/01/86)
When I found out that vi 3.9 understood function keys and had
showmode (puts an I in the lower right corner when in insert
mode, R in Replace, r in replace), I thought "neato!" but after
using them for 5 minutes I got quite disgusted at the number of
bugs in the implementation:
The mode indicator goes off if you auto-word-wrap on the last
line of the screen.
The mode indicator goes off if you use any function keys while
in insert mode.
You are kicked out of insert mode if you get a beep from a
function key; e.g., if you use the arrows and hit the end
of a line.
If you press a function key while in Replace mode, you are
put back into Input mode instead of Replace (of course the
indicator has disappeared because of bug #2).
Function keys are implemented from insert mode by simulating
an ESC, doing the function, then simulating an "i" command.
This means if you are in a "cw" command, the line gets scrunched
when you press an arrow key, for instance. Not exactly a bug,
but it is surprising. This causes very undesirable behaviour
for some function keys, for example DELCHAR. When you press
DELCHAR in command mode, it executes the x command and deletes
the character under the cursor. Fair enough. Now say you are
in input mode. When you hit DELCHAR, an ESC is simulated, so
the cursor moves back one. Then DELCHAR (x) is done, deleting
the current char, and you are put back in input mode (i). This
has the net result of deleting the character IN FRONT OF the
cursor. Now try to explain this to a novice:
The DELCHAR key deletes the current character in command
mode, but it deletes the previous one in input mode.
Sounds stupid, doesn't it?
The main problem with VI from a screen editor point of view is that it
is really a line-oriented screen editor:
Forward and back word (b & w) go around lines, but forward and
back character don't. Also, forward word gets stuck at the end
of a line if it ends with a space.
Vi always wants the cursor to be on top of a character, instead
of between characters, so you can't have a 0-length buffer, and
empty lines look like lines with one space (the only easy way to tell
them apart is to do an "x" on the line and see if it beeps).
The newline character is a magic cookie. I can't point the cursor
to it, and I can't treat it like a normal character. Therefore,
because you can't "x" it, vi has another random command: Join.
This is the crux of the problem.
You can't backspace around newlines in input mode.
If you hit your line kill character in input mode, that line is
gone forever. It's sitting there in front of you, but you have
to type it in again.
In auto-indent mode, you have to type ^D to undent. Why doesn't
backspace work?
The other problem is that it is NOT a WYSIWYG editor:
You type any change command (c,C,etc) and you get this
funny $ at the end of the changed region and the $ and the
text you changed aren't really there. *Many* times I've had
novices use the C command and hit spaces to the end of the line
because they wanted to get rid of text that they didn't know
was already "gone".
This really makes it difficult to tell a new user what is
going on. You'd like to say "what's on the screen is what's
in the buffer" but it just isn't true.
Also random inconsistencies that make it very difficult to make
blanket statements:
The ]] command goes to the next line starting with {, but if
you use "d]]" it deletes to the next line starting with }.
I thought that the "d" command took a following motion command
and deleted from the current position to where the motion would
take me, but apparently not always.
I tried teaching VI to computer novices, but gave up because of the
non-WYSIWYG property and the constant confusion between input and
command mode. (This was 3.7 vi on BSD, so there was no showmode.
Even if there were, it would have been too brain-damaged to use.)
I was constantly trying to explain things like the DELCHAR botch
or the $ stuff which makes absolutely no sense to the average user.
Then I got smart and typed up a short command list of the 30 most
common EMACS commands arranged by function, and the pleas for help
dropped off dramatically.
--
Michael Baldwin
(not the opinions of) AT&T Bell Laboratories
{at&t}!whuxl!mike