Subject: editor

From: gbergman@UCBCARTAN (George Mark Bergman)
Date: 29 Jul 83 16:02:06 PDT (Fri)

29/7/83
    I got a reply from Horton: a copy of my (first) letter,
annotated with comments that this should indeed be fixed, that
would be impossible, etc..  I'll send a copy to anyone who'd
like (or a copy of his comment on some specific bug they're
interested in).  Meanwhile, I'll send you my reply to him, since
it discusses still more bugs and possible improvements.

Dear Mark,
     Got your comments on my first letter!  Did you get the second,
shorter one?  Glad to see that some things, at least, can be fixed.
     Robert has put version 3.9 on this machine and I'm using it.
Using movement arrows within insert mode is amusing; though when there
is documentation, there should be a warning to the user that these
prevent ``u'' from undoing anything before those commands.  But
the first thing there needs to be documentation for is vedit!  Is
any being written?
     In your comment on ``Can't yank inside global/macro'' you said
that one can, of course, always yank to a named buffer.  I checked,
in the case of @a scripts, and the answer is yes and no:  The yank
works, but one still gets that diagnostic, and anything else in the
sequence of commands is aborted.
     And concerning the diagnostic ``Can't undo in global commands'' --
I understand what you say about why one can't, but it still seems an
unenlightening and perhaps inappropriate diagnostic to get when one has
done  @a  and buffer  a  contains say
	x:g/foo/s//bar
Here the initial ``x'', deleting the character the cursor was on when
the command was given, creates the text-modified condition which,
as I mention, seems to cause globals in @-scripts to give this
diagnostic.  I've just tested the above script -- several times,
because I found it hard to believe what was happening -- and it did
indeed give the diagnostic in question, but instead of replacing foo's
with bar's, it replaced the first line containing a foo with a copy of
the last line of the file! I leave it to you to figure that one out!
(This is on version 3.9.  Incidentally, I've used a true ^M in that
script, so it is ready for you to try.)

     Further observations on some of the bugs I mentioned in my
second letter:  The business with  yb  is both more general and more
complicated than I realized.  The general fact seems to be that when
one does a yank to a position earlier on the same line, the cursor does
not move, but the editor thinks it has, so that any subsequent command,
e.g. a movement, a delete, etc., has the effect that it would if it had
been done with the cursor starting from the new position.  The
complication is that yanks to named buffers don't behave the same as
simple yanks: They also leave the cursor unmoved, but what they actually
yank into the buffer is the text from the cursor location to the end of
the line; and whether they cause the editor to consider the cursor to
be in a different location from where it really is seems to depend on
the movement in question:  with "ayNb, no, with "ayN|, yes (where N
again stands for a positive integer).  So what I called a snake in the
grass seems to be a can of worms!
     In experimenting with this, incidentally, I've found that, while a
put from a named buffer can be undone with u, if one attempts the
command U, ``undo all changes made since coming onto this line'', only
changes made since the last named-buffer-put are undone.
 
     I mentioned various abbreviations that were hard to unabbreviate,
but could be done with the help of ^V -- but that I had found no way
to undo
	:ab if if\pq
To be precise, I had found that  :una ^Vif,  :una ^V^Vif,  and
:una    ^Vif  where each ^V represents two ^V's typed in, didn't work.
I've finally found something that does:  :una i^Vf.

     I find the diagnostic ``No tail recursion'' strange,
since the occurrence of an abbreviation at the end of the item
abbreviated shouldn't cause a recursive loop; while circumstances that
do cause such a loop, namely the occurrence of the abbreviation within
the item abbreviated, preceded by a space and followed by punctuation,
are not censored, e.g. :ab x ( x ), or with more subtle effect,
:ab x x sup 2.
     It seems that if one has :ab x word,  then the abbreviation works
when x is preceded by a beginning-of-insert, a space, a tab, or a
newline, and followed by most any nonalphabetic character.  For
word-processing use, it would be natural to allow it to also be
preceeded by (, ", `, [, perhaps even a user-specified set of
characters.

     To my list of vi commands which I think should be able to take
counts, add p and P.  I often want to put in a large number of copies of
one or more lines, as ``forms'' in which I will enter various kinds of
additional data, and it would be convenient to be able to do compose
such a line and then duplicate it the desired number of times all at
once.  What I currently do is produce a copy and then go
yypk2yypk4yyp... till I have enough.

     Two more commands I think would be useful:  (1) One which "puts" to
the screen (in the sense of g/pattern/p, i.e. without affecting the
buffer) the contents, or the first lines in cases that are longer than
one line, of all nonempty buffers, named or numbered, with an
indication, of course, of which each was.  (Ideally one would like to
be able to specify some subset of the buffers, whether one wants the
first line, or everything, or some specified number of lines, etc..) 
(2) One which would show the script of the command stored to be used as
``.''.  (And perhaps ditto with the last search pattern.)
     Oh, yes: it would also be nice to have a way to give commands
without having them displace the one specified to be repeated by ``.'',
e.g. if one wants to do a certain change time after time at various
points in the file (using ``n'' and ``.'') but occasionally sees other
changes to be made along the way.  An alternative to the above would be
a way to read the command stored to be used as ``.'' into a named
buffer, so that one can give other commands and then return to
that one.  This would also allow one to reread the text of the command:
useful if it isn't behaving as one meant it to.
     
     You might as well send any future mail to me here as
gbergman@cartan -- I was using brahms while cartan's terminals were
being moved but I'll probably be using cartan more from now on.  But
I'll check mail on both.  (However, I'll be on vacation in New York
State from the 3d to the 16th of August.)
						Best regards,
						George