Re: Difference between VC++ and UNIX



Al Balmer wrote:
In comparison, most of the free multiplatform editors I've tried are
primitive. Some of them can be made less primitive with some effort
put into customization and learning how to use it. One free
multi-platform editor with a very good feature set is Jedit, but the
resource requirements are fairly stiff. It's impractical to run on my
old HP R-380 box, for example.

Some differences are strictly personal - I hate vi's modes, for
example.

I think vi gets a bad rap for modes. In fact, I don't even think
it's a helpful description to say that it HAS modes. At least,
it doesn't have modes in the sense that

With most text editors (excepting the GUI-oriented ones), there is a
grammar that describes how you interact with the editor. That is,
you can sit down and write a set of production rules that describes
the legal input to the editor.

One way to think of this is that every command you can give the editor
is a sentence in that grammar[1].

To put this another way, the meaning of any single keyboard symbol
or character[2] that you enter on the keyboard is dependent on the
context in which the symbol is entered. So, virtually all editors
are modal, in the sense that a given input does something different
depending on the recent input. Virtually all editors store some
kind of state. The input drives a state machine.

The real issue with vi, which is what throws people, is that when
the editor first starts, the editor is not in a mode where typing
a character will insert it into the text. Most editors HAVE states
where this is the case; they just don't START that way. For example,
if I type C-x in emacs, that puts me in a state where typing "u"
does not insert a "u" into the buffer.

Few people really have a problem with the idea that the semantics
of a keypress depends on previous input. The real problem (other
than a serious lack of good documentation on vi, at least in the
old days) is that people expect that when an editor is started, it
will be in a state where a keypress inserts the literal character.

Now, combine that with the idea that every command to an editor is
a single sentence in a grammar. When you've finished entering a
sentence, the editor is (when it comes to the grammar) normally
going to be back in the same state it started in. If you think of
entering a command, then letting the editor sit "at rest" while
you think of the next thing to do, then entering another command,
and so on, the "resting" state of most editors is a state where
typing a character on the keyboard will insert that character.
Not so with vi. With vi, the "resting" state is one where the
character is a command, not itself.

Just to illustrate my point, here is a list of commands you
might enter in vi, with one command on each line:

iHello, world.[ESC] insert the text "Hello world"
yy make a copy of the line
p paste that copy
:w[RETURN] write the file to disk

Note that at the end of every command, vi is ready to accept
another command. Also note that the first complete command
inserts some text.

This is why I think it's not very accurate to think of vi as having
modes. You're not switching to "command mode" when you hit ESC;
instead, you're finishing an "i" command. You are *always in*
command mode; it's just that some of the commands involve inserting
some text.

Also note that if I wrote down a similar list of commands for
another editor, emacs, you'd see the exact opposite pattern:

H insert the text "H"
e insert the text "e"
l etc., etc., etc.....
l
o
,
[space]
w
o
r
l
d
. insert the text "."
C-a move to the beginning of line
C-k kill text to end of line
C-x u undo
C-e move to end of line
C-y yank the killed text back

Note that, like in the case of vi, some of these commands (just
one in this example) are multiple keystrokes long, and some of
the keystrokes in the commands are printable characters but
don't self-insert. (That'd be the "u" in C-x u.)

What's the key difference here? At the end of everyone one of
these commands, emacs is back into its starting state, which is
a state where typing a printable character inserts it into the
text.

So, to put it concisely, emacs (or at least this subset of it --
I'm not an emacs expert) has a property that vi doesn't: in emacs,
if a sentence in the grammar begins with a keystroke that corresponds
to a printable character, the sentence is the keystroke, and the
meaning of the sentence is to self-insert. vi has a completely
different property: there is NO sentence where the sentence is
the character and the meaning is to self-insert.

Anyway, the point here is that the description of vi having two
modes and constantly switching between them is a bit confusing.
It doesn't really capture the essence of how vi operates very
well. It's much cleaner to think of vi as a state machine where
you can't directly get to "insert this character" directly from
the start state and where ESC doesn't change modes but instead
takes you back to the start state.

- Logan

[1] Or you can think of it as a single sentence that drives your
entire session with the editor, in which case if CMD is the
starting point of the grammar for a single command, you can
write

SESSION -> CMD SESSION
SESSION -> ""

as the grammar for the whole language. So the two ideas
are basically equivalent. But I digress...

[2] but there can be keystrokes that aren't characters, like
a letter combined with the "Alt" key, for example.
.