Subversion Repositories planix.SVN

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)