Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA
Path: utzoo!watmath!clyde!akgua!mcnc!decvax!ucbvax!ucbtopaz!gbergman
From: gbergman@ucbtopaz.CC.Berkeley.ARPA
Newsgroups: net.unix-wizards,net.bugs
Subject: Chris Torek's warning on 11-squishing
Message-ID: <476@ucbtopaz.CC.Berkeley.ARPA>
Date: Sun, 6-May-84 01:59:01 EDT
Article-I.D.: ucbtopaz.476
Posted: Sun May  6 01:59:01 1984
Date-Received: Mon, 7-May-84 00:41:17 EDT
References: <6859@umcp-cs.UUCP>, <469@ucbtopaz.CC.Berkeley.ARPA>
Organization: Univ. of Calif., Berkeley CA USA
Lines: 48

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)