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
gbergman@ucbtopaz.UUCP (05/12/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)