From: gbergman@ucbcartan (George Mark Bergman)
Date: Fri, 23 Sep 83 13:53:36 PDT

Latest letter on ex~vi to Horton:

Dear Mark,

     I hope I can assume that after my long letter to which you
replied, you did get my two shorter notes (one sent the same day,
the other about a week later); and that you've simply been to busy
to think about them or reply.
     However, since I have had bad experiences with Mail, I am worried
that either you may never have gotten them or that you may have replied
and your replies not reached me.  I hope you can send me a one-liner to
relieve my doubts.

     Not many bugs to report this time, but I will modify or discuss
a few of the suggestions I've made before.

     One that I want to modify is my suggestion that % should also
match < with > and ` with '.  All right in itself, but terrible if it
would also mean that with  :set match,  every time one typed a > or a '
the cursor would look for the last occurrence of < or `, since <, >, and
' can occur in ways that have nothing to do with matching.  So I think
that making matchable pairs user-specifiable would be much more useful.
Faith Fich (who send her regards -- she and Mike were our neighbors till
a month ago, but have left for their new jobs at U. Seattle) suggested
that user-settable matches would be particularly useful for those
like herself who use distinct opening and closing delimiters with eqn.
Actually, on further thought this isn't quite right, since eqn
delimiters behave differently from parentheses -- if I want to use =
as my delimiter to enter equation mode, and & as my delimiter to leave
it, then eqn will not give any special treatment to &'s in text mode or
='s in equation mode; so perhaps a different kind of matching for
that kind of use might be desirable; one would set  :set dmatch =&
for the delimiters suggested above; or :set dmatch $$  if one uses  $
for both delimiters as in the eqn tutorials.  I know checkeq is
supposed to serve this function; but it would certainly be convenient
to have it in the editor; and anyway, my experience was that checkeq
didn't understand that one could have distinct opening and closing
delimiters.  (But this is a disinterested suggestion; I haven't used
eqn for a long time; I put in my equations in raw troff.)

     The suggestion in my long original letter about an alternative to
the diagnostic "using open mode" was based on a misunderstanding -- but
one that might be worth making a reality.  I had been assuming,
since tutorials referred to the "three states" ex, vi, and open, and
since I knew one could enter the editor by typing  % ex filename or
% vi filename, that a third way to enter the editor was by typing
% open filename, and that this is what one should do when editing
with a device not having an addressable cursor (which I had never done).
So I supposed that the diagnostic "using open mode" would only be
received if one were trying to use the wrong mode of the editor for the
tty type shown in  one's environment.  Perhaps one should indeed have
special way to enter the editor when one intended to edit in "open
mode".  (If "open" has other uses as a command, the command might be
"vo" or "op".)  Then if a user gave the command vi and his
environment did not indicate a device with an addressable cursor, it
would indeed be appropriate to give a diagnostic informing him that his
environment was not compatible with this command.  I suggest this
because of the frustrating experiences I had as a beginner, of
being put into open mode (because my tty type had somehow been lost)
and not knowing what I could do about it.

     I am somewhat confused by your explanation that editor scripts
that would go back and forth between ex and vi modes (using the :vi
and Q commands) are impossible because "The internals of getting a
character from the tty are completely different in ex and vi.  Pushing
input for one doesn't affect the other."  A vi "script" (i.e. a mapping
or a macro called by @x) can presently include bottom-line commands
called with ":".  I would suppose that the way such commands get
characters from the terminal is about the same as the way ex does.
You also write that "Any : command that outputs more than 1 line puts
you into "ex mode"," -- is this a different sense of "ex mode"?  If
not, what happens when a vi script does this?
     I mentioned that the :so command from vi ignored anything after
any global command in the sourced file.  I also find that it will not
accept the ex commands i and a; I realize that a prohibition against
these is part of the way vi's bottom line differs from genuine ex.
I've just done some experimenting, and I find that a script sourced
from the bottom line of vi also interprets the command vi as a command
to edit another file.  Do we really want script files to be interpreted
so differently when sourced from ex mode and from the bottom line of vi?
Or if these differences are inevitable, can't the vi version at least
have the positive difference of being able to go to visual mode with
^M^M or something, and continue following the script, interpreting
characters as screen mode commands, just as a mapping or @x macro will
if it has gone down to the bottom line with ":" and come back again?
     I am also still reluctant to give up the idea of a version of the
editor in which there is no difference between the line-oriented mode
and the bottom line of the visual mode.  Suppose you took the editor as
it exists now, and modified it so that in visual mode, ":" was
interpreted as "Q", and in ex mode, ^[ was interpreted as ^Mvi.  The one
obvious disadvantage would be that it would insist on redrawing the
screen after minor editing operations in ex mode.  So suppose you made
it remember the previous state of the screen every time it entered ex
mode, and make the necessary adjustments on return to visual mode if the
editing done was fairly trivial -- using the same criteria it now uses
after bottom-line commands.  What would be the problem?
     Of course, I know I am quite ignorant of what is involved, and what
I am suggesting as possible may be quite impossible, or may have to wait
for that far-off day when you rewrite the editor.

     You write that some of the restrictions on global commands are due
to the fact that the state of the buffer before the command is stored in
the "last deleted" buffer.  But couldn't this situation be modified?
Let's call the "last deleted" buffer buffer 0, since material from it
seems to progress up to 1, 2, etc. with successive changes made.
Suppose things were set up so that during the operation of a global or
macro, deleted material, yanked material, etc. went by default into
buffer 1 instead of 0...?  Or alternatively, that the state before the
global were saved in buffer 9, and this was then set outside of the
chain of buffers into which material got pushed with successive
deletions, during the operation of the global?  Would this eliminate
the objection to nested globals as well?  Presumably, in a global within
a global, the previous state would be stored in buffer 1, and new yanks
put by default in buffer 2 (if the first of the above suggestions were
followed).
     You mention in your comments to my letter that the difficulty of
editing command lines "is a standard complaint about a moded editor"
that would be hard to fix.  But I point out in that same letter how
appropriate macros or script-files can overcome that difficulty.  (My
files "do/1", "do/:" and the "map ^A ..." in my EXINIT.)  It should be
possible to introduce commands that would have the
same effects as those macros.  (Or at least, to describe such macros
in the documentation.  I have realized, by the way, that ^A was a poor
choice of character for me to map, because it occurs in the output of
function keys on a lot of terminals.)

     It would be nice to extend the kinds of "regular expressions"
allowed in searches, e.g. a la egrep.  Sometimes I also want to indicate
something like "a substring of precisely 40 characters".  This can be
rendered as "........................................" at present,
but things like that can easily lead to commands that
exceed length limits.  (Suppose one wants to look for a string of
40 successive characters other than whitespace.  [^ ][^ ][^ ] ... is
too long.)  Have you checked out what I mentioned in my first long
letter, that ed allows you to search for (e.g.) successive
identical characters as \(.\)\1?

     Let me pass on a suggestion made recently in a system message by
someone named nye.  He was worried about what would happen
if while one person was editing a file, someone else with write
permission for that file also began editing it.  Presumably, whoever
did a "write" last would overwrite the other person's work.  He
suggested that there be a diagnostic "file has been changed since last
write" for such a situation.  (In particular, he wondered what would
happen if he got his mail by editing /usr/spool/mail/name, rather than
by using Mail -- which is certainly tempting if one is more comfortable
with the editor than with Mail -- and if unbeknownst to him new mail
arrived while he was editing.)

     I have discovered the hard way that when one has done a
vi -r filename  and decided one was satisfied with the version that
was saved, ZZ or :x are  n o t  the same as  :wq  -- the first two
discard the saved file, and only the last one writes it over the
previous version.  (I actually haven't checked this out on version 3.9.
I tried to, and found that robert hadn't brought
/usr/lib/ex3.9{preserve,recover}, if that's what they're still
called, from arpa along with the rest of 3.9.  But he's getting them for
me.)  If you don't want to make  ZZ  and  :x  actually equivalent to
:wq, you might at least make them give error messages forcing the
user to make the explicit choice of :wq to keep the saved version, or :q
to discard it.

     I've been having fun using recursive "map" commands from time to
time.  For example, a file of mailing addresses of Math Departments is
being prepared, for use with a new Computer Services command "label".
This requires that each address constitute one line of the file, with
the intended lines of each label separated by
semicolons rather than newlines, each being no longer than 34
characters.  At present, the lines in the file are of the form
[university-name];[city-state-zip]
and I wanted to find cases where the university name the secretaries
had typed in was over 34 characters long.  So I did
:map ^A +36^V|F;^A0
Then, when I hit ^A, the cursor went bopping down the file, passing
through each line at which it could find a ";" before the 36th position,
but stopping when it hit a line where it could not.  When I had
corrected such a line, by abbreviating a long word or whatever, I could
hit ^A again and find the next case.  The "0" at the end of the map
command is to prevent the "No tail recursion" rule from aborting my
mapping.  It has no other effect, because it is never reached.
     Of course, the above example of a recursive mapping is guaranteed
to stop eventually, if only by reaching the end of the file.  But I find
that mappings that can go on indefinitely are very hard to stop.  E.g.
:map q ax^[q0
I've tried some like that, and sometimes hitting <break> or whatever
enough times successfully stops them (often leaving a bit of a mess --
characters that ought to have come after the string of x's embedded
among them), while other times the only thing I can do is to go to
another terminal and kill the editing process.  Maybe it is to prevent
things like that that you put in the "No tail recursion" rule --
though clearly it can be gotten around.  Might it not be better to
somehow make the editor not quite so deaf to <break>s during such a
process?

     I will mention one curious experience which I have not been able to
reproduce.  I use :set nu.  After a delete near the beginning of a file,
I found myself looking at a screen with line-numbers beginning around
-2!  The lines with nonpositive numbers were blank, if I recall; lines
1, 2, etc. were as they should be.  I mentioned this to someone
who said he'd had the same thing had happened at times, but had
never been able to figure out what conditions caused it.

					Best regards,
					George