+From gbergman@UCBBRAHMS Mon Jul 25 16:21:43 1983
+Date: 25 Jul 83 16:16:52 PDT (Mon)
+From: gbergman@UCBBRAHMS (George Mark Bergman)
+Subject: Re: editor bugs etc.
+Message-Id: <8307252316.AA22776@UCBBRAHMS.ARPA>
+Received: by UCBBRAHMS.ARPA (3.342/3.7)
+ id AA22776; 25 Jul 83 16:16:52 PDT (Mon)
+Received: from UCBBRAHMS.ARPA by UCBERNIE.ARPA (3.336/3.7)
+ id AA13678; 25 Jul 83 16:21:17 PDT (Mon)
+To: mckusick@UCBERNIE
+Status: R
+
+The following are (i) a short note from Mark Horton
+in reply to a note of mine saying I'd been keeping notes
+on editor bugs, had heard he had a new version, was
+interested in hearing about it and perhaps sending
+him notes on bugs not mentioned as corrected; (ii)
+a long letter from me in which I do list bugs, features
+I think would be desirable etc., (iii) an addendum I
+sent the next day, (iv) brief jottings not yet sent.
+
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+>From mark@cbosgd.UUCP Thu Jul 21 12:31:55 1983
+
+The new version of vi isn't very different to the user.
+The internals use terminfo instead of termcap, but the
+user interface isn't affected by this (except that it
+starts up faster). The major new features are
+ set showmode
+ will cause an indication on the status line when
+ you are in input mode
+ vedit
+ is a new invocation of vi for novices
+ more function keys now work
+ function keys work in both command and input mode
+Of course, there are a few bug fixes too.
+
+There is a binary in ~mark/bin/vi on ucbarpa. It requires the
+/etc/term heirarchy (there is no file called /etc/terminfo) which
+was on ucbarpa once but might be gone now. If you want to grab
+them from whereever they still exist, please feel free to try them.
+ Mark
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+Sent to Mark Horton 23/7/83, about 11AM
+
+Dear Mark,
+
+ Well, your note didn't say you wanted me to send my comments
+on editor bugs and suggestions, but you didn't say I shouldn't,
+so I decided to do so. I've tried to organize it into some sort
+of sections. I'd be interested to know which of the bugs mentioned
+here you have already found and corrected. (I may soon find out for
+myself; the person in charge of this machine says he'll try to get a
+copy of version 3.9 from UCBARPA if they still have it, and get it
+running for me. If you have any helpful information for him, he
+is robert@brahms, Robert Gross.)
+ Vedit sounds like a great idea.
+ I should mention that throughout this letter, I have
+avoided using actual control-characters, but faked them,
+e.g. used ^ and H to get the appearance of ^H, since files with
+real control-characters can be confusing when looked at in mail,
+more, etc. But this means that if you want to try any commands I
+refer to that use them, you won't be able to yank and source them,
+unless you replace my fakes with real control characters.
+ The version I am using is 3.7.
+
+
+PROBLEMS WITH COUNTS
+
+ Some vi operations that logically ought to be able to take
+counts do not, while others misbehave with counts. In this section,
+``N'' will always denote a positive integer placed as a count before
+a vi operation.
+ The most gross case of misbehavior is that of N^B!
+The effect is to redraw the screen 23N-44 lines further advanced.
+(Probably the numbers depend on the screen-size of the terminal;
+this is on a Z19, using termcap h19u.) When N=1, this does indeed
+move you a screenful backward, but for higher N it moves the window
+forward some amount! Further, whatever controls are supposed to
+monitor whether the command would land one at an acceptable line-
+number seem to have a different idea of what it is doing: If you
+aren't already familiar with these weird effects, try setting the
+cursor near the end of a file that is more than 4 screenfuls long,
+and hitting 3^B. (You might then try an insert at the place you get
+to, and a :f^] .)
+ N/pattern/ would be useful, but is not allowed.
+ ND would be a natural synonym for dN$, by analogy with NC for cN$,
+but it doesn't work that way; it just ignores the N.
+ Finally, if N is precisely the number of lines
+from the current line to the end of the file, N$ will still correctly
+carry one to the last character of the file, but cN$, NC, dN$ and yN$
+refuse to do anything! (NY does work, not being a synonym for yN$.)
+The failure of NC is particularly annoying; often when I am composing
+something, I go back to somewhere in the middle of the next-to-
+last line, say, and want to rewrite the rest of the sentence;
+2cc would kill not only the part I want to rewrite but also the OK
+beginning of the line, and 2C or 2c$ won't work. I realize that I
+could get around this by keeping an empty line at the end of the file,
+but that should not be necessary.
+
+
+PROBLEMS REGARDING SOURCE, MACROS, MAPPINGS
+ These are enormously useful, but seem to have all kinds of hidden
+restrictions.
+
+ The Appendix to the Ex Reference Manual, "List of Changes from
+Version 3.5 to Version 3.6" says ``A bug which prevented the source
+command from working...from visual has been fixed''. It is true that
+one can now use :so from vi, but it still has a bug: When
+the scriptfile invoked contains a global command
+and some other command(s) after it, everything after the first global
+command is ignored. The same appears to be true of scripts in named
+buffers invoked from vi-bottom-line by @x.
+
+ (It is, perhaps, unexpected that one can invoke scripts with
+multiline commands using @x from vi's bottom-line at all, since such
+commands will not work if typed on vi's bottom line directly.
+A script like
+ s/$/a\
+ b
+invoked as @x will indeed work. But strangely, if one tries to
+invoke from the regular mode of vi the script
+ :s/$/a\
+ b
+by putting it in buffer x and doing @x, only the first line
+will take effect.)
+
+ Another serious restriction is that the command ``vi'' appears to
+be ignored in sourced ex-scripts, and though the command Q in macros of
+various flavors in vi (mapped characters, map!ed characters that contain
+``...^V^[...Q...''; @x scripts) does take one into ex, any ex
+commands after it are ignored.
+
+ I assume you are aware of whatever restrictions lead to the
+error-message ``Cannot yank inside global/macro'', since you must
+have written it, though ``inside'' seems to here have the peculiar
+meaning ``after a text-changing operation of the macro.''
+ The error-message ``Can't undo in global commands'' is more
+mysterious, since I get it when I have a global command after
+a text-changing command in an @x script (though not in a sourced file).
+ Anyway, the fewer such restrictions these operations were subject
+to, the more useful they would be!
+
+ Although nested source commands are allowed (and I find them
+useful), they leave the editor in a ``noprompt'' state. This
+can be gotten around by including ``se prompt'' as a line in the
+outermost scriptfile, but I would hope the problem causing it could
+be cured.
+
+ When one tries to ``:unmap!'' a ``:map!'' command whose
+right-hand-side begins with ^H (entered as ^V^H, of course), one
+gets the message ``That macro wasn't mapped''. (One can get around
+this by using :unmap! ^V[character].)
+
+ Certain termcaps apparently produce automatic mappings, which
+unfortunately may interfere with useful vi commands. In particular,
+on a tvi, ^L gets mapped to a movement command, which makes it
+unavailable for redrawing the screen, unless unmapped.
+
+
+PROBLEMS WITH DIAGNOSTICS
+
+"Hit return to continue" -- It took me a long time to realize that
+when I got this diagnostic there was an alternative to hitting
+return. I suggest it be reworded
+ "Hit Return or :"
+However, the behavior of the editor when this diagnostic is given
+seems to be inconsistent. In particular, when the last of a serious
+of commands is
+ :e otherfile
+and I get "Hit return to continue", then hitting : usually
+has no different effect from hitting return (or any other
+key), namely the screen is redrawn; yet I think that sometimes
+in this situation it has brought me directly to the bottom line
+as desired. Very confusing.
+ Would it be possible to have other alternatives than : and return
+available, such as /pattern ? Or, more simply, when one would presently
+be given the diagnostic "Hit return to continue", why not just put the
+editor into the state it would have if one then hit :, since one would
+then still have the option of hitting return and getting into vi
+proper, but it would not require the extra keystroke : to
+begin a bottom-line command, nor would one go through the frequent
+frustrating experience of absentmindedly starting to write a
+bottom-line command, or a pattern-search, and then having to wait
+while the screen was redrawn because one had hit a key other than :.
+
+"Using open mode"
+Again, it took me a long time to learn that when I tried to enter
+vi and got this diagnostic, it meant that the system had somehow
+lost the termcap for the terminal I was on, and that I would have
+to do something to get the correct termcap into the environment.
+Till I realized this, I generally ended up either struggling along
+frustrated in open mode, or logging out and logging back in. I suggest
+that when someone calls for vi and the termcap is not appropriate,
+the editor should not be invoked in any form, but instead, a message
+be given such as:
+ ``Your environment does not show a termcap entry permitting
+the use of the visual editor. If you are working on a terminal not
+supporting vi (in particular, a device with no addressable cursor),
+you may enter one of the other modes of the editor with the command
+"open filename" or "ex filename". If you are working on a terminal
+that should support vi, your environment entries are incorrect and
+should be corrected. They presently show:
+ TERM=....
+ TERMCAP=....
+If you know the correct name or abbreviation for your terminal-
+type, type it at the end of the next line; if not hit return:
+ % setenv TERM ''
+ If the user typed an acceptable terminal-name, the message would
+continue, telling how to get the appropriate termcap. If the user
+instead typed return, the message would ask him or her to type the
+name of the manufacturer shown on the terminal, not
+worrying about upper/lower-case distinctions, and a list of possible
+terminal names and abbreviations would be given... . This whole
+program would not be part of the editor, so there would
+be no problem of space within the existing crowded confines of
+the editor code.
+
+"No such file or directory" -- I think there should be a distinction
+between these two cases, because of the important distinction in the
+consequences when the user tries to quit the editor:
+If the directory exists, the file is created, but
+if not, the results are more complicated -- I seem to recall on one
+occasion simply losing what I had written on my second try
+at quitting; though I just now did an experiment and this time
+repeated ZZ's and :x's simply gave repeated error messages.
+
+"File already exists..." -- The ``List of changes from 3.5 to 3.6'' says
+``If you get I/O errors, the file is considered "not edited"... .''
+I presume that this correction is somehow the cause of the fact that
+I frequently get the above message when trying to leave the editor
+on a machine with version 3.7, and have to use
+ :w! %|q
+to exit. But I've never seen any evidence that there were I/O errors;
+it mainly seems to happen when I've written some lines to another
+file in the process of editing. So the criteria the editor is using
+to decide when there have been ``I/O errors'' should be rechecked.
+
+"no such command from open/visual" -- This confused me in my first
+few days of using the editor, when I didn't understand that one
+couldn't use i and a (in either their vi or ex senses) from the bottom
+line of vi. A message "i -- no such command from open/visual"
+was perplexing because I knew that "i" was indeed a vi command.
+Perhaps it should say "no such command from open/visual bottom line".
+
+MISCELLANEOUS PROBLEMS
+
+ In ex search and replacement patterns, \\ is supposed to represent
+a real \-character, but something goes wrong when this occurs
+at the end of a global command. E.g., though
+ :s/^/\\
+works OK (in vi or ex), the variant
+ :.g/^/s//\\
+definitely does not. In vi it turns everything off, in ex it seems to
+behave as though there were just a single \, and in a scriptfile,
+it -- does something still different, which you can discover if you
+don't know!
+
+The Ex Reference Manual says, ``For sanity with use from within
+visual mode, ex ignores a ":" preceding any command.'' But it
+ignores it in the wrong place! -- not at the beginning of the
+command line, but just before the command letter itself. I.e.,
+it accepts 1,3:s/^/ /, but not :1,3s/^/ /.
+
+SUGGESTIONS FOR MINOR ADDED CAPABILITIES
+
+ In a multiline substitute command with the "c" option, when
+each line is displayed one has three choices: y, n or break. There
+are some further options that would be useful. One would be "p" --
+at present, "p" can only be included on the command line, which
+means that one has a choice between seeing the result of every
+substitution or none. In practice, one would generally like to see
+the results of the first few cases to make sure that the command one has
+written does what one meant it to, and maybe a few tricky cases that
+come up; but not every case! Another might be "u" -- to undo the last
+case for which one gave a "y". Still another might be an option that
+would mean ``undo the "c" option -- I see that the substitute command
+is doing what I wanted, go ahead and finish it without me.''
+ In a command g/pattern/p, the pattern in question is occasionally
+such that it takes a while to figure out where on the line it occurs.
+For this purpose, an option that ``pointed out'' the instance of the
+pattern, in the same manner that the pattern to be replaced is pointed
+out in substitute command with option c, would be desirable.
+ When g/pattern/p gives more than a screenful of lines, it would
+be nice to have it piped through the equivalent of ``more''.
+
+ ex has the command line option "-", which ``is useful in processing
+editor scripts''. But if one wants to use a script in the course of
+an otherwise interactive editing session, it would be desirable to have
+a corresponding resettable option ``:se -'' (or ``:se nofb'').
+
+ In strings in pattern-searches, it would be useful to have
+^ and $ retain their ``magic'', so that /x[a$]/ could
+search for all occurrences of x before an a or a newline.
+(Of course, one would then have to decide whether /x[^y]/ should
+include the case of x followed by a newline or not.)
+
+ Just as ex allows the command :vi, so I think that vi should
+have some bottom-line command equivalent to the regular-mode
+command Q. When one has done some text-changing bottom-line
+commands, and realizes one wants to go into ex, it can be time-
+consuming to hit return and then Q, and wait for the screen to be
+redrawn for vi before one gets the ex prompt.
+
+ The option of putting several commands on one line, separated
+by, "|" is particularly useful in the vi bottom-line mode, because
+it avoids having the screen redrawn several times. It would be
+useful to be able sometimes do the same thing with non-bottom-line
+commands, e.g. in editing a troff file at a low baud rate on a dumb
+terminal one might like to be able to do i\fI^]3Ea\fR^] without
+watching the line get redrawn twice. Perhaps some key that would
+cause any sequence of commands to be ``held'' until some complementary
+key was hit would be useful.
+ It would also be desirable to have a sequence of commands that had
+been given in this way available as one unit to be repeated by ``.'',
+if desired.
+
+ The parenthesis-matching facility with % might be extended
+to match ` with ' and < with >.
+
+ I will mention one facility that I discovered by surprize is
+possessed by ed but not ex -- sequences such as \1 can be used
+within ed search-patterns. E.g. (for the most trivial case)
+ /\(.\)\1/
+will search for doubled letters.
+
+
+DEBATABLE SUGGESTIONS
+ I will mention here some possible changes which have the
+difficulty that they would change the meaning of existing commands,
+so that it could be argued that the disadvantage of users having
+to change their habits might outweigh the advantages.
+
+ First, one might try to resolve, one way or another, the
+contradiction between the count arguments taken by the join commands
+in vi and ex: In ex, jN joins N+1 lines; in vi, NJ joins N lines
+(except if N=1).
+
+ Second, the movement commands tx and Tx of vi (x any character)
+seem poorly defined. Just as fx will ignore the character on which
+the cursor is presently sitting, even if it is an x, and move to the
+next occurrence, so I would think that tx should ignore the character
+immediately after the cursor, and Tx the character immediately before
+the cursor. The point is that when one does Nfx, and finds that one
+had failed to count one occurrence of x and fallen short of where one
+wanted to go, one can hit ; and get there. Likewise, on doing Ntx
+and finding one has fallen short, one should be able to hit ; and get
+to the the next occurrence; but at present, hitting ; leaves
+the cursor in the same position; one must hit ``2;'' to get any
+further. In effect, Ntx is presently defined as Nfxh; I am
+suggesting that it be defined as lNfxh.
+
+ The sequences cw, dw and yw are presently violations of the
+principle that c[movement], d[movement] and y[movement] change,
+delete, or yank everything from the current cursor position through
+the endpoint of the movement command. cw does what one would expect of
+ce (in fact, they seem to be synonyms), while there is no way to get
+the effect which cw would have if it were treated ``consistently''.
+(E.g., if I have a line beginning ``And if'', and I want to change it
+to ``If'', I cannot just put the cursor on the A and hit cwI^].) dw
+and yw delete up to the character immediately before the point to
+which ``w'' would take the cursor. I would have to agree that this
+behavior of dw and yw is more useful than that which a literal
+interpretation of the movement rule would lead to; but perhaps it
+would become still more useful if when applied to the last word on
+a line, it deleted or yanked the space immediately before the word
+along with the word... . On the other hand, one could argue for
+making a distinction between cw and ce.
+
+ Though I see the motivation for the above definitions,
+I see no sensible reason why Y should be equivalent to yy, when
+C and D are equivalent to c$ and d$. I would vote for changing
+Y to mean y$.
+
+RADICAL SUGGESTIONS
+
+ Is there any reason for maintaining the distinction between
+the ``:'' state of vi, and ex itself? At present, there are
+relative advantages that lead one to choose to go into one or the
+other for a given operation: From the vi-: state, it is easier
+to return to the regular vi state; from ex, one has a more powerful
+range of commands; and it is easier to give a series of commands
+because each carriage-return gives one a new prompt. My suggestion
+is that from vi, ``:'' should carry you directly to ex, and when you
+are in ex, carriage-return (^M) after a command should give you a new
+prompt, while ^] should put you into vi. Conceivably, things might be
+simplified even further, and carriage return rather than : could
+be the key that would carry one from the regular mode of vi into ex:
+
+ .-------. .-------.
+ .-------. a,i... | basic | ^M | |
+ | vi |<------ | |----->| ex |<---.
+ | insert| | vi | | | |^M
+ | mode | ------>| |<-----| mode | ---'
+ `-------' ^] | mode | ^] | |
+ `-------' `-------'
+
+(Of course, ^M presently has a meaning in vi, but
+it has a synonym +.) Clearly, there would also be no need for a
+special "Hit return to continue" state.
+ I have not distinguished vi and open in the above diagram.
+My idea here is that ^] would actually return you to either vi
+or open, whichever you had last been in, and that to switch
+to the other, you could enter ex and type vi^] or o^] respectively.
+(Or you could type vi^M, respectively o^M, and further ex commands,
+and the mode would be saved for the next time you hit a ^].) Or
+alternatively, these could be made settable options: se visual
+respectively se novisual.
+ Having gotten used to the editor as it now exists, I admit that
+I feel uneasy about the above idea -- the sense of knowing that
+I am ``still in vi'' when I hit :, and not that ``other land'' of ex,
+represents a kind of of orientation that it is disconcerting
+to abandon. But I can't see any logical disadvantage in making
+such a change. Can you? Certainly, there would be things that
+would have to be thought out, such as what happens to bottom-line
+vi pattern-searches. My thought would be that ``/'' from vi should
+give :/ (i.e., put one in ex at the start of a pattern-search),
+and ^] after a pattern-search should put one into vi at the appropriate
+character on the line, in contrast to ^M after a pattern search,
+which would leave one in ex at the appropriate line. In general,
+I think such changes would lead to greater simplicity and learnability
+of the editor.
+ I would also hope that excursions between vi and ex and back
+could be allowed in scriptfiles. It might also be desirable for
+ex to have, in addition to a concept of ``current line'', one of
+``current cursor position''... .
+
+ Well, on to another subject. One of the inconveniences I
+found very vexing when first learning to use the editor was that
+when in either vi insert mode, or ex/vi-bottom-line, it was very hard
+to edit what I was doing. Within insert mode the only ``editing''
+I could do, without escaping, was with the three operations ^H,
+^W and the kill character. And on a slow line with a dumb terminal,
+escaping to make changes could be very time-consuming because large
+parts of the screen would insist on being redrawn. Perhaps some
+other control-character could serve as
+a modified escape, that allowed one to edit what one had entered
+in the current insertion without having everything below it redrawn,
+and then return to it. Obviously, if carried to its logical
+limit this idea could lead to ridiculous nests of
+editing operations; but there would be no need to carry it to its
+logical limit.
+ Anyway, the problem of editing ex-style commands
+was even worse, because there was no way to ``escape and
+revise''. I eventually learned enough to realize that the solution
+was to edit complicated commands in another file and source it.
+But it is sometimes very useful to have the text on which the
+commands are to act in front of you when composing them (e.g., you can
+yank and modify various pieces), which led to the variant of writing
+command lines within the file I was editing, and then writing
+those lines into another file and sourcing that, without ever leaving
+the current file. But this is distracting to deal with
+when concentrating on the editing task itself, which led me
+to divise a scriptfile which would handle the writing-to-another-file-
+and-sourcing for me. Or actually, several such files: One for
+single-line commands to be used essentially once; one for single-line
+commands that I would want to use on the same file during various
+editing sessions, and so would want to keep available in that
+file, and one for multi-line commands (to be used once). When
+I first got the idea, I thought one scriptfile would be enough, and
+I would call it ``do'', so that the command to execute a script I
+had written in a file I was editing would be ``:so do''. The
+file it would write to and source would be ``do.again'', so that
+if I wanted to reuse it, I could ``:so do.again''. When I realized
+the need for several versions, ``do'' became a directory. Here,
+for your amusement, are the three files. (Re the lines ``se prompt'',
+cf. my comment on that under PROBLEMS WITH SOURCE etc.):
+
+ do/1 (for 1-time use of 1-line commands)
+ .w! ~/do/again
+ d
+ so #
+ se prompt
+
+ do/1+ (like above, without deleting the command)
+ .w! ~/do/again
+ so #
+ se prompt
+
+ do/: (to use this, write a multi-line command script, put : at
+ the beginning of the first line, put the cursor on the last
+ line of the script, and then source the following:)
+ ?^:?s/:/
+ ,''w! ~/do/again
+ ,''d
+ so #
+ se prompt
+
+(I also created another version to use in case the script had
+to have an internal line beginning with ``:'', so that this couldn't
+unambiguously mark the beginning of the script. This used
+a line which explicitly specified the address-range of the script.
+But I have never had a need for it, so I will not bother you with it.)
+ Finally, having gotten an account on a machine with a version 3
+editor recently, I have divised still another way of doing this. I
+have put in my EXINIT the command
+
+ 'map ^A "ayy:@a^M'
+
+and now, gratifyingly, the single stroke ^A has essentially the effect
+of ``:so do/1+'' -- except for the restrictions to which vi ``map''
+commands are subject. But I've only been using this for a
+couple of weeks; so I have yet to learn how chafing those restrictions
+will or won't be.
+ Anyway, it might be worth thinking about whether some of these
+things that I've done with macros should be incorporated in some form
+into the editor itself; or else whether these macros might be written
+up in the documentation (or some tutorials) on the editor.
+
+ Next subject: Complicated pattern-searches in long files
+can be time-consuming. I have seen the point mentioned
+that if a pattern-description can be begun with "^",
+this can speed up the search -- since the pattern-comparisons need
+only be begun at beginnings of lines. In some cases, this might
+not be possible, but the user might be aware of some other
+character or character-sequence in the search-pattern
+that will occur relatively rarely in the file. In such cases it would
+be desirable if the user could specify one spot from which the pattern
+search should start, working forward and backward from there, to
+minimize false starts. E.g., if for some reason one wants to
+delete every word containing the letter m, the script
+ %s/[^ ]*m[^ ]*//
+would become much less time-consuming if one could mark the point
+at which to begin, say writing
+ %s/[^ ]*\!m[^ ]*//
+so as to instruct the editor to search for m's, and each time
+one was found, to find the longest possible strings of non-space
+characters before and after it, and delete these. (This is a silly
+example, but I think the idea is clear.)
+
+ Something that I've seriously felt the need for is the
+capability of searching for lines that satisfy more than one
+condition. If one just wants to locate such lines, one can
+of course leave the editor and do a pipeline of two or
+more greps; but it would be nice to be able to perform global
+commands on such lines.
+
+ Finally, any possibility of introducing the capability of searching
+for patterns including embedded newlines, a la sed? Multiple windows,
+a la emacs?
+
+ADDENDA
+ I logged in this morning on an adm3a at 300 baud to go over this
+letter once more before sending it, and ran into another bug! I had
+done 15^D to get a large scroll despite the low speed, and at one point
+I saw a line with a typo scrolling up. So I noted its line-number, 402
+and without waiting for the screen to stop moving typed something like
+402Gfsrd. What happened was that the change was made on line 407 rather
+than 402 -- presumably the cursor was sent to where 402 had been when
+the command was received... .
+ Editing this letter this morning reminded me of another feature I
+have thought would be desirable for editing on dumb terminals at low
+speeds: An option that would cause lines read from a file or typed
+in at the bottom of the screen to appear double spaced, with @ signs
+@
+between them, such as one gets when one deletes a line on such a
+@
+terminal. (I have faked this effect here, though the fake will not be
+@
+very successful if you have se nu or se list on.) The point is that
+@
+editing operations that presently cause painfully slow screen-redrawings
+would simply put material in in place of these fillers -- as happens
+now when one is lucky enough to be adding material just above a place
+where material was previously deleted.
+
+ - * - * - * - * - * -
+
+ I hope you've found some things of interest in this hodgepodge.
+
+ Yours,
+ George (gbergman@brahms)
+
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+23/7/83, about 8PM
+
+ Maybe thinking about the editor while writing my previous
+``note'' to you has made me more conscious of these things,
+but for some reason, I've discovered several more peculiarities of
+the the Version 3.7 editor today!
+
+ First, the abbreviation feature has a strange bug (feature?)
+involving the backslash: If some string X is the abbreviation
+for a string Y, and if X is typed (following a space etc)
+immediately followed by a \ and another character c, the
+result is not Y\c by cY\. The case where I discovered this
+was a doubly complicated one: I had an abbreviation of
+the form
+ :ab x x\yZ
+where x and y were characters and Z was a string of characters.
+So when I typed x, it presumably first expanded it as x\yZ,
+then performed the transformation I just described on the x\y
+turning it into yx\yZ\, and thus giving the result yx\yZ\Z.
+This turns out to be one of the cases that can't be unmapped
+without doing :una ^Vx. Further, I just tried a similar case
+with x replaced by a string of more than one character
+(namely, :ab if if\pq) and I find I can't unmap that at all.
+ I also find that an abbreviated string containing | (which
+must be inserted using ^V|, of course) is difficult to unmap.
+
+ Second, some peculiarities about where the cursor ends
+up after a yank. If the yank involved a forward movement,
+the cursor stays where it is, which is the beginning
+of the yanked segment. If the yank involves a backwards
+movement, the place where the cursor originally was is not
+the same as the beginning of the yanked segment, and there
+seems to be some confusion as to which principle is followed:
+y- or yk moves the cursor up, while yb leaves it fixed.
+Unfortunately, there is a snake in the grass with yb: If
+you hit p after it, the yanked word will not appear after
+the position where the cursor has remained, but
+after the position to which it would have gone if it had moved
+to the beginning of the yanked segment! Likewise if you
+you hit an x... .
+ (You have no idea how much trouble I'm
+having with those "if"'s. Of course, I could quit the editor
+and come back in, and I would lose that crazy abbreviation
+that way.)
+
+ I also notice that if the cursor is at the end of a word
+or between words, 2e behaves the same as e!
+
+ Finally, I note that d^, when the cursor is before the first
+nonwhite character, is another exception to the principle that
+d[motion] deletes everything through the endpoint of [motion].
+Similarly with c^ and y^.
+
+- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *
+discovered next day (not yet sent):
+
+error with yb does not just concern p and x: any command is
+executed as though cursor is at destination of backward in-line
+yank.
+
+N^B does not work consistently? (Not on a medium-length file in Kim)
+
+Can get endless-loop mapping if abbreviation forms word within
+abbreviated. E.g. :ab x ( x )
+``word'' must be delimited on left by space, tab,
+newline, start-of-insert; on right by any punctuation. Why
+special ``no tail recursion'' rule?
+ Things like that ``if'' abbreviation can be undone using
+:una i^Vf!
+
+Mention desirability of Np
+
+copies sent to ralph@ucbarpa, lindahl@topaz 25/7/83
+
+From gbergman@UCBCARTAN Mon Aug 1 14:19:27 1983
+Date: 1 Aug 83 14:14:06 PDT (Mon)
+From: gbergman@UCBCARTAN (George Mark Bergman)
+Subject: Re: editor
+Message-Id: <8308012114.AA00627@UCBCARTAN.ARPA>
+Received: by UCBCARTAN.ARPA (3.342/3.7)
+ id AA00627; 1 Aug 83 14:14:06 PDT (Mon)
+Received: from UCBCARTAN.ARPA by UCBERNIE.ARPA (3.336/3.7)
+ id AA19324; 1 Aug 83 14:19:12 PDT (Mon)
+To: mckusick@UCBERNIE
+Status: R
+
+Here's Mark Horton's reply to my letter on bugs
+
+>From mark@cbosgd.UUCP Thu Jul 28 14:38:55 1983
+
+Sorry this has taken so long, but your note was too long to digest
+in the cracks between the other stuff I do. Anyway, you've clearly
+put a great deal of thought into this, and I appreciate your input.
+I'll reply individually to your thoughts, and keep them on file
+for use (someday) when vi gets rewritten. Some of them are just
+plain bugs that ought to be fixed soon anyway.
+
+ PROBLEMS WITH COUNTS
+
+ The most gross case of misbehavior is that of N^B!
+ The effect is to redraw the screen 23N-44 lines further advanced.
+ (Probably the numbers depend on the screen-size of the terminal;
+ this is on a Z19, using termcap h19u.) When N=1, this does indeed
+ move you a screenful backward, but for higher N it moves the window
+ forward some amount! Further, whatever controls are supposed to
+ monitor whether the command would land one at an acceptable line-
+ number seem to have a different idea of what it is doing: If you
+ aren't already familiar with these weird effects, try setting the
+ cursor near the end of a file that is more than 4 screenfuls long,
+ and hitting 3^B. (You might then try an insert at the place you get
+ to, and a :f^] .)
+This is a known bug, and was fixed in 3.8. The count is supposed to subtract
+(LINES-1)*N from the line number, but there's + that should be a -, so it
+goes forward instead. The check is correct, so it's possible to go off
+the end of the buffer.
+ N/pattern/ would be useful, but is not allowed.
+N/pattern/ resets the window size (silly but true) to N.
+ ND would be a natural synonym for dN$, by analogy with NC for cN$,
+ but it doesn't work that way; it just ignores the N.
+ Finally, if N is precisely the number of lines
+ from the current line to the end of the file, N$ will still correctly
+ carry one to the last character of the file, but cN$, NC, dN$ and yN$
+ refuse to do anything! (NY does work, not being a synonym for yN$.)
+ The failure of NC is particularly annoying; often when I am composing
+ something, I go back to somewhere in the middle of the next-to-
+ last line, say, and want to rewrite the rest of the sentence;
+ 2cc would kill not only the part I want to rewrite but also the OK
+ beginning of the line, and 2C or 2c$ won't work. I realize that I
+ could get around this by keeping an empty line at the end of the file,
+ but that should not be necessary.
+While you're making valid observations here, are you aware that you can delete
+the current sentence with d} ? I think that's what you really want.
+
+
+ PROBLEMS REGARDING SOURCE, MACROS, MAPPINGS
+ These are enormously useful, but seem to have all kinds of hidden
+ restrictions.
+
+ The Appendix to the Ex Reference Manual, "List of Changes from
+ Version 3.5 to Version 3.6" says ``A bug which prevented the source
+ command from working...from visual has been fixed''. It is true that
+ one can now use :so from vi, but it still has a bug: When
+ the scriptfile invoked contains a global command
+ and some other command(s) after it, everything after the first global
+ command is ignored. The same appears to be true of scripts in named
+ buffers invoked from vi-bottom-line by @x.
+Sounds like a bug.
+
+ (It is, perhaps, unexpected that one can invoke scripts with
+ multiline commands using @x from vi's bottom-line at all, since such
+ commands will not work if typed on vi's bottom line directly.
+ A script like
+ s/$/a\
+ b
+ invoked as @x will indeed work. But strangely, if one tries to
+ invoke from the regular mode of vi the script
+ :s/$/a\
+ b
+ by putting it in buffer x and doing @x, only the first line
+ will take effect.)
+In 3.7 (or 3.8, I'm not sure), you can say
+ :s/$/a^V^Mb
+to get a newline on the RHS. Of course, this doesn't mean there isn't
+a bug in scripts.
+
+ Another serious restriction is that the command ``vi'' appears to
+ be ignored in sourced ex-scripts, and though the command Q in macros of
+ various flavors in vi (mapped characters, map!ed characters that contain
+ ``...^V^[...Q...''; @x scripts) does take one into ex, any ex
+ commands after it are ignored.
+The internals of getting a character from the tty are completely different
+in ex and vi. Pushing input for one doesn't affect the other. So there
+isn't much hope of changing this situation.
+
+ I assume you are aware of whatever restrictions lead to the
+ error-message ``Cannot yank inside global/macro'', since you must
+ have written it, though ``inside'' seems to here have the peculiar
+ meaning ``after a text-changing operation of the macro.''
+ The error-message ``Can't undo in global commands'' is more
+ mysterious, since I get it when I have a global command after
+ a text-changing command in an @x script (though not in a sourced file).
+ Anyway, the fewer such restrictions these operations were subject
+ to, the more useful they would be!
+It's the way undo is done - the text for undo is saved in the "last deleted"
+buffer, and yank puts text there too. Couple this with the fact that globals
+and macros can be undone as a unit (they save their state before the first change)
+and you'll see that the two notions can't coexist. Of course, you can always
+yank into a named buffer, even inside a macro.
+
+ Although nested source commands are allowed (and I find them
+ useful), they leave the editor in a ``noprompt'' state. This
+ can be gotten around by including ``se prompt'' as a line in the
+ outermost scriptfile, but I would hope the problem causing it could
+ be cured.
+Bug, I guess.
+
+ When one tries to ``:unmap!'' a ``:map!'' command whose
+ right-hand-side begins with ^H (entered as ^V^H, of course), one
+ gets the message ``That macro wasn't mapped''. (One can get around
+ this by using :unmap! ^V[character].)
+Bug, I guess.
+
+ Certain termcaps apparently produce automatic mappings, which
+ unfortunately may interfere with useful vi commands. In particular,
+ on a tvi, ^L gets mapped to a movement command, which makes it
+ unavailable for redrawing the screen, unless unmapped.
+Well, there's no way for vi to tell the difference between ^L that the
+user typed as ^L and ^L that the user typed as right arrow. However, there
+are a number of terminals that are upward compatible with the adm3a and use
+^L for right arrow. Vi has a special case for these built in - if the
+terminal has insert/delete line, and ^L is right arrow, then ^R will redraw
+the screen.
+
+
+ PROBLEMS WITH DIAGNOSTICS
+
+ "Hit return to continue" -- It took me a long time to realize that
+ when I got this diagnostic there was an alternative to hitting
+ return. I suggest it be reworded
+ "Hit Return or :"
+ However, the behavior of the editor when this diagnostic is given
+ seems to be inconsistent. In particular, when the last of a serious
+ of commands is
+ :e otherfile
+ and I get "Hit return to continue", then hitting : usually
+ has no different effect from hitting return (or any other
+ key), namely the screen is redrawn; yet I think that sometimes
+ in this situation it has brought me directly to the bottom line
+ as desired. Very confusing.
+ Would it be possible to have other alternatives than : and return
+ available, such as /pattern ? Or, more simply, when one would presently
+ be given the diagnostic "Hit return to continue", why not just put the
+ editor into the state it would have if one then hit :, since one would
+ then still have the option of hitting return and getting into vi
+ proper, but it would not require the extra keystroke : to
+ begin a bottom-line command, nor would one go through the frequent
+ frustrating experience of absentmindedly starting to write a
+ bottom-line command, or a pattern-search, and then having to wait
+ while the screen was redrawn because one had hit a key other than :.
+There is an internal difference between "ex mode" (where it doesn't keep a
+screen image) and "vi mode" (where it does). Any : command that outputs more
+than 1 line puts you into "ex mode", requiring "hit return to continue"
+before clearing the screen and redrawing it with known stuff. There is no
+hope of this changing - the code is too spaghetti-ized already. In the worst
+case, the ! command scribbles on the screen and there's nothing vi can do
+to know what the command did.
+
+What you really want is for vi to check for typeahead and avert the refresh
+when it's going to have to redo it anyway. My curses does this, but I simply
+don't have time to rewrite vi to use it. This would also solve the other
+problem you mention where macros ought to redraw the screen only once.
+If you saw the insides of the code, you'd see it needs a rewrite to do this.
+Each command knows the screen things to do to fix the screen.
+
+What most of us do is hit DEL when the screen is being drawn with something
+we don't want to see. This aborts the update and leaves junk on the screen.
+Then you move the cursor where you want it, and if the screen is still
+garbaged, hit ^L. Ugly but effective.
+
+ "Using open mode"
+ Again, it took me a long time to learn that when I tried to enter
+ vi and got this diagnostic, it meant that the system had somehow
+ lost the termcap for the terminal I was on, and that I would have
+ to do something to get the correct termcap into the environment.
+ Till I realized this, I generally ended up either struggling along
+ frustrated in open mode, or logging out and logging back in. I suggest
+ that when someone calls for vi and the termcap is not appropriate,
+ the editor should not be invoked in any form, but instead, a message
+ be given such as:
+ ``Your environment does not show a termcap entry permitting
+ the use of the visual editor. If you are working on a terminal not
+ supporting vi (in particular, a device with no addressable cursor),
+ you may enter one of the other modes of the editor with the command
+ "open filename" or "ex filename". If you are working on a terminal
+ that should support vi, your environment entries are incorrect and
+ should be corrected. They presently show:
+ TERM=....
+ TERMCAP=....
+ If you know the correct name or abbreviation for your terminal-
+ type, type it at the end of the next line; if not hit return:
+ % setenv TERM ''
+ If the user typed an acceptable terminal-name, the message would
+ continue, telling how to get the appropriate termcap. If the user
+ instead typed return, the message would ask him or her to type the
+ name of the manufacturer shown on the terminal, not
+ worrying about upper/lower-case distinctions, and a list of possible
+ terminal names and abbreviations would be given... . This whole
+ program would not be part of the editor, so there would
+ be no problem of space within the existing crowded confines of
+ the editor code.
+This, of course, doesn't belong in vi, but in login or tset. In fact,
+tset is much friendlier these days. Vi will print a better diagnostic
+if it knows you're on a "generic" terminal type such as "dialup" - in
+terminfo there's a capability to indicate this, so it can print
+ I don't know what kind of terminal you have - all I have is "patchboard"
+3.7 can't do this because it can't tell the difference between a generic
+terminal and a hardcopy terminal.
+
+ "No such file or directory" -- I think there should be a distinction
+ between these two cases, because of the important distinction in the
+ consequences when the user tries to quit the editor:
+The kernel doesn't distinguish, so it's hard for vi to. This is just a perror
+string.
+ If the directory exists, the file is created, but
+ if not, the results are more complicated -- I seem to recall on one
+ occasion simply losing what I had written on my second try
+ at quitting; though I just now did an experiment and this time
+ repeated ZZ's and :x's simply gave repeated error messages.
+Well, if it can't be reproduced, it doesn't stand much chance of getting fixed.
+(Not that it would if you could reproduce it, of course.)
+
+ "File already exists..." -- The ``List of changes from 3.5 to 3.6'' says
+ ``If you get I/O errors, the file is considered "not edited"... .''
+ I presume that this correction is somehow the cause of the fact that
+ I frequently get the above message when trying to leave the editor
+ on a machine with version 3.7, and have to use
+ :w! %|q
+Ick! Most of us just type
+ :wq!
+which is equivalent and much shorter.
+ to exit. But I've never seen any evidence that there were I/O errors;
+ it mainly seems to happen when I've written some lines to another
+ file in the process of editing. So the criteria the editor is using
+ to decide when there have been ``I/O errors'' should be rechecked.
+Actually, if you get ANY error (e.g. :foo<cr>) it resets the "buffer modified"
+condition. I have finally been convinced this is not right. For a while, I
+considered it a necessary evil in case your /tmp/Ex* file got an I/O error.
+
+ "no such command from open/visual" -- This confused me in my first
+ few days of using the editor, when I didn't understand that one
+ couldn't use i and a (in either their vi or ex senses) from the bottom
+ line of vi. A message "i -- no such command from open/visual"
+ was perplexing because I knew that "i" was indeed a vi command.
+ Perhaps it should say "no such command from open/visual bottom line".
+OK.
+
+ MISCELLANEOUS PROBLEMS
+
+ In ex search and replacement patterns, \\ is supposed to represent
+ a real \-character, but something goes wrong when this occurs
+ at the end of a global command. E.g., though
+ :s/^/\\
+ works OK (in vi or ex), the variant
+ :.g/^/s//\\
+ definitely does not. In vi it turns everything off, in ex it seems to
+ behave as though there were just a single \, and in a scriptfile,
+ it -- does something still different, which you can discover if you
+ don't know!
+Backslash is special at the end of a line in global. You need more \\'s.
+
+ The Ex Reference Manual says, ``For sanity with use from within
+ visual mode, ex ignores a ":" preceding any command.'' But it
+ ignores it in the wrong place! -- not at the beginning of the
+ command line, but just before the command letter itself. I.e.,
+ it accepts 1,3:s/^/ /, but not :1,3s/^/ /.
+Hmm.
+
+ SUGGESTIONS FOR MINOR ADDED CAPABILITIES
+
+ In a multiline substitute command with the "c" option, when
+ each line is displayed one has three choices: y, n or break. There
+ are some further options that would be useful. One would be "p" --
+ at present, "p" can only be included on the command line, which
+ means that one has a choice between seeing the result of every
+ substitution or none. In practice, one would generally like to see
+ the results of the first few cases to make sure that the command one has
+ written does what one meant it to, and maybe a few tricky cases that
+ come up; but not every case! Another might be "u" -- to undo the last
+ case for which one gave a "y". Still another might be an option that
+ would mean ``undo the "c" option -- I see that the substitute command
+ is doing what I wanted, go ahead and finish it without me.''
+If I were going to do something this involved (I didn't know anybody used the
+c option anymore - most people use "n" and "." in vi) I would do query-replace
+ala EMACS right.
+ In a command g/pattern/p, the pattern in question is occasionally
+ such that it takes a while to figure out where on the line it occurs.
+ For this purpose, an option that ``pointed out'' the instance of the
+ pattern, in the same manner that the pattern to be replaced is pointed
+ out in substitute command with option c, would be desirable.
+ When g/pattern/p gives more than a screenful of lines, it would
+ be nice to have it piped through the equivalent of ``more''.
+Nice but unlikely. Unless, of course, you have page mode in your tty driver,
+like we do, in which case you get it for free.
+
+ ex has the command line option "-", which ``is useful in processing
+ editor scripts''. But if one wants to use a script in the course of
+ an otherwise interactive editing session, it would be desirable to have
+ a corresponding resettable option ``:se -'' (or ``:se nofb'').
+Seems like a good idea.
+
+ In strings in pattern-searches, it would be useful to have
+ ^ and $ retain their ``magic'', so that /x[a$]/ could
+ search for all occurrences of x before an a or a newline.
+ (Of course, one would then have to decide whether /x[^y]/ should
+ include the case of x followed by a newline or not.)
+This sounds pretty hard to do.
+
+ Just as ex allows the command :vi, so I think that vi should
+ have some bottom-line command equivalent to the regular-mode
+ command Q. When one has done some text-changing bottom-line
+ commands, and realizes one wants to go into ex, it can be time-
+ consuming to hit return and then Q, and wait for the screen to be
+ redrawn for vi before one gets the ex prompt.
+This would be ugly, since the ex command routine would have to return an
+indication to the vi routine to exit back to the top level ex command.
+But I suppose it could be done.
+
+ The option of putting several commands on one line, separated
+ by, "|" is particularly useful in the vi bottom-line mode, because
+ it avoids having the screen redrawn several times. It would be
+ useful to be able sometimes do the same thing with non-bottom-line
+ commands, e.g. in editing a troff file at a low baud rate on a dumb
+ terminal one might like to be able to do i\fI^]3Ea\fR^] without
+ watching the line get redrawn twice. Perhaps some key that would
+ cause any sequence of commands to be ``held'' until some complementary
+ key was hit would be useful.
+ It would also be desirable to have a sequence of commands that had
+ been given in this way available as one unit to be repeated by ``.'',
+ if desired.
+See above. And get yourself a terminal with insert/delete char!
+
+ The parenthesis-matching facility with % might be extended
+ to match ` with ' and < with >.
+OK.
+
+ I will mention one facility that I discovered by surprize is
+ possessed by ed but not ex -- sequences such as \1 can be used
+ within ed search-patterns. E.g. (for the most trivial case)
+ /\(.\)\1/
+ will search for doubled letters.
+This surprises me.
+
+
+ DEBATABLE SUGGESTIONS
+ I will mention here some possible changes which have the
+ difficulty that they would change the meaning of existing commands,
+ so that it could be argued that the disadvantage of users having
+ to change their habits might outweigh the advantages.
+
+ First, one might try to resolve, one way or another, the
+ contradiction between the count arguments taken by the join commands
+ in vi and ex: In ex, jN joins N+1 lines; in vi, NJ joins N lines
+ (except if N=1).
+Yeah, ex should be N, not N+1.
+
+ Second, the movement commands tx and Tx of vi (x any character)
+ seem poorly defined. Just as fx will ignore the character on which
+ the cursor is presently sitting, even if it is an x, and move to the
+ next occurrence, so I would think that tx should ignore the character
+ immediately after the cursor, and Tx the character immediately before
+ the cursor. The point is that when one does Nfx, and finds that one
+ had failed to count one occurrence of x and fallen short of where one
+ wanted to go, one can hit ; and get there. Likewise, on doing Ntx
+ and finding one has fallen short, one should be able to hit ; and get
+ to the the next occurrence; but at present, hitting ; leaves
+ the cursor in the same position; one must hit ``2;'' to get any
+ further. In effect, Ntx is presently defined as Nfxh; I am
+ suggesting that it be defined as lNfxh.
+Agreed.
+
+ The sequences cw, dw and yw are presently violations of the
+ principle that c[movement], d[movement] and y[movement] change,
+ delete, or yank everything from the current cursor position through
+ the endpoint of the movement command. cw does what one would expect of
+ ce (in fact, they seem to be synonyms), while there is no way to get
+ the effect which cw would have if it were treated ``consistently''.
+ (E.g., if I have a line beginning ``And if'', and I want to change it
+ to ``If'', I cannot just put the cursor on the A and hit cwI^].) dw
+ and yw delete up to the character immediately before the point to
+ which ``w'' would take the cursor. I would have to agree that this
+ behavior of dw and yw is more useful than that which a literal
+ interpretation of the movement rule would lead to; but perhaps it
+ would become still more useful if when applied to the last word on
+ a line, it deleted or yanked the space immediately before the word
+ along with the word... . On the other hand, one could argue for
+ making a distinction between cw and ce.
+This is to make the user interface friendlier, and is a fact of life.
+If I wanted to change "And if" to "If", I'd type "dw~".
+
+ Though I see the motivation for the above definitions,
+ I see no sensible reason why Y should be equivalent to yy, when
+ C and D are equivalent to c$ and d$. I would vote for changing
+ Y to mean y$.
+The users wouldn't stand for such a change. Too many are used to it like it is.
+But you could always map it.
+
+ RADICAL SUGGESTIONS
+
+ Is there any reason for maintaining the distinction between
+ the ``:'' state of vi, and ex itself? At present, there are
+ relative advantages that lead one to choose to go into one or the
+ other for a given operation: From the vi-: state, it is easier
+ to return to the regular vi state; from ex, one has a more powerful
+ range of commands; and it is easier to give a series of commands
+ because each carriage-return gives one a new prompt. My suggestion
+ is that from vi, ``:'' should carry you directly to ex, and when you
+ are in ex, carriage-return (^M) after a command should give you a new
+ prompt, while ^] should put you into vi. Conceivably, things might be
+ simplified even further, and carriage return rather than : could
+ be the key that would carry one from the regular mode of vi into ex:
+The basic problem here is that if : put you into ex mode, you'd have to redraw
+the screen when you hit return. The motivation for : commands is that you
+don't have to go through a conceptually hard mode change and wait for a
+screen redraw.
+
+ .-------. .-------.
+ .-------. a,i... | basic | ^M | |
+ | vi |<------ | |----->| ex |<---.
+ | insert| | vi | | | |^M
+ | mode | ------>| |<-----| mode | ---'
+ `-------' ^] | mode | ^] | |
+ `-------' `-------'
+
+ (Of course, ^M presently has a meaning in vi, but
+ it has a synonym +.) Clearly, there would also be no need for a
+ special "Hit return to continue" state.
+ I have not distinguished vi and open in the above diagram.
+ My idea here is that ^] would actually return you to either vi
+ or open, whichever you had last been in, and that to switch
+ to the other, you could enter ex and type vi^] or o^] respectively.
+ (Or you could type vi^M, respectively o^M, and further ex commands,
+ and the mode would be saved for the next time you hit a ^].) Or
+ alternatively, these could be made settable options: se visual
+ respectively se novisual.
+ Having gotten used to the editor as it now exists, I admit that
+ I feel uneasy about the above idea -- the sense of knowing that
+ I am ``still in vi'' when I hit :, and not that ``other land'' of ex,
+ represents a kind of of orientation that it is disconcerting
+ to abandon. But I can't see any logical disadvantage in making
+ such a change. Can you? Certainly, there would be things that
+ would have to be thought out, such as what happens to bottom-line
+ vi pattern-searches. My thought would be that ``/'' from vi should
+ give :/ (i.e., put one in ex at the start of a pattern-search),
+ and ^] after a pattern-search should put one into vi at the appropriate
+ character on the line, in contrast to ^M after a pattern search,
+ which would leave one in ex at the appropriate line. In general,
+ I think such changes would lead to greater simplicity and learnability
+ of the editor.
+ I would also hope that excursions between vi and ex and back
+ could be allowed in scriptfiles. It might also be desirable for
+ ex to have, in addition to a concept of ``current line'', one of
+ ``current cursor position''... .
+
+ Well, on to another subject. One of the inconveniences I
+ found very vexing when first learning to use the editor was that
+ when in either vi insert mode, or ex/vi-bottom-line, it was very hard
+ to edit what I was doing. Within insert mode the only ``editing''
+ I could do, without escaping, was with the three operations ^H,
+ ^W and the kill character. And on a slow line with a dumb terminal,
+ escaping to make changes could be very time-consuming because large
+ parts of the screen would insist on being redrawn. Perhaps some
+ other control-character could serve as
+ a modified escape, that allowed one to edit what one had entered
+ in the current insertion without having everything below it redrawn,
+ and then return to it. Obviously, if carried to its logical
+ limit this idea could lead to ridiculous nests of
+ editing operations; but there would be no need to carry it to its
+ logical limit.
+Why not just get a terminal with insert char? You're paying in performance
+for having an obsolete terminal.
+ Anyway, the problem of editing ex-style commands
+ was even worse, because there was no way to ``escape and
+ revise''. I eventually learned enough to realize that the solution
+ was to edit complicated commands in another file and source it.
+This is a standard complaint about a moded editor. It couldn't be fixed
+without taking away the property of ESC ending command lines. Besides,
+allowing editing on the bottom line would really break a lot of code.
+ But it is sometimes very useful to have the text on which the
+ commands are to act in front of you when composing them (e.g., you can
+ yank and modify various pieces), which led to the variant of writing
+ command lines within the file I was editing, and then writing
+ those lines into another file and sourcing that, without ever leaving
+ the current file. But this is distracting to deal with
+ when concentrating on the editing task itself, which led me
+ to divise a scriptfile which would handle the writing-to-another-file-
+ and-sourcing for me. Or actually, several such files: One for
+ single-line commands to be used essentially once; one for single-line
+ commands that I would want to use on the same file during various
+ editing sessions, and so would want to keep available in that
+ file, and one for multi-line commands (to be used once). When
+ I first got the idea, I thought one scriptfile would be enough, and
+ I would call it ``do'', so that the command to execute a script I
+ had written in a file I was editing would be ``:so do''. The
+ file it would write to and source would be ``do.again'', so that
+ if I wanted to reuse it, I could ``:so do.again''. When I realized
+ the need for several versions, ``do'' became a directory. Here,
+ for your amusement, are the three files. (Re the lines ``se prompt'',
+ cf. my comment on that under PROBLEMS WITH SOURCE etc.):
+
+ do/1 (for 1-time use of 1-line commands)
+ .w! ~/do/again
+ d
+ so #
+ se prompt
+
+ do/1+ (like above, without deleting the command)
+ .w! ~/do/again
+ so #
+ se prompt
+
+ do/: (to use this, write a multi-line command script, put : at
+ the beginning of the first line, put the cursor on the last
+ line of the script, and then source the following:)
+ ?^:?s/:/
+ ,''w! ~/do/again
+ ,''d
+ so #
+ se prompt
+
+ (I also created another version to use in case the script had
+ to have an internal line beginning with ``:'', so that this couldn't
+ unambiguously mark the beginning of the script. This used
+ a line which explicitly specified the address-range of the script.
+ But I have never had a need for it, so I will not bother you with it.)
+ Finally, having gotten an account on a machine with a version 3
+ editor recently, I have divised still another way of doing this. I
+ have put in my EXINIT the command
+
+ 'map ^A "ayy:@a^M'
+
+ and now, gratifyingly, the single stroke ^A has essentially the effect
+ of ``:so do/1+'' -- except for the restrictions to which vi ``map''
+ commands are subject. But I've only been using this for a
+ couple of weeks; so I have yet to learn how chafing those restrictions
+ will or won't be.
+ Anyway, it might be worth thinking about whether some of these
+ things that I've done with macros should be incorporated in some form
+ into the editor itself; or else whether these macros might be written
+ up in the documentation (or some tutorials) on the editor.
+
+ Next subject: Complicated pattern-searches in long files
+ can be time-consuming. I have seen the point mentioned
+ that if a pattern-description can be begun with "^",
+ this can speed up the search -- since the pattern-comparisons need
+ only be begun at beginnings of lines. In some cases, this might
+ not be possible, but the user might be aware of some other
+ character or character-sequence in the search-pattern
+ that will occur relatively rarely in the file. In such cases it would
+ be desirable if the user could specify one spot from which the pattern
+ search should start, working forward and backward from there, to
+ minimize false starts. E.g., if for some reason one wants to
+ delete every word containing the letter m, the script
+ %s/[^ ]*m[^ ]*//
+ would become much less time-consuming if one could mark the point
+ at which to begin, say writing
+ %s/[^ ]*\!m[^ ]*//
+ so as to instruct the editor to search for m's, and each time
+ one was found, to find the longest possible strings of non-space
+ characters before and after it, and delete these. (This is a silly
+ example, but I think the idea is clear.)
+Isn't worth doing - this is fast enough for most people in most cases.
+
+ Something that I've seriously felt the need for is the
+ capability of searching for lines that satisfy more than one
+ condition. If one just wants to locate such lines, one can
+ of course leave the editor and do a pipeline of two or
+ more greps; but it would be nice to be able to perform global
+ commands on such lines.
+You want the PWB "or" operator. This is hard to put in - their code
+is really convoluted.
+
+ Finally, any possibility of introducing the capability of searching
+ for patterns including embedded newlines, a la sed?
+Newlines aren't stored - the data structure is an array of lines.
+So this is nearly impossible.
+ Multiple windows, a la emacs?
+Would be easy after a rewrite, but impossible with current code.
+What you really want is a window manager, anyway, most of the time.
+
+ ADDENDA
+ I logged in this morning on an adm3a at 300 baud to go over this
+ letter once more before sending it, and ran into another bug! I had
+ done 15^D to get a large scroll despite the low speed, and at one point
+ I saw a line with a typo scrolling up. So I noted its line-number, 402
+ and without waiting for the screen to stop moving typed something like
+ 402Gfsrd. What happened was that the change was made on line 407 rather
+ than 402 -- presumably the cursor was sent to where 402 had been when
+ the command was received... .
+Knowing the internals of vi, I'd say this is impossible. It probably just
+screwed up your screen from line noise (or your terminal isn't truly full
+duplex), or you got the wrong line number.
+ Editing this letter this morning reminded me of another feature I
+ have thought would be desirable for editing on dumb terminals at low
+ speeds: An option that would cause lines read from a file or typed
+ in at the bottom of the screen to appear double spaced, with @ signs
+ @
+ between them, such as one gets when one deletes a line on such a
+ @
+ terminal. (I have faked this effect here, though the fake will not be
+ @
+ very successful if you have se nu or se list on.) The point is that
+ @
+ editing operations that presently cause painfully slow screen-redrawings
+ would simply put material in in place of these fillers -- as happens
+ now when one is lucky enough to be adding material just above a place
+ where material was previously deleted.
+Again, it would cost less to buy a real terminal. You can get one for $500
+or so now from Falco or Liberty or Zenith.
+
+Thanks again for the input.
+
+ Mark
+
+
+From gbergman@UCBCARTAN Fri Jul 29 16:07:10 1983
+Date: 29 Jul 83 16:02:06 PDT (Fri)
+From: gbergman@UCBCARTAN (George Mark Bergman)
+Subject: editor
+Message-Id: <8307292302.AA09635@UCBCARTAN.ARPA>
+Received: by UCBCARTAN.ARPA (3.342/3.7)
+ id AA09635; 29 Jul 83 16:02:06 PDT (Fri)
+Received: from UCBCARTAN.ARPA by UCBERNIE.ARPA (3.336/3.7)
+ id AA06658; 29 Jul 83 16:07:04 PDT (Fri)
+To: cc-03@ucbcory, danh@kim, lindahl@topaz, mckusick@ernie, ralph@ucbarpa
+Status: RO
+
+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
+
+From gbergman@ucbcartan Fri Sep 23 13:57:06 1983
+Date: Fri, 23 Sep 83 13:53:36 PDT
+From: gbergman@ucbcartan (George Mark Bergman)
+Message-Id: <8309232053.AA02960@ucbcartan.ARPA>
+Received: by ucbcartan.ARPA (4.6/3.7)
+ id AA02960; Fri, 23 Sep 83 13:53:36 PDT
+Received: from ucbcartan.ARPA by UCBERNIE.ARPA (3.336/3.7)
+ id AA20684; 23 Sep 83 13:57:01 PDT (Fri)
+To: cc-03@ucbcory, danh@kim, lindahl@topaz, mckusick@ucbernie, ralph@ucbarpa
+Status: RO
+
+Latest letter on ex~vi to Horton:
+
+Dear Mark,
+
+ I hope I can assume that after my long letter to which you
+replied, you did get my two shorter notes (one sent the same day,
+the other about a week later); and that you've simply been to busy
+to think about them or reply.
+ However, since I have had bad experiences with Mail, I am worried
+that either you may never have gotten them or that you may have replied
+and your replies not reached me. I hope you can send me a one-liner to
+relieve my doubts.
+
+ Not many bugs to report this time, but I will modify or discuss
+a few of the suggestions I've made before.
+
+ One that I want to modify is my suggestion that % should also
+match < with > and ` with '. All right in itself, but terrible if it
+would also mean that with :set match, every time one typed a > or a '
+the cursor would look for the last occurrence of < or `, since <, >, and
+' can occur in ways that have nothing to do with matching. So I think
+that making matchable pairs user-specifiable would be much more useful.
+Faith Fich (who send her regards -- she and Mike were our neighbors till
+a month ago, but have left for their new jobs at U. Seattle) suggested
+that user-settable matches would be particularly useful for those
+like herself who use distinct opening and closing delimiters with eqn.
+Actually, on further thought this isn't quite right, since eqn
+delimiters behave differently from parentheses -- if I want to use =
+as my delimiter to enter equation mode, and & as my delimiter to leave
+it, then eqn will not give any special treatment to &'s in text mode or
+='s in equation mode; so perhaps a different kind of matching for
+that kind of use might be desirable; one would set :set dmatch =&
+for the delimiters suggested above; or :set dmatch $$ if one uses $
+for both delimiters as in the eqn tutorials. I know checkeq is
+supposed to serve this function; but it would certainly be convenient
+to have it in the editor; and anyway, my experience was that checkeq
+didn't understand that one could have distinct opening and closing
+delimiters. (But this is a disinterested suggestion; I haven't used
+eqn for a long time; I put in my equations in raw troff.)
+
+ The suggestion in my long original letter about an alternative to
+the diagnostic "using open mode" was based on a misunderstanding -- but
+one that might be worth making a reality. I had been assuming,
+since tutorials referred to the "three states" ex, vi, and open, and
+since I knew one could enter the editor by typing % ex filename or
+% vi filename, that a third way to enter the editor was by typing
+% open filename, and that this is what one should do when editing
+with a device not having an addressable cursor (which I had never done).
+So I supposed that the diagnostic "using open mode" would only be
+received if one were trying to use the wrong mode of the editor for the
+tty type shown in one's environment. Perhaps one should indeed have
+special way to enter the editor when one intended to edit in "open
+mode". (If "open" has other uses as a command, the command might be
+"vo" or "op".) Then if a user gave the command vi and his
+environment did not indicate a device with an addressable cursor, it
+would indeed be appropriate to give a diagnostic informing him that his
+environment was not compatible with this command. I suggest this
+because of the frustrating experiences I had as a beginner, of
+being put into open mode (because my tty type had somehow been lost)
+and not knowing what I could do about it.
+
+ I am somewhat confused by your explanation that editor scripts
+that would go back and forth between ex and vi modes (using the :vi
+and Q commands) are impossible because "The internals of getting a
+character from the tty are completely different in ex and vi. Pushing
+input for one doesn't affect the other." A vi "script" (i.e. a mapping
+or a macro called by @x) can presently include bottom-line commands
+called with ":". I would suppose that the way such commands get
+characters from the terminal is about the same as the way ex does.
+You also write that "Any : command that outputs more than 1 line puts
+you into "ex mode"," -- is this a different sense of "ex mode"? If
+not, what happens when a vi script does this?
+ I mentioned that the :so command from vi ignored anything after
+any global command in the sourced file. I also find that it will not
+accept the ex commands i and a; I realize that a prohibition against
+these is part of the way vi's bottom line differs from genuine ex.
+I've just done some experimenting, and I find that a script sourced
+from the bottom line of vi also interprets the command vi as a command
+to edit another file. Do we really want script files to be interpreted
+so differently when sourced from ex mode and from the bottom line of vi?
+Or if these differences are inevitable, can't the vi version at least
+have the positive difference of being able to go to visual mode with
+^M^M or something, and continue following the script, interpreting
+characters as screen mode commands, just as a mapping or @x macro will
+if it has gone down to the bottom line with ":" and come back again?
+ I am also still reluctant to give up the idea of a version of the
+editor in which there is no difference between the line-oriented mode
+and the bottom line of the visual mode. Suppose you took the editor as
+it exists now, and modified it so that in visual mode, ":" was
+interpreted as "Q", and in ex mode, ^[ was interpreted as ^Mvi. The one
+obvious disadvantage would be that it would insist on redrawing the
+screen after minor editing operations in ex mode. So suppose you made
+it remember the previous state of the screen every time it entered ex
+mode, and make the necessary adjustments on return to visual mode if the
+editing done was fairly trivial -- using the same criteria it now uses
+after bottom-line commands. What would be the problem?
+ Of course, I know I am quite ignorant of what is involved, and what
+I am suggesting as possible may be quite impossible, or may have to wait
+for that far-off day when you rewrite the editor.
+
+ You write that some of the restrictions on global commands are due
+to the fact that the state of the buffer before the command is stored in
+the "last deleted" buffer. But couldn't this situation be modified?
+Let's call the "last deleted" buffer buffer 0, since material from it
+seems to progress up to 1, 2, etc. with successive changes made.
+Suppose things were set up so that during the operation of a global or
+macro, deleted material, yanked material, etc. went by default into
+buffer 1 instead of 0...? Or alternatively, that the state before the
+global were saved in buffer 9, and this was then set outside of the
+chain of buffers into which material got pushed with successive
+deletions, during the operation of the global? Would this eliminate
+the objection to nested globals as well? Presumably, in a global within
+a global, the previous state would be stored in buffer 1, and new yanks
+put by default in buffer 2 (if the first of the above suggestions were
+followed).
+ You mention in your comments to my letter that the difficulty of
+editing command lines "is a standard complaint about a moded editor"
+that would be hard to fix. But I point out in that same letter how
+appropriate macros or script-files can overcome that difficulty. (My
+files "do/1", "do/:" and the "map ^A ..." in my EXINIT.) It should be
+possible to introduce commands that would have the
+same effects as those macros. (Or at least, to describe such macros
+in the documentation. I have realized, by the way, that ^A was a poor
+choice of character for me to map, because it occurs in the output of
+function keys on a lot of terminals.)
+
+ It would be nice to extend the kinds of "regular expressions"
+allowed in searches, e.g. a la egrep. Sometimes I also want to indicate
+something like "a substring of precisely 40 characters". This can be
+rendered as "........................................" at present,
+but things like that can easily lead to commands that
+exceed length limits. (Suppose one wants to look for a string of
+40 successive characters other than whitespace. [^ ][^ ][^ ] ... is
+too long.) Have you checked out what I mentioned in my first long
+letter, that ed allows you to search for (e.g.) successive
+identical characters as \(.\)\1?
+
+ Let me pass on a suggestion made recently in a system message by
+someone named nye. He was worried about what would happen
+if while one person was editing a file, someone else with write
+permission for that file also began editing it. Presumably, whoever
+did a "write" last would overwrite the other person's work. He
+suggested that there be a diagnostic "file has been changed since last
+write" for such a situation. (In particular, he wondered what would
+happen if he got his mail by editing /usr/spool/mail/name, rather than
+by using Mail -- which is certainly tempting if one is more comfortable
+with the editor than with Mail -- and if unbeknownst to him new mail
+arrived while he was editing.)
+
+ I have discovered the hard way that when one has done a
+vi -r filename and decided one was satisfied with the version that
+was saved, ZZ or :x are n o t the same as :wq -- the first two
+discard the saved file, and only the last one writes it over the
+previous version. (I actually haven't checked this out on version 3.9.
+I tried to, and found that robert hadn't brought
+/usr/lib/ex3.9{preserve,recover}, if that's what they're still
+called, from arpa along with the rest of 3.9. But he's getting them for
+me.) If you don't want to make ZZ and :x actually equivalent to
+:wq, you might at least make them give error messages forcing the
+user to make the explicit choice of :wq to keep the saved version, or :q
+to discard it.
+
+ I've been having fun using recursive "map" commands from time to
+time. For example, a file of mailing addresses of Math Departments is
+being prepared, for use with a new Computer Services command "label".
+This requires that each address constitute one line of the file, with
+the intended lines of each label separated by
+semicolons rather than newlines, each being no longer than 34
+characters. At present, the lines in the file are of the form
+[university-name];[city-state-zip]
+and I wanted to find cases where the university name the secretaries
+had typed in was over 34 characters long. So I did
+:map ^A +36^V|F;^A0
+Then, when I hit ^A, the cursor went bopping down the file, passing
+through each line at which it could find a ";" before the 36th position,
+but stopping when it hit a line where it could not. When I had
+corrected such a line, by abbreviating a long word or whatever, I could
+hit ^A again and find the next case. The "0" at the end of the map
+command is to prevent the "No tail recursion" rule from aborting my
+mapping. It has no other effect, because it is never reached.
+ Of course, the above example of a recursive mapping is guaranteed
+to stop eventually, if only by reaching the end of the file. But I find
+that mappings that can go on indefinitely are very hard to stop. E.g.
+:map q ax^[q0
+I've tried some like that, and sometimes hitting <break> or whatever
+enough times successfully stops them (often leaving a bit of a mess --
+characters that ought to have come after the string of x's embedded
+among them), while other times the only thing I can do is to go to
+another terminal and kill the editing process. Maybe it is to prevent
+things like that that you put in the "No tail recursion" rule --
+though clearly it can be gotten around. Might it not be better to
+somehow make the editor not quite so deaf to <break>s during such a
+process?
+
+ I will mention one curious experience which I have not been able to
+reproduce. I use :set nu. After a delete near the beginning of a file,
+I found myself looking at a screen with line-numbers beginning around
+-2! The lines with nonpositive numbers were blank, if I recall; lines
+1, 2, etc. were as they should be. I mentioned this to someone
+who said he'd had the same thing had happened at times, but had
+never been able to figure out what conditions caused it.
+
+ Best regards,
+ George
+
+From gbergman@ucbcartan Thu Nov 3 22:32:01 1983
+Received: from ucbcartan.ARPA by ucbernie.ARPA (4.17/4.13)
+ id AA25163; Thu, 3 Nov 83 22:31:44 pst
+Date: Thu, 3 Nov 83 22:28:11 PST
+From: gbergman@ucbcartan (George Mark Bergman)
+Message-Id: <8311040628.AA06097@ucbcartan.ARPA>
+Received: by ucbcartan.ARPA (4.6/3.7)
+ id AA06097; Thu, 3 Nov 83 22:28:11 PST
+To: cc-03@BERKELEY, danh@kim, lindahl@topaz, mckusick@ucbernie, ralph@ucbarpa
+Status: R
+
+Latest letter to Mark Horton re editor bugs etc.:
+
+copies sent to
+cc-03@ucbcory
+ralph@ucbarpa, lindahl@topaz, mckusick@ucbernie 25/7/83
+danh@kim 26/7
+Mark Horton's reply: anderson@kim 30/7/83
+
+Dear Mark,
+ I got your reply to my last letter, but you don't say
+whether you got the two preceding ones -- in particular, I'm
+curious as to what you'd say about the peculiar behavior of
+abbreviations terminated by \[character]. (E.g., suppose
+someone did :ab ac artistic, and then, supposing the file was for
+troffing, typed ac\fP. -- Try it!) And likewise, about what
+happens if you hit @x, when register "x contains
+ x:g/foo/s//bar
+(To see this wierd effect, you have to have a file with
+an occurrence of ``foo'', and a distinctive l a s t line.)
+
+ In an earlier letter I commented that the mapping that
+the editor sets up to enable the tvi's right-arrow key makes
+^L unavailable for refreshing the screen. You replied that,
+of course, the editor could not distinguish a ^L generated by
+the arrow key from one typed as <ctrl>-L by the user. True,
+but some users, such as myself, are quite happy using hjkl
+to move around the screen (I use them completely by reflex)
+and so have no wish to enable special arrow keys, but do
+want to have ^L available to redraw the screen when
+a message or something messes it up.
+ The problem with ^L occurred in using a tvi; now, using
+a Z29 (in h19 mode), another version of the problem arises.
+It has arrow keys that transmit things like ^]A, ^]B, etc.,
+and version 3.9 not only maps these sequences, but also
+map!s them. What I found happening is that if in typing
+I made a change somewhere in the body of a line and then
+wanted to add something at the end of the line, I would often
+type a ^] to end the first change and then an A to
+begin the second, with less than a second between them, and
+this sequence would then be map!ed into ^]ka or
+something, landing me in a different place from the one
+I wanted. Aside from this major problem, there is the minor
+inconvenience that the map! mechanism apparently waits
+a second every time I type an ^] from insert mode to see
+whether this is going to be one of the map!ed sequences, and
+this makes exiting from insert mode sluggish. My temporary
+solution has been to write a file of the form
+ unmap ^]A| unmap ^]B| ...|unmap! ^]A| unmap! ^]B|
+which I source every time I go into vi on the Z29. I
+guess what I should do is create simplified termcaps that
+leave out the arrow keys for my own use when in version 3.7.
+Kevin Layer tells me that when he puts 3.9 on all systems here,
+there will be documentation on how to create terminfo files;
+so I will be able to avoid these inconveniences in 3.9 as well.
+ What would be better, for these two-or-more character sequences,
+though, would be if the "timeout" feature on mappings
+could involve a variable interval, which could be set in the
+millisecond range for terminal-generated sequences (I suppose
+it would have to depend on the baud rate), and longer
+for user-mapped sequences. The likelihood of the user
+accidentally typing in one of the special sequences so fast
+is negligible.
+ Incidentally, I notice that when I type :map to look
+at the automatic mappings, these are labeled "up", "down" etc.,
+though for mappings that I create the corresponding position
+just shows a repeat of the mapped sequence. Is there
+any way the user can put mnemonics in with his own mappings?
+
+ Two other minor points:
+
+ In your reply to my first letter, where I suggested that
+N/pattern should take one to the Nth occurrence of /pattern,
+you said that N/pattern actually resets the window size to N
+while carrying one to /pattern. The tutorial says the same,
+I believe, but nonetheless, it doesn't work!
+ When one has pulled a command into a buffer,
+say "x, and invoked it with @x, if one then tries to get
+a copy of this command by doing "xp, it doesn't seem to work.
+The way I've found to make it work is to do any other
+yank-and-put (using, say, the last-deleted
+buffer). This somehow unfreezes the mechanism, and (after undoing
+this last put, unless one wanted it), one can then successfully
+do "xp.
+ Yours,
+ George
+
+(Message inbox:32)
+Date: Sun, 10 Jun 84 16:29:50 pdt
+From: gbergman@ucbcartan (George Mark Bergman)
+To: cc-03@ucbcory, danh@kim, decvax!tarsa, gbergman@ucbcartan,
+ hplabs!intelca!omsvax!isosvax!root, ihnp4!burl!we13!ltuxa!jab,
+ leblanc@ucbdali, lindahl@topaz, mckusick@ucbernie, priili@Ardc.ARPA,
+ ralph@ucbarpa, reiser@ruby, romine@seismo.ARPA, unisoft!eryk,
+ uw-beaver!ubc-vision!mprvaxa!sonnens
+Subject: more editor bugs & ideas
+
+ Here's another letter of comments on the editor that I'm
+sending to Mark Horton (mark@cbosgd).
+ If any of you to whom I'm sending this aren't interested in
+staying on this mailing list, just let me know.
+ Horton replied to an earlier letter by saying he had no idea
+when he'd have any time to work on the editor again, so I don't
+expect replies from him to this and further such letters in the near
+future.
+ For those who are not familiar with the subject of item "A."
+below, modeline is a feature that he added without publicizing it much,
+whereby if any line in the vicinity of the top or bottom of the file
+(top and bottom 10 lines? I don't remember) contains the string
+vi: or ex: and then another :, everything between these is
+interpreted as a command and executed when this file is read by the
+editor. There was a big squall in net.news when someone discovered
+it by chance (an accidental string of this sort occurred in their
+/etc/password; fortunately the "command" was meaningless, and evoked
+a diagnostic from the editor). Some serious dangers of this
+feature were pointed out by various contributors, one of whom described
+for all who were interested how to eliminate it from the source file.
+
+Dear Mark,
+ Here's another few month's collection of comments...
+
+A. Modeline
+ I presume that in following the net.news discussion of the
+``MAJOR BUG (modeline)'' you saw my two contributions; but I'll
+summarize the relevant points (not in the order I made them):
+
+1) One possible feature that would be about as convenient as
+the modeline, and would avoid the dangers that people have pointed
+out, would be `enhanced tags', in which the 3d entry of a line of the
+tags file could be not merely a pattern search, but an arbitrary
+command line.
+
+2) I described (both in net.news and in an earlier letter to you) a
+mapping in my EXINIT which makes one keystroke yank the current line
+(or the next N lines if preceded by a count) to a named buffer
+and then execute that buffer. If one keeps a set of initializing
+commands within a file to which they are to apply, one can then
+easily execute them on beginning an editing session, which gives
+almost the convenience of the modeline feature, without the dangers,
+and has an enormous range of other uses. So I think the modeline
+feature could be dropped.
+
+ Let me add to those points:
+
+3) A modeline
+ vi:r %:
+leads to an infinite recursion! Fortunately, ^C cuts it off.
+
+4) I agree with others' comments in net.news that if the modeline
+feature is not dropped altogether, it should be a settable option
+with default ``nomodeline''.
+
+5) It should certainly be off when ``novice'' is set!
+
+B. Tags
+ Having mentioned these in point A(1), I will give some other
+comments I have: One of your update documents mentions the fixing
+of a bug that left ``nomagic'' set if the file named in the tags
+file did not exist. Very good, but one still ends up with ``nomagic''
+if the file exists but the pattern-search is unsuccessful!
+ It would also be nice if the tags file could include file addresses
+of the form ~user/filename, in particular ~/filename, and if the
+command :set tags= recognized the same. (I suppose this makes no
+difference to people who get their tags from ctags, but for me, the
+tags file is maintained as a collection of items I have been working on
+recently, or mean to soon, and entries are put in or removed by
+hand regularly.)
+
+C. Reversal of n and N
+ I also mentioned in one of my net.news comments a peculiar behavior
+that often seems to occur after I've been using my yank-and-execute
+mapping a lot, in which, after a command-line pattern-search :/pattern
+(rather than simply /pattern), the screen-mode commands n and N give
+searches in the reverse of the expected direction, with ? and /
+respectively instead of vice versa. Perhaps you can figure out what
+causes this; if not, would it help for me to do something like make
+a core dump of the editor when it is happening and send it to you?
+(I don't know how to send a nonascii file, though... .)
+ A few more observations on this behavior: Though I commonly
+discover it when I am using my yank-and-execute mapping, it has
+happened on at least one occasion when I hadn't use that at all,
+so far as I could recall. It may actually happen quite frequently,
+but people just don't notice it because they usually use /pattern
+instead of :/pattern. (My mapping makes it more convenient for
+me to use the latter when the pattern is complicated, or I want to
+store it for repeated use.)
+
+D. Update on dangerous recursions
+ Discovering that ^C interrupted the recursive modeline led me
+to test it out on a recursive mapping, :ab x ( x ). It interrupts
+it OK. Problem solved courtesy of 4.2BSD, I guess.
+
+ I will collect under the next heading my usual list of:
+
+E. Minor bugs and modest suggestions
+
+ ye and yE yank one character less than they should.
+
+ If the command Ne (N a count) would land one on a 1-letter
+word, one generally lands at the end of the next word instead
+(even if it is also a 1-letter word. Exception: if one starts
+at or after the end of the preceding word, e behaves as it should.)
+
+ Note also that in the line
+ Sentence... . Sentence
+if the cursor is on the second S, the command ( causes no motion
+at all.
+
+ I suggest that the motion commands { and } should accept indented
+lines as paragraph-starts, or at least that there should be some
+way of requesting this in the ":set para=" command. After all, these
+motions shouldn't be useful only to people writing troff files!
+
+ In general, the command NC (where N is a count) changes material
+from the cursor position to the end of the Nth line, leaving material
+before the cursor on the current line unchanged. But if the line
+is indented, and the cursor is on or before the first nonwhite
+character, the preceding white text (spaces and tabs) is lost.
+
+ It should be possible to use
+ :unmap #1 :unmap! #1 :unab #1
+when function-keys have been mapped.
+
+ Sometimes a noisy phone-line, termcap padding errors, etc.
+cause just one or two lines of the screen to be messed up, and one
+may only wish to refresh those lines. Could a command be introduced
+which would do this? Ironically, on a dumb terminal one can generally
+do this by moving the cursor over the line, but not on a smart terminal.
+Another way one can do it is ddP, but I would sometimes feel uneasy
+about unnecessarily modifying the text. I would
+suggest that the form of the command be 1^L (2^L for 2 lines, etc.).
+Currently, ^L apparently ignores counts. (Actually, I'm writing at
+the moment on a tvi, so I've verified this for ^R rather than ^L.)
+
+ If one uses the source command, and the file sourced contains
+a command
+ :e newfile
+where newfile does not already exist, the diagnostic ``No such file
+or directory'' aborts the sourcing process. One ought to be able to
+use such commands in a sourced file.
+
+ In vi screen command mode, ^[ is supposed to ``cancel partially
+formed commands'' and generally does so without protesting, but if the
+partially formed command is a count (e.g., if one has typed 110 instead
+of 10 and wishes to start over) it feeps, which depending on one's
+terminal can be a minor or a major annoyance. (Also depending on
+whether someone is trying to sleep in the next room.)
+
+ The diagnostic, ``First address exceeds second'' should not be
+needed with one-address commands! The case where a series of addresses
+before a command, of which the first may exceed the second, is most
+useful is when the last address is a pattern-search preceded
+by a ";", e.g.
+ :$;?^\.PP?-r otherfile
+but let me give simpler examples; of the two commands
+ :3,1,2ka :1,3,2ka
+the first correctly marks line 2, but the second is aborted by the
+diagnostic quoted.
+
+F. A feature that would be very desirable, and might or might not
+be easy to implement.
+
+ In general, when one is inserting text on a smart terminal in vi,
+the context below the text being added is pushed downward, line by line,
+till none is left on the screen. I would like a settable option that
+kept a certain number of lines of following context on the screen
+during additions. The point is that one should see the material that
+what one is writing will have to mesh with. What would be involved in
+implementing this would, of course, depend on terminal capabilities.
+If it would be difficult to keep an arbitrary number of lines,
+would it at least be possible to have an option that would keep one
+line, using the special bottom-line feature of some terminals?
+
+G. More radical suggestions (wishlist).
+
+1) Editing text with _\bu_\bn_\bd_\be_\br_\bl_\bi_\bn_\bi_\bn_\bg.
+ Although one of the valuable features of vi is the explicitness
+with which most nonprinting characters are shown, this can be annoying
+when one wants to deal with text in which many characters
+are ``emphasized'' using the sequence _^H; e.g. nroff output. I
+suggest a settable option under which such sequences would be shown as
+with ul.
+ I realize that this would involve working out a great number
+of details, e.g. would motion commands treat _^Hx as one
+character or as three? How would the nth column be defined? How
+would one place the cursor on one of the elements of the string
+_^Hx for editing purposes? What would be done with _^H^A or _^H_^H....?
+ I think the best solution would be to treat _^Hx as a single
+character for the purposes of motion commands, definition of nth
+column, deletions, etc. when this option was set. In terms of placing
+the cursor, two possibilities occur to me. One would be to only allow
+the cursor to sit on the underlined character ``as a whole'', and to
+have changes in underlining done by special commands: perhaps ^E as a
+toggle to turn emphasis on and off in insert mode, _ to change
+underlining in screen command mode as ~ changes capitalization
+("_" is at present a synonym to "^", except
+that it takes counts. ^ could be modified to take
+counts, and _ then used as suggested above), and \e in replacement
+patterns. The other would be to consider a cursor sitting ``on''
+a sequence _^Hx to actually be on the x, and to set things up so that
+if the cursor is on any of the other members of this sequence, the
+sequence is ``expanded'' on the screen, i.e. shown as it is in the
+present vi. Then define a single vi command so as not to skip over
+the _ and ^H in such a sequence; namely ^H. (This would mean
+making a distinction between h and ^H in screen command mode.)
+This one motion would allow one to edit parts of such a sequence.
+
+2) Editing several files at once.
+ When I have to do work that involves more than one file, the
+repeated use of :w|e#, yanking text to named buffers to move it, losing
+marked lines when I return to a previous file, etc. becomes
+annoying. I think it would be desirable if one could make a group
+of files behave like one file during an editing session, and move
+around within that file as comfortably as one move within one file.
+ I suggest that visually, each file be separated from the next
+by a pattern
+:::::::::::::::::::
+as when ``more'' is applied to a group of files.
+For ``Go to file 3, line 20'' I suggest a screen command syntax
+*3*20G. *-1* and *+2* could mean ``the preceding file'' and ``the
+file after next'' in such commands. (The initial * could be optional
+if there is no preceding + or -, as in the first example.) In a
+command such as :w, the default address range would be all of the file
+to which the current line belongs (i.e.,
+it would be a synonym for :*.*w) To write all files, I suggest :**w.
+:q, :x and ZZ would quit the editing session entirely, while :*1*q
+would remove the buffer of file 1 from the object being edited.
+On the other hand, relative motions such as 10j, H, etc. would work
+within the ``visible object'', the union of the files.
+%s/pattern/repl/ would apply to the file containing the current line,
+and would have the synonym *.*s/pattern/repl/, while
+*1,2,4*s/pattern/repl/ would affect the 3 indicated files, and
+**s/pattern/repl/ would affect all files.
+
+3) Input and output of shell escapes.
+ The various commands involving shell escapes that you have
+set up allow four possible relations between the text being edited
+and the input and output of the commands: none (:!command);
+specified line-range as input with output not affecting text
+(:address-range w !command); no input from text but output inserted at
+specified line (:address r !command); and specified input from text
+with output replacing input (:address-range !command).
+ It would be nice to have more flexibility; in particular, to
+be able to include input from the file and place the output somewhere
+else in the file without destroying the input text, and to input
+more than one segment of text, e.g.
+ !egrep -f[addr.range] [other.addr.range] > [place of insertion]
+Obviously, there would be a problem of setting up a syntax that would
+avoid confusion with strings that look like address-ranges in the
+shell command. Perhaps \[...\] could enclose address-ranges where
+I have used [...] above.
+
+4) ;
+ The ; syntax, allowing one to do a pattern-search starting
+from a specified line is useful, but in setting up 2-address commands,
+one does not necessarily want the point from which one starts the
+search for the second address to be the first address. If this business
+were being set up now, I would suggest that
+ address;/pattern/
+should simply be a way of specifying the result of doing the indicated
+pattern-search relative to the indicated address, so that
+ :address1,address2;/pattern/d
+would delete from address1 to the location found by the pattern-search
+relative to address2. Since people are used to the existing
+syntax of ;, I suggest that some other symbol be used in the above
+way, e.g. ], so that
+ :address1,address2]/pattern/d
+could be interpreted as described.
+
+5) Insertions into long lines on smart terminals at low or medium
+baud rate (e.g. 1200).
+ This is annoying because the material coming after the point
+of insertion begins to wrap around, and the cursor must jump back and
+forth, inserting characters at the beginning of the
+continuation line, then going back to the point of insertion, and so
+on. (At least, this is my experience on my Z29. I haven't done
+editing by phone connection on any other smart terminal.) It's
+actually nicer on a dumb terminal, where the editor just overwrites,
+and shows you the result after you escape. I suppose that the need
+for the cursor to jump back and forth is due to the deficiency of the
+terminals -- has anyone suggested to terminal manufacturers that along
+with the wraparound feature, they add a feature which ``remembers''
+when a line is a continuation of the preceding line, and automatically
+pushes material from the preceding line into the continuation line
+when characters are added to the former, eliminating the need to send
+all these instructions in over a slow line? (Do terminal manufacturers
+listen to editor-software specialists?) If not, it might just
+be best to not show the pushed-over earlier material till the insertion
+is complete.
+
+6) Filename convention
+ This is really a suggestion for UNIX generally, but it could be
+implemented on the editor separately. It is that for any file,
+filename/.. denote the directory in which the file lies. (This
+does not mean that every file should be treated as a directory, or
+that the ls command should show filename/..; it would just
+be a convenient way to refer to the directory containing a given
+nondirectory file, consistent with the existing convention for
+directories.) Within the editor, the important cases would be
+%/.. and #/.., allowing commands such as:
+ :1,10w %/../othername
+
+ All for now! Yours,
+ George
+
projects / unix-history / commitdiff