gbergman@ucbtopaz.CC.Berkeley.ARPA (05/06/84)
Of course I tried out my line-executing macro on test files first!
And it worked, and has served me marvellously for most of a year (so
far), through a lot of varied editing. Others should also test it out
before using it.
Could Chris Torek give us some quantitative estimates on how much
reusing of named buffers, etc. should lead to bugs, and if possible
what kind of bugs to expect? He may not realize that ``a lot of'' use
of this macro really involves a relatively small number of lines being
yanked to buffer ``a'' in an editing session.
Once, when I was doing a lot of work trying to get a large group
of mappings working ``just right'' with this macro, so that I remapped
the same function keys many times, I eventually got a diagnostic saying
that there was no room for more mappings; so I left the editor and came
back in (having the mappings still there in the file to use) and there
was no more trouble.
The one important misbehavior I've noted is what I mentioned in
my message: that the `undo' command occasionally undoes more than the
last command. So, as usual, it is best to write the buffer at key
stages in one's editing. But this is within the range of the editor's
usual occasional flakiness.
There is one kind of use that I occasionally make of this macro
that constitutes an exception to my statement that one only yanks a
relatively small number of lines to buffer ``a'' in an editing
session. This involves ``cleaning up'' troff-eqn files typed by a
secretary, for which purpose I read into the file a file of about 100
lines of editor commands -- pattern searches for common typos (like 0
for close-parenth), substitute commands for reformatting things for
which I eventually wrote troff macros differing from the usages I
explained to the secretary, mappings that make it easy to break an eqn
construct into two, etc.. I go through these, executing them one by
one; and there is one peculiar, though not particularly dangerous
behavior of the editor that I have found suddenly begins happening when
I have been at it for a while: If a pattern search is done in the form
:/pattern^M (instead of the more usual /pattern^M -- unfortunately, my
^O trick, when applied to a line ``/pattern'', gives the effect of the
latter rather than the former, and I don't want to load up my exinit
with special mappings just to make pattern searches more convenient),
then, though the search itself works correctly, if I try to repeat
the search with n, I get a ``?'' instead of a ``/'' at the bottom of
the screen, and the search is executed in reversed sense. Solution:
just use N for n and vice versa. Or leave the editor and come back
in, continuing at the point where you left off.) Is this a
symptom of ``11-squishing''?
Anyway, if you don't like such things happening, stick to
less intensive uses of this trick.
Can anyone explain the term ``11-squishing'' to me, by the way?
George Bergman
(preferred address: ...!ucbvax!ucbcartan!gbergman)chris@umcp-cs.UUCP (05/08/84)
Sorry if I confused people. I made up ``11-squishing'' on the spur
of the moment, and meant the kind of hacks one writes when trying
to squeeze a program written for a Vax onto the PDP-11 downstairs.
There's always a few more bytes you can save, if you reuse this
buffer here, over there, and there too. Vi has a lot of this kind
of buffer reuse, mostly dealing with undo.
I haven't seen any bugs that would blow away an entire file (except
for the occasional segmentation fault), but there seem to be some
which would cause great anguish if one used undo after using a fancy
macro. It's not nice to see all the text you typed in for the last
hour or two jump around, even if it is still all there in some form....
Let's see if I can find some bugs right now.
Aha, here's one. First, a "map":
:map = "ayy1GPu
Now type =; the cursor will jump to the top line and you'll get an
error about puts inside macros. Now type U (capital u), and
something strange happens to the first line. (I got the ``Newsgroups:''
line replaced by the ``Subject:'' line, for some reason.)
Just found another bug: if you use a global command that invokes
a substitute command, and the substitute command happens to make
a line longer than 1023 characters after succeeding on a previous
line, the substitute tries to use undo to fix things, but the global
prevents the use of undo, and the editor buffer is left rather
clobbered. (This was inside a :map'ped key, if you care to
experiment.)
Admittedly these cases are somewhat unlikely, but if you start
experimenting, you should be aware that there *are* bugs.
(For the record, these experiments were done on a 4.1BSD system.
4.2 may have new and improved vi bugs :-).)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland