MAJOR BUG (vi modeline) -- a safe & powerful alternative

[gbergman at ucbtopaz.UUCP]

Subject: "MAJOR BUG" (vi modeline) -- a safe & powerful alternative
Newsgroups: net.unix-wizards,net.bugs

     Convenient though it may be to have a command executed
automatically on entering a file with the editor, it is still
more useful to be able to keep command lines in the
file and execute any of them ad lib.
     Given a line of the file, the way to execute it as a bottom-line
command is to yank it to a named buffer, e.g.
	"ayy
and then give the bottom-line command that executes the contents of
that buffer, in this case
	:@a

     I have an item in my EXINIT that makes the single keystroke
control-O do this for me.  I will give it twice below, once exactly
as it appears in my EXINIT, and once with the two control-characters
shown explicitly as ^+Letter, for those of you seeing this through
``more'' etc.:
		map  "ayy:@a
   explicitly: 	map ^O "ayy:@a^M

     In addition to allowing you to keep commands in files for repeated
use, it makes it possible to carefully edit a command before executing
it, make a modification if the first version did not do what you meant
it to, etc..  It was actually for such editing capability that I set it
up, and the practice of storing commands for reuse developed after.

     The above mapped key can be preceded by a count.  E.g. 3^O will
execute the next three lines as bottom-line commands.

     Let me note a couple of limitations:
     In a bank of commands so executed together, e.g. by 3^O, none
except the last may be a ``global'':
	g/pattern/command
If a global appears in nonfinal position, all commands after it are
ignored.  (This seems to be a general bug of vi; the same thing happens
if one gives on the bottom-line of vi the command
	:source filename
and the file contains a global in nonfinal position.  Only in ex mode
does the command :source behave properly.  Modeline also seems to
be confused by global commands, by the way.)  On the other
hand, I regularly execute banks of many mappings together with no
trouble, as well as things like:
	10,-w !nroff|col|lpr -h
	x
or
	-r !date
	+,$-w !mail NAME
Banks of several substitute commands sometimes give trouble; messages
like ``extra characters after substitute command''.
     Also note that since we are in vi, not ex, the ex commands i, a,
and c cannot be used.  (However, in place of  a  one can use, say
	s/$/^Mline1^Mline2^Metc./
with ^M's entered as ^V-carriage-return, and similar
substitutes for the others, if the resulting command isn't too long.)
     Commands executed in this way (in fact, any commands
given by mappings, @x macros, etc.) cannot execute a ``yank'' (or a
deletion to a named buffer) after any operation that changes the
file.  (According to Mark Horton, there is good reason for this if the
yank is to the ``nameless'' buffer; the fact that it affects yanks to
named buffers as well is a bug.)  This behavior is somewhat capricious:
I have written one command involving such a yank that works OK for no
reason I understand, and another that does something totally
unrelated to what it ought to.
     Sometimes an ``undo'' following a command undoes both it and
some preceding commands!
     To avoid accidentally executing a command with serious consequences
(e.g. mailing a half-written letter, which I once did) one can write in
such commands preceded by the escape character ", e.g.
	"+,$-w !mail NAME
and delete the " only when ready to use.

     Despite its minor drawbacks, this trick has totally transformed
the use of the editor for me!  I would be very interested in other
people's reactions.

     I have some similar tricks for executing file-lines in
ex mode instead of vi mode (mainly developed when I was on a PDP
and didn't have a version 3.7 editor with its @-macro facility).
I occasionally use them when I want to execute something with
successive global commands; I'll give details if anyone is intere   0843
From: n44a!wjh12!genrad!decvax!cca!z
Newsgroups: net.bugs.4bsd
Title: Re: Bug in tset(1) - (nf)
Article-I.D.: cca.388
Posted: Tue May  1 08:59:06 1984
References: <3192 at fortune.UUCP>

Yes, this is a problem.  Aside from the fact that it is only logical
that a tab from the end of a line behave like every other tab (i.e,
advance no more than eight spaces), all terminals that I have seen with
hardwired tab stops do behave this way.  Furthermore, even those
terminals with user settable tab stops have a tab set in the first
column and every eight columns thereafter when they are initialized.
If the tab stops set by tset are different from default tab settings and
those on terminals with hardwired tab stops, then it becomes impossible
for programs to reliably know exactly where a terminal's tab stops are.

	Steve Zimmerman
	decvax!cca!z