![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to TODO CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.bin / ex / OTHER|
Return to TODO CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.bin / ex / OTHER |
1.1 root 1: From gbergman@UCBBRAHMS Mon Jul 25 16:21:43 1983
2: Date: 25 Jul 83 16:16:52 PDT (Mon)
3: From: gbergman@UCBBRAHMS (George Mark Bergman)
4: Subject: Re: editor bugs etc.
5: Message-Id: <[email protected]>
6: Received: by UCBBRAHMS.ARPA (3.342/3.7)
7: id AA22776; 25 Jul 83 16:16:52 PDT (Mon)
8: Received: from UCBBRAHMS.ARPA by UCBERNIE.ARPA (3.336/3.7)
9: id AA13678; 25 Jul 83 16:21:17 PDT (Mon)
10: To: mckusick@UCBERNIE
11: Status: R
12:
13: The following are (i) a short note from Mark Horton
14: in reply to a note of mine saying I'd been keeping notes
15: on editor bugs, had heard he had a new version, was
16: interested in hearing about it and perhaps sending
17: him notes on bugs not mentioned as corrected; (ii)
18: a long letter from me in which I do list bugs, features
19: I think would be desirable etc., (iii) an addendum I
20: sent the next day, (iv) brief jottings not yet sent.
21:
22: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
23: >From [email protected] Thu Jul 21 12:31:55 1983
24:
25: The new version of vi isn't very different to the user.
26: The internals use terminfo instead of termcap, but the
27: user interface isn't affected by this (except that it
28: starts up faster). The major new features are
29: set showmode
30: will cause an indication on the status line when
31: you are in input mode
32: vedit
33: is a new invocation of vi for novices
34: more function keys now work
35: function keys work in both command and input mode
36: Of course, there are a few bug fixes too.
37:
38: There is a binary in ~mark/bin/vi on ucbarpa. It requires the
39: /etc/term heirarchy (there is no file called /etc/terminfo) which
40: was on ucbarpa once but might be gone now. If you want to grab
41: them from whereever they still exist, please feel free to try them.
42: Mark
43: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
44: Sent to Mark Horton 23/7/83, about 11AM
45:
46: Dear Mark,
47:
48: Well, your note didn't say you wanted me to send my comments
49: on editor bugs and suggestions, but you didn't say I shouldn't,
50: so I decided to do so. I've tried to organize it into some sort
51: of sections. I'd be interested to know which of the bugs mentioned
52: here you have already found and corrected. (I may soon find out for
53: myself; the person in charge of this machine says he'll try to get a
54: copy of version 3.9 from UCBARPA if they still have it, and get it
55: running for me. If you have any helpful information for him, he
56: is robert@brahms, Robert Gross.)
57: Vedit sounds like a great idea.
58: I should mention that throughout this letter, I have
59: avoided using actual control-characters, but faked them,
60: e.g. used ^ and H to get the appearance of ^H, since files with
61: real control-characters can be confusing when looked at in mail,
62: more, etc. But this means that if you want to try any commands I
63: refer to that use them, you won't be able to yank and source them,
64: unless you replace my fakes with real control characters.
65: The version I am using is 3.7.
66:
67:
68: PROBLEMS WITH COUNTS
69:
70: Some vi operations that logically ought to be able to take
71: counts do not, while others misbehave with counts. In this section,
72: ``N'' will always denote a positive integer placed as a count before
73: a vi operation.
74: The most gross case of misbehavior is that of N^B!
75: The effect is to redraw the screen 23N-44 lines further advanced.
76: (Probably the numbers depend on the screen-size of the terminal;
77: this is on a Z19, using termcap h19u.) When N=1, this does indeed
78: move you a screenful backward, but for higher N it moves the window
79: forward some amount! Further, whatever controls are supposed to
80: monitor whether the command would land one at an acceptable line-
81: number seem to have a different idea of what it is doing: If you
82: aren't already familiar with these weird effects, try setting the
83: cursor near the end of a file that is more than 4 screenfuls long,
84: and hitting 3^B. (You might then try an insert at the place you get
85: to, and a :f^] .)
86: N/pattern/ would be useful, but is not allowed.
87: ND would be a natural synonym for dN$, by analogy with NC for cN$,
88: but it doesn't work that way; it just ignores the N.
89: Finally, if N is precisely the number of lines
90: from the current line to the end of the file, N$ will still correctly
91: carry one to the last character of the file, but cN$, NC, dN$ and yN$
92: refuse to do anything! (NY does work, not being a synonym for yN$.)
93: The failure of NC is particularly annoying; often when I am composing
94: something, I go back to somewhere in the middle of the next-to-
95: last line, say, and want to rewrite the rest of the sentence;
96: 2cc would kill not only the part I want to rewrite but also the OK
97: beginning of the line, and 2C or 2c$ won't work. I realize that I
98: could get around this by keeping an empty line at the end of the file,
99: but that should not be necessary.
100:
101:
102: PROBLEMS REGARDING SOURCE, MACROS, MAPPINGS
103: These are enormously useful, but seem to have all kinds of hidden
104: restrictions.
105:
106: The Appendix to the Ex Reference Manual, "List of Changes from
107: Version 3.5 to Version 3.6" says ``A bug which prevented the source
108: command from working...from visual has been fixed''. It is true that
109: one can now use :so from vi, but it still has a bug: When
110: the scriptfile invoked contains a global command
111: and some other command(s) after it, everything after the first global
112: command is ignored. The same appears to be true of scripts in named
113: buffers invoked from vi-bottom-line by @x.
114:
115: (It is, perhaps, unexpected that one can invoke scripts with
116: multiline commands using @x from vi's bottom-line at all, since such
117: commands will not work if typed on vi's bottom line directly.
118: A script like
119: s/$/a\
120: b
121: invoked as @x will indeed work. But strangely, if one tries to
122: invoke from the regular mode of vi the script
123: :s/$/a\
124: b
125: by putting it in buffer x and doing @x, only the first line
126: will take effect.)
127:
128: Another serious restriction is that the command ``vi'' appears to
129: be ignored in sourced ex-scripts, and though the command Q in macros of
130: various flavors in vi (mapped characters, map!ed characters that contain
131: ``...^V^[...Q...''; @x scripts) does take one into ex, any ex
132: commands after it are ignored.
133:
134: I assume you are aware of whatever restrictions lead to the
135: error-message ``Cannot yank inside global/macro'', since you must
136: have written it, though ``inside'' seems to here have the peculiar
137: meaning ``after a text-changing operation of the macro.''
138: The error-message ``Can't undo in global commands'' is more
139: mysterious, since I get it when I have a global command after
140: a text-changing command in an @x script (though not in a sourced file).
141: Anyway, the fewer such restrictions these operations were subject
142: to, the more useful they would be!
143:
144: Although nested source commands are allowed (and I find them
145: useful), they leave the editor in a ``noprompt'' state. This
146: can be gotten around by including ``se prompt'' as a line in the
147: outermost scriptfile, but I would hope the problem causing it could
148: be cured.
149:
150: When one tries to ``:unmap!'' a ``:map!'' command whose
151: right-hand-side begins with ^H (entered as ^V^H, of course), one
152: gets the message ``That macro wasn't mapped''. (One can get around
153: this by using :unmap! ^V[character].)
154:
155: Certain termcaps apparently produce automatic mappings, which
156: unfortunately may interfere with useful vi commands. In particular,
157: on a tvi, ^L gets mapped to a movement command, which makes it
158: unavailable for redrawing the screen, unless unmapped.
159:
160:
161: PROBLEMS WITH DIAGNOSTICS
162:
163: "Hit return to continue" -- It took me a long time to realize that
164: when I got this diagnostic there was an alternative to hitting
165: return. I suggest it be reworded
166: "Hit Return or :"
167: However, the behavior of the editor when this diagnostic is given
168: seems to be inconsistent. In particular, when the last of a serious
169: of commands is
170: :e otherfile
171: and I get "Hit return to continue", then hitting : usually
172: has no different effect from hitting return (or any other
173: key), namely the screen is redrawn; yet I think that sometimes
174: in this situation it has brought me directly to the bottom line
175: as desired. Very confusing.
176: Would it be possible to have other alternatives than : and return
177: available, such as /pattern ? Or, more simply, when one would presently
178: be given the diagnostic "Hit return to continue", why not just put the
179: editor into the state it would have if one then hit :, since one would
180: then still have the option of hitting return and getting into vi
181: proper, but it would not require the extra keystroke : to
182: begin a bottom-line command, nor would one go through the frequent
183: frustrating experience of absentmindedly starting to write a
184: bottom-line command, or a pattern-search, and then having to wait
185: while the screen was redrawn because one had hit a key other than :.
186:
187: "Using open mode"
188: Again, it took me a long time to learn that when I tried to enter
189: vi and got this diagnostic, it meant that the system had somehow
190: lost the termcap for the terminal I was on, and that I would have
191: to do something to get the correct termcap into the environment.
192: Till I realized this, I generally ended up either struggling along
193: frustrated in open mode, or logging out and logging back in. I suggest
194: that when someone calls for vi and the termcap is not appropriate,
195: the editor should not be invoked in any form, but instead, a message
196: be given such as:
197: ``Your environment does not show a termcap entry permitting
198: the use of the visual editor. If you are working on a terminal not
199: supporting vi (in particular, a device with no addressable cursor),
200: you may enter one of the other modes of the editor with the command
201: "open filename" or "ex filename". If you are working on a terminal
202: that should support vi, your environment entries are incorrect and
203: should be corrected. They presently show:
204: TERM=....
205: TERMCAP=....
206: If you know the correct name or abbreviation for your terminal-
207: type, type it at the end of the next line; if not hit return:
208: % setenv TERM ''
209: If the user typed an acceptable terminal-name, the message would
210: continue, telling how to get the appropriate termcap. If the user
211: instead typed return, the message would ask him or her to type the
212: name of the manufacturer shown on the terminal, not
213: worrying about upper/lower-case distinctions, and a list of possible
214: terminal names and abbreviations would be given... . This whole
215: program would not be part of the editor, so there would
216: be no problem of space within the existing crowded confines of
217: the editor code.
218:
219: "No such file or directory" -- I think there should be a distinction
220: between these two cases, because of the important distinction in the
221: consequences when the user tries to quit the editor:
222: If the directory exists, the file is created, but
223: if not, the results are more complicated -- I seem to recall on one
224: occasion simply losing what I had written on my second try
225: at quitting; though I just now did an experiment and this time
226: repeated ZZ's and :x's simply gave repeated error messages.
227:
228: "File already exists..." -- The ``List of changes from 3.5 to 3.6'' says
229: ``If you get I/O errors, the file is considered "not edited"... .''
230: I presume that this correction is somehow the cause of the fact that
231: I frequently get the above message when trying to leave the editor
232: on a machine with version 3.7, and have to use
233: :w! %|q
234: to exit. But I've never seen any evidence that there were I/O errors;
235: it mainly seems to happen when I've written some lines to another
236: file in the process of editing. So the criteria the editor is using
237: to decide when there have been ``I/O errors'' should be rechecked.
238:
239: "no such command from open/visual" -- This confused me in my first
240: few days of using the editor, when I didn't understand that one
241: couldn't use i and a (in either their vi or ex senses) from the bottom
242: line of vi. A message "i -- no such command from open/visual"
243: was perplexing because I knew that "i" was indeed a vi command.
244: Perhaps it should say "no such command from open/visual bottom line".
245:
246: MISCELLANEOUS PROBLEMS
247:
248: In ex search and replacement patterns, \\ is supposed to represent
249: a real \-character, but something goes wrong when this occurs
250: at the end of a global command. E.g., though
251: :s/^/\\
252: works OK (in vi or ex), the variant
253: :.g/^/s//\\
254: definitely does not. In vi it turns everything off, in ex it seems to
255: behave as though there were just a single \, and in a scriptfile,
256: it -- does something still different, which you can discover if you
257: don't know!
258:
259: The Ex Reference Manual says, ``For sanity with use from within
260: visual mode, ex ignores a ":" preceding any command.'' But it
261: ignores it in the wrong place! -- not at the beginning of the
262: command line, but just before the command letter itself. I.e.,
263: it accepts 1,3:s/^/ /, but not :1,3s/^/ /.
264:
265: SUGGESTIONS FOR MINOR ADDED CAPABILITIES
266:
267: In a multiline substitute command with the "c" option, when
268: each line is displayed one has three choices: y, n or break. There
269: are some further options that would be useful. One would be "p" --
270: at present, "p" can only be included on the command line, which
271: means that one has a choice between seeing the result of every
272: substitution or none. In practice, one would generally like to see
273: the results of the first few cases to make sure that the command one has
274: written does what one meant it to, and maybe a few tricky cases that
275: come up; but not every case! Another might be "u" -- to undo the last
276: case for which one gave a "y". Still another might be an option that
277: would mean ``undo the "c" option -- I see that the substitute command
278: is doing what I wanted, go ahead and finish it without me.''
279: In a command g/pattern/p, the pattern in question is occasionally
280: such that it takes a while to figure out where on the line it occurs.
281: For this purpose, an option that ``pointed out'' the instance of the
282: pattern, in the same manner that the pattern to be replaced is pointed
283: out in substitute command with option c, would be desirable.
284: When g/pattern/p gives more than a screenful of lines, it would
285: be nice to have it piped through the equivalent of ``more''.
286:
287: ex has the command line option "-", which ``is useful in processing
288: editor scripts''. But if one wants to use a script in the course of
289: an otherwise interactive editing session, it would be desirable to have
290: a corresponding resettable option ``:se -'' (or ``:se nofb'').
291:
292: In strings in pattern-searches, it would be useful to have
293: ^ and $ retain their ``magic'', so that /x[a$]/ could
294: search for all occurrences of x before an a or a newline.
295: (Of course, one would then have to decide whether /x[^y]/ should
296: include the case of x followed by a newline or not.)
297:
298: Just as ex allows the command :vi, so I think that vi should
299: have some bottom-line command equivalent to the regular-mode
300: command Q. When one has done some text-changing bottom-line
301: commands, and realizes one wants to go into ex, it can be time-
302: consuming to hit return and then Q, and wait for the screen to be
303: redrawn for vi before one gets the ex prompt.
304:
305: The option of putting several commands on one line, separated
306: by, "|" is particularly useful in the vi bottom-line mode, because
307: it avoids having the screen redrawn several times. It would be
308: useful to be able sometimes do the same thing with non-bottom-line
309: commands, e.g. in editing a troff file at a low baud rate on a dumb
310: terminal one might like to be able to do i\fI^]3Ea\fR^] without
311: watching the line get redrawn twice. Perhaps some key that would
312: cause any sequence of commands to be ``held'' until some complementary
313: key was hit would be useful.
314: It would also be desirable to have a sequence of commands that had
315: been given in this way available as one unit to be repeated by ``.'',
316: if desired.
317:
318: The parenthesis-matching facility with % might be extended
319: to match ` with ' and < with >.
320:
321: I will mention one facility that I discovered by surprize is
322: possessed by ed but not ex -- sequences such as \1 can be used
323: within ed search-patterns. E.g. (for the most trivial case)
324: /\(.\)\1/
325: will search for doubled letters.
326:
327:
328: DEBATABLE SUGGESTIONS
329: I will mention here some possible changes which have the
330: difficulty that they would change the meaning of existing commands,
331: so that it could be argued that the disadvantage of users having
332: to change their habits might outweigh the advantages.
333:
334: First, one might try to resolve, one way or another, the
335: contradiction between the count arguments taken by the join commands
336: in vi and ex: In ex, jN joins N+1 lines; in vi, NJ joins N lines
337: (except if N=1).
338:
339: Second, the movement commands tx and Tx of vi (x any character)
340: seem poorly defined. Just as fx will ignore the character on which
341: the cursor is presently sitting, even if it is an x, and move to the
342: next occurrence, so I would think that tx should ignore the character
343: immediately after the cursor, and Tx the character immediately before
344: the cursor. The point is that when one does Nfx, and finds that one
345: had failed to count one occurrence of x and fallen short of where one
346: wanted to go, one can hit ; and get there. Likewise, on doing Ntx
347: and finding one has fallen short, one should be able to hit ; and get
348: to the the next occurrence; but at present, hitting ; leaves
349: the cursor in the same position; one must hit ``2;'' to get any
350: further. In effect, Ntx is presently defined as Nfxh; I am
351: suggesting that it be defined as lNfxh.
352:
353: The sequences cw, dw and yw are presently violations of the
354: principle that c[movement], d[movement] and y[movement] change,
355: delete, or yank everything from the current cursor position through
356: the endpoint of the movement command. cw does what one would expect of
357: ce (in fact, they seem to be synonyms), while there is no way to get
358: the effect which cw would have if it were treated ``consistently''.
359: (E.g., if I have a line beginning ``And if'', and I want to change it
360: to ``If'', I cannot just put the cursor on the A and hit cwI^].) dw
361: and yw delete up to the character immediately before the point to
362: which ``w'' would take the cursor. I would have to agree that this
363: behavior of dw and yw is more useful than that which a literal
364: interpretation of the movement rule would lead to; but perhaps it
365: would become still more useful if when applied to the last word on
366: a line, it deleted or yanked the space immediately before the word
367: along with the word... . On the other hand, one could argue for
368: making a distinction between cw and ce.
369:
370: Though I see the motivation for the above definitions,
371: I see no sensible reason why Y should be equivalent to yy, when
372: C and D are equivalent to c$ and d$. I would vote for changing
373: Y to mean y$.
374:
375: RADICAL SUGGESTIONS
376:
377: Is there any reason for maintaining the distinction between
378: the ``:'' state of vi, and ex itself? At present, there are
379: relative advantages that lead one to choose to go into one or the
380: other for a given operation: From the vi-: state, it is easier
381: to return to the regular vi state; from ex, one has a more powerful
382: range of commands; and it is easier to give a series of commands
383: because each carriage-return gives one a new prompt. My suggestion
384: is that from vi, ``:'' should carry you directly to ex, and when you
385: are in ex, carriage-return (^M) after a command should give you a new
386: prompt, while ^] should put you into vi. Conceivably, things might be
387: simplified even further, and carriage return rather than : could
388: be the key that would carry one from the regular mode of vi into ex:
389:
390: .-------. .-------.
391: .-------. a,i... | basic | ^M | |
392: | vi |<------ | |----->| ex |<---.
393: | insert| | vi | | | |^M
394: | mode | ------>| |<-----| mode | ---'
395: `-------' ^] | mode | ^] | |
396: `-------' `-------'
397:
398: (Of course, ^M presently has a meaning in vi, but
399: it has a synonym +.) Clearly, there would also be no need for a
400: special "Hit return to continue" state.
401: I have not distinguished vi and open in the above diagram.
402: My idea here is that ^] would actually return you to either vi
403: or open, whichever you had last been in, and that to switch
404: to the other, you could enter ex and type vi^] or o^] respectively.
405: (Or you could type vi^M, respectively o^M, and further ex commands,
406: and the mode would be saved for the next time you hit a ^].) Or
407: alternatively, these could be made settable options: se visual
408: respectively se novisual.
409: Having gotten used to the editor as it now exists, I admit that
410: I feel uneasy about the above idea -- the sense of knowing that
411: I am ``still in vi'' when I hit :, and not that ``other land'' of ex,
412: represents a kind of of orientation that it is disconcerting
413: to abandon. But I can't see any logical disadvantage in making
414: such a change. Can you? Certainly, there would be things that
415: would have to be thought out, such as what happens to bottom-line
416: vi pattern-searches. My thought would be that ``/'' from vi should
417: give :/ (i.e., put one in ex at the start of a pattern-search),
418: and ^] after a pattern-search should put one into vi at the appropriate
419: character on the line, in contrast to ^M after a pattern search,
420: which would leave one in ex at the appropriate line. In general,
421: I think such changes would lead to greater simplicity and learnability
422: of the editor.
423: I would also hope that excursions between vi and ex and back
424: could be allowed in scriptfiles. It might also be desirable for
425: ex to have, in addition to a concept of ``current line'', one of
426: ``current cursor position''... .
427:
428: Well, on to another subject. One of the inconveniences I
429: found very vexing when first learning to use the editor was that
430: when in either vi insert mode, or ex/vi-bottom-line, it was very hard
431: to edit what I was doing. Within insert mode the only ``editing''
432: I could do, without escaping, was with the three operations ^H,
433: ^W and the kill character. And on a slow line with a dumb terminal,
434: escaping to make changes could be very time-consuming because large
435: parts of the screen would insist on being redrawn. Perhaps some
436: other control-character could serve as
437: a modified escape, that allowed one to edit what one had entered
438: in the current insertion without having everything below it redrawn,
439: and then return to it. Obviously, if carried to its logical
440: limit this idea could lead to ridiculous nests of
441: editing operations; but there would be no need to carry it to its
442: logical limit.
443: Anyway, the problem of editing ex-style commands
444: was even worse, because there was no way to ``escape and
445: revise''. I eventually learned enough to realize that the solution
446: was to edit complicated commands in another file and source it.
447: But it is sometimes very useful to have the text on which the
448: commands are to act in front of you when composing them (e.g., you can
449: yank and modify various pieces), which led to the variant of writing
450: command lines within the file I was editing, and then writing
451: those lines into another file and sourcing that, without ever leaving
452: the current file. But this is distracting to deal with
453: when concentrating on the editing task itself, which led me
454: to divise a scriptfile which would handle the writing-to-another-file-
455: and-sourcing for me. Or actually, several such files: One for
456: single-line commands to be used essentially once; one for single-line
457: commands that I would want to use on the same file during various
458: editing sessions, and so would want to keep available in that
459: file, and one for multi-line commands (to be used once). When
460: I first got the idea, I thought one scriptfile would be enough, and
461: I would call it ``do'', so that the command to execute a script I
462: had written in a file I was editing would be ``:so do''. The
463: file it would write to and source would be ``do.again'', so that
464: if I wanted to reuse it, I could ``:so do.again''. When I realized
465: the need for several versions, ``do'' became a directory. Here,
466: for your amusement, are the three files. (Re the lines ``se prompt'',
467: cf. my comment on that under PROBLEMS WITH SOURCE etc.):
468:
469: do/1 (for 1-time use of 1-line commands)
470: .w! ~/do/again
471: d
472: so #
473: se prompt
474:
475: do/1+ (like above, without deleting the command)
476: .w! ~/do/again
477: so #
478: se prompt
479:
480: do/: (to use this, write a multi-line command script, put : at
481: the beginning of the first line, put the cursor on the last
482: line of the script, and then source the following:)
483: ?^:?s/:/
484: ,''w! ~/do/again
485: ,''d
486: so #
487: se prompt
488:
489: (I also created another version to use in case the script had
490: to have an internal line beginning with ``:'', so that this couldn't
491: unambiguously mark the beginning of the script. This used
492: a line which explicitly specified the address-range of the script.
493: But I have never had a need for it, so I will not bother you with it.)
494: Finally, having gotten an account on a machine with a version 3
495: editor recently, I have divised still another way of doing this. I
496: have put in my EXINIT the command
497:
498: 'map ^A "ayy:@a^M'
499:
500: and now, gratifyingly, the single stroke ^A has essentially the effect
501: of ``:so do/1+'' -- except for the restrictions to which vi ``map''
502: commands are subject. But I've only been using this for a
503: couple of weeks; so I have yet to learn how chafing those restrictions
504: will or won't be.
505: Anyway, it might be worth thinking about whether some of these
506: things that I've done with macros should be incorporated in some form
507: into the editor itself; or else whether these macros might be written
508: up in the documentation (or some tutorials) on the editor.
509:
510: Next subject: Complicated pattern-searches in long files
511: can be time-consuming. I have seen the point mentioned
512: that if a pattern-description can be begun with "^",
513: this can speed up the search -- since the pattern-comparisons need
514: only be begun at beginnings of lines. In some cases, this might
515: not be possible, but the user might be aware of some other
516: character or character-sequence in the search-pattern
517: that will occur relatively rarely in the file. In such cases it would
518: be desirable if the user could specify one spot from which the pattern
519: search should start, working forward and backward from there, to
520: minimize false starts. E.g., if for some reason one wants to
521: delete every word containing the letter m, the script
522: %s/[^ ]*m[^ ]*//
523: would become much less time-consuming if one could mark the point
524: at which to begin, say writing
525: %s/[^ ]*\!m[^ ]*//
526: so as to instruct the editor to search for m's, and each time
527: one was found, to find the longest possible strings of non-space
528: characters before and after it, and delete these. (This is a silly
529: example, but I think the idea is clear.)
530:
531: Something that I've seriously felt the need for is the
532: capability of searching for lines that satisfy more than one
533: condition. If one just wants to locate such lines, one can
534: of course leave the editor and do a pipeline of two or
535: more greps; but it would be nice to be able to perform global
536: commands on such lines.
537:
538: Finally, any possibility of introducing the capability of searching
539: for patterns including embedded newlines, a la sed? Multiple windows,
540: a la emacs?
541:
542: ADDENDA
543: I logged in this morning on an adm3a at 300 baud to go over this
544: letter once more before sending it, and ran into another bug! I had
545: done 15^D to get a large scroll despite the low speed, and at one point
546: I saw a line with a typo scrolling up. So I noted its line-number, 402
547: and without waiting for the screen to stop moving typed something like
548: 402Gfsrd. What happened was that the change was made on line 407 rather
549: than 402 -- presumably the cursor was sent to where 402 had been when
550: the command was received... .
551: Editing this letter this morning reminded me of another feature I
552: have thought would be desirable for editing on dumb terminals at low
553: speeds: An option that would cause lines read from a file or typed
554: in at the bottom of the screen to appear double spaced, with @ signs
555: @
556: between them, such as one gets when one deletes a line on such a
557: @
558: terminal. (I have faked this effect here, though the fake will not be
559: @
560: very successful if you have se nu or se list on.) The point is that
561: @
562: editing operations that presently cause painfully slow screen-redrawings
563: would simply put material in in place of these fillers -- as happens
564: now when one is lucky enough to be adding material just above a place
565: where material was previously deleted.
566:
567: - * - * - * - * - * -
568:
569: I hope you've found some things of interest in this hodgepodge.
570:
571: Yours,
572: George (gbergman@brahms)
573:
574: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
575: 23/7/83, about 8PM
576:
577: Maybe thinking about the editor while writing my previous
578: ``note'' to you has made me more conscious of these things,
579: but for some reason, I've discovered several more peculiarities of
580: the the Version 3.7 editor today!
581:
582: First, the abbreviation feature has a strange bug (feature?)
583: involving the backslash: If some string X is the abbreviation
584: for a string Y, and if X is typed (following a space etc)
585: immediately followed by a \ and another character c, the
586: result is not Y\c by cY\. The case where I discovered this
587: was a doubly complicated one: I had an abbreviation of
588: the form
589: :ab x x\yZ
590: where x and y were characters and Z was a string of characters.
591: So when I typed x, it presumably first expanded it as x\yZ,
592: then performed the transformation I just described on the x\y
593: turning it into yx\yZ\, and thus giving the result yx\yZ\Z.
594: This turns out to be one of the cases that can't be unmapped
595: without doing :una ^Vx. Further, I just tried a similar case
596: with x replaced by a string of more than one character
597: (namely, :ab if if\pq) and I find I can't unmap that at all.
598: I also find that an abbreviated string containing | (which
599: must be inserted using ^V|, of course) is difficult to unmap.
600:
601: Second, some peculiarities about where the cursor ends
602: up after a yank. If the yank involved a forward movement,
603: the cursor stays where it is, which is the beginning
604: of the yanked segment. If the yank involves a backwards
605: movement, the place where the cursor originally was is not
606: the same as the beginning of the yanked segment, and there
607: seems to be some confusion as to which principle is followed:
608: y- or yk moves the cursor up, while yb leaves it fixed.
609: Unfortunately, there is a snake in the grass with yb: If
610: you hit p after it, the yanked word will not appear after
611: the position where the cursor has remained, but
612: after the position to which it would have gone if it had moved
613: to the beginning of the yanked segment! Likewise if you
614: you hit an x... .
615: (You have no idea how much trouble I'm
616: having with those "if"'s. Of course, I could quit the editor
617: and come back in, and I would lose that crazy abbreviation
618: that way.)
619:
620: I also notice that if the cursor is at the end of a word
621: or between words, 2e behaves the same as e!
622:
623: Finally, I note that d^, when the cursor is before the first
624: nonwhite character, is another exception to the principle that
625: d[motion] deletes everything through the endpoint of [motion].
626: Similarly with c^ and y^.
627:
628: - *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *- *
629: discovered next day (not yet sent):
630:
631: error with yb does not just concern p and x: any command is
632: executed as though cursor is at destination of backward in-line
633: yank.
634:
635: N^B does not work consistently? (Not on a medium-length file in Kim)
636:
637: Can get endless-loop mapping if abbreviation forms word within
638: abbreviated. E.g. :ab x ( x )
639: ``word'' must be delimited on left by space, tab,
640: newline, start-of-insert; on right by any punctuation. Why
641: special ``no tail recursion'' rule?
642: Things like that ``if'' abbreviation can be undone using
643: :una i^Vf!
644:
645: Mention desirability of Np
646:
647: copies sent to ralph@ucbarpa, lindahl@topaz 25/7/83
648:
649: From gbergman@UCBCARTAN Mon Aug 1 14:19:27 1983
650: Date: 1 Aug 83 14:14:06 PDT (Mon)
651: From: gbergman@UCBCARTAN (George Mark Bergman)
652: Subject: Re: editor
653: Message-Id: <[email protected]>
654: Received: by UCBCARTAN.ARPA (3.342/3.7)
655: id AA00627; 1 Aug 83 14:14:06 PDT (Mon)
656: Received: from UCBCARTAN.ARPA by UCBERNIE.ARPA (3.336/3.7)
657: id AA19324; 1 Aug 83 14:19:12 PDT (Mon)
658: To: mckusick@UCBERNIE
659: Status: R
660:
661: Here's Mark Horton's reply to my letter on bugs
662:
663: >From [email protected] Thu Jul 28 14:38:55 1983
664:
665: Sorry this has taken so long, but your note was too long to digest
666: in the cracks between the other stuff I do. Anyway, you've clearly
667: put a great deal of thought into this, and I appreciate your input.
668: I'll reply individually to your thoughts, and keep them on file
669: for use (someday) when vi gets rewritten. Some of them are just
670: plain bugs that ought to be fixed soon anyway.
671:
672: PROBLEMS WITH COUNTS
673:
674: The most gross case of misbehavior is that of N^B!
675: The effect is to redraw the screen 23N-44 lines further advanced.
676: (Probably the numbers depend on the screen-size of the terminal;
677: this is on a Z19, using termcap h19u.) When N=1, this does indeed
678: move you a screenful backward, but for higher N it moves the window
679: forward some amount! Further, whatever controls are supposed to
680: monitor whether the command would land one at an acceptable line-
681: number seem to have a different idea of what it is doing: If you
682: aren't already familiar with these weird effects, try setting the
683: cursor near the end of a file that is more than 4 screenfuls long,
684: and hitting 3^B. (You might then try an insert at the place you get
685: to, and a :f^] .)
686: This is a known bug, and was fixed in 3.8. The count is supposed to subtract
687: (LINES-1)*N from the line number, but there's + that should be a -, so it
688: goes forward instead. The check is correct, so it's possible to go off
689: the end of the buffer.
690: N/pattern/ would be useful, but is not allowed.
691: N/pattern/ resets the window size (silly but true) to N.
692: ND would be a natural synonym for dN$, by analogy with NC for cN$,
693: but it doesn't work that way; it just ignores the N.
694: Finally, if N is precisely the number of lines
695: from the current line to the end of the file, N$ will still correctly
696: carry one to the last character of the file, but cN$, NC, dN$ and yN$
697: refuse to do anything! (NY does work, not being a synonym for yN$.)
698: The failure of NC is particularly annoying; often when I am composing
699: something, I go back to somewhere in the middle of the next-to-
700: last line, say, and want to rewrite the rest of the sentence;
701: 2cc would kill not only the part I want to rewrite but also the OK
702: beginning of the line, and 2C or 2c$ won't work. I realize that I
703: could get around this by keeping an empty line at the end of the file,
704: but that should not be necessary.
705: While you're making valid observations here, are you aware that you can delete
706: the current sentence with d} ? I think that's what you really want.
707:
708:
709: PROBLEMS REGARDING SOURCE, MACROS, MAPPINGS
710: These are enormously useful, but seem to have all kinds of hidden
711: restrictions.
712:
713: The Appendix to the Ex Reference Manual, "List of Changes from
714: Version 3.5 to Version 3.6" says ``A bug which prevented the source
715: command from working...from visual has been fixed''. It is true that
716: one can now use :so from vi, but it still has a bug: When
717: the scriptfile invoked contains a global command
718: and some other command(s) after it, everything after the first global
719: command is ignored. The same appears to be true of scripts in named
720: buffers invoked from vi-bottom-line by @x.
721: Sounds like a bug.
722:
723: (It is, perhaps, unexpected that one can invoke scripts with
724: multiline commands using @x from vi's bottom-line at all, since such
725: commands will not work if typed on vi's bottom line directly.
726: A script like
727: s/$/a\
728: b
729: invoked as @x will indeed work. But strangely, if one tries to
730: invoke from the regular mode of vi the script
731: :s/$/a\
732: b
733: by putting it in buffer x and doing @x, only the first line
734: will take effect.)
735: In 3.7 (or 3.8, I'm not sure), you can say
736: :s/$/a^V^Mb
737: to get a newline on the RHS. Of course, this doesn't mean there isn't
738: a bug in scripts.
739:
740: Another serious restriction is that the command ``vi'' appears to
741: be ignored in sourced ex-scripts, and though the command Q in macros of
742: various flavors in vi (mapped characters, map!ed characters that contain
743: ``...^V^[...Q...''; @x scripts) does take one into ex, any ex
744: commands after it are ignored.
745: The internals of getting a character from the tty are completely different
746: in ex and vi. Pushing input for one doesn't affect the other. So there
747: isn't much hope of changing this situation.
748:
749: I assume you are aware of whatever restrictions lead to the
750: error-message ``Cannot yank inside global/macro'', since you must
751: have written it, though ``inside'' seems to here have the peculiar
752: meaning ``after a text-changing operation of the macro.''
753: The error-message ``Can't undo in global commands'' is more
754: mysterious, since I get it when I have a global command after
755: a text-changing command in an @x script (though not in a sourced file).
756: Anyway, the fewer such restrictions these operations were subject
757: to, the more useful they would be!
758: It's the way undo is done - the text for undo is saved in the "last deleted"
759: buffer, and yank puts text there too. Couple this with the fact that globals
760: and macros can be undone as a unit (they save their state before the first change)
761: and you'll see that the two notions can't coexist. Of course, you can always
762: yank into a named buffer, even inside a macro.
763:
764: Although nested source commands are allowed (and I find them
765: useful), they leave the editor in a ``noprompt'' state. This
766: can be gotten around by including ``se prompt'' as a line in the
767: outermost scriptfile, but I would hope the problem causing it could
768: be cured.
769: Bug, I guess.
770:
771: When one tries to ``:unmap!'' a ``:map!'' command whose
772: right-hand-side begins with ^H (entered as ^V^H, of course), one
773: gets the message ``That macro wasn't mapped''. (One can get around
774: this by using :unmap! ^V[character].)
775: Bug, I guess.
776:
777: Certain termcaps apparently produce automatic mappings, which
778: unfortunately may interfere with useful vi commands. In particular,
779: on a tvi, ^L gets mapped to a movement command, which makes it
780: unavailable for redrawing the screen, unless unmapped.
781: Well, there's no way for vi to tell the difference between ^L that the
782: user typed as ^L and ^L that the user typed as right arrow. However, there
783: are a number of terminals that are upward compatible with the adm3a and use
784: ^L for right arrow. Vi has a special case for these built in - if the
785: terminal has insert/delete line, and ^L is right arrow, then ^R will redraw
786: the screen.
787:
788:
789: PROBLEMS WITH DIAGNOSTICS
790:
791: "Hit return to continue" -- It took me a long time to realize that
792: when I got this diagnostic there was an alternative to hitting
793: return. I suggest it be reworded
794: "Hit Return or :"
795: However, the behavior of the editor when this diagnostic is given
796: seems to be inconsistent. In particular, when the last of a serious
797: of commands is
798: :e otherfile
799: and I get "Hit return to continue", then hitting : usually
800: has no different effect from hitting return (or any other
801: key), namely the screen is redrawn; yet I think that sometimes
802: in this situation it has brought me directly to the bottom line
803: as desired. Very confusing.
804: Would it be possible to have other alternatives than : and return
805: available, such as /pattern ? Or, more simply, when one would presently
806: be given the diagnostic "Hit return to continue", why not just put the
807: editor into the state it would have if one then hit :, since one would
808: then still have the option of hitting return and getting into vi
809: proper, but it would not require the extra keystroke : to
810: begin a bottom-line command, nor would one go through the frequent
811: frustrating experience of absentmindedly starting to write a
812: bottom-line command, or a pattern-search, and then having to wait
813: while the screen was redrawn because one had hit a key other than :.
814: There is an internal difference between "ex mode" (where it doesn't keep a
815: screen image) and "vi mode" (where it does). Any : command that outputs more
816: than 1 line puts you into "ex mode", requiring "hit return to continue"
817: before clearing the screen and redrawing it with known stuff. There is no
818: hope of this changing - the code is too spaghetti-ized already. In the worst
819: case, the ! command scribbles on the screen and there's nothing vi can do
820: to know what the command did.
821:
822: What you really want is for vi to check for typeahead and avert the refresh
823: when it's going to have to redo it anyway. My curses does this, but I simply
824: don't have time to rewrite vi to use it. This would also solve the other
825: problem you mention where macros ought to redraw the screen only once.
826: If you saw the insides of the code, you'd see it needs a rewrite to do this.
827: Each command knows the screen things to do to fix the screen.
828:
829: What most of us do is hit DEL when the screen is being drawn with something
830: we don't want to see. This aborts the update and leaves junk on the screen.
831: Then you move the cursor where you want it, and if the screen is still
832: garbaged, hit ^L. Ugly but effective.
833:
834: "Using open mode"
835: Again, it took me a long time to learn that when I tried to enter
836: vi and got this diagnostic, it meant that the system had somehow
837: lost the termcap for the terminal I was on, and that I would have
838: to do something to get the correct termcap into the environment.
839: Till I realized this, I generally ended up either struggling along
840: frustrated in open mode, or logging out and logging back in. I suggest
841: that when someone calls for vi and the termcap is not appropriate,
842: the editor should not be invoked in any form, but instead, a message
843: be given such as:
844: ``Your environment does not show a termcap entry permitting
845: the use of the visual editor. If you are working on a terminal not
846: supporting vi (in particular, a device with no addressable cursor),
847: you may enter one of the other modes of the editor with the command
848: "open filename" or "ex filename". If you are working on a terminal
849: that should support vi, your environment entries are incorrect and
850: should be corrected. They presently show:
851: TERM=....
852: TERMCAP=....
853: If you know the correct name or abbreviation for your terminal-
854: type, type it at the end of the next line; if not hit return:
855: % setenv TERM ''
856: If the user typed an acceptable terminal-name, the message would
857: continue, telling how to get the appropriate termcap. If the user
858: instead typed return, the message would ask him or her to type the
859: name of the manufacturer shown on the terminal, not
860: worrying about upper/lower-case distinctions, and a list of possible
861: terminal names and abbreviations would be given... . This whole
862: program would not be part of the editor, so there would
863: be no problem of space within the existing crowded confines of
864: the editor code.
865: This, of course, doesn't belong in vi, but in login or tset. In fact,
866: tset is much friendlier these days. Vi will print a better diagnostic
867: if it knows you're on a "generic" terminal type such as "dialup" - in
868: terminfo there's a capability to indicate this, so it can print
869: I don't know what kind of terminal you have - all I have is "patchboard"
870: 3.7 can't do this because it can't tell the difference between a generic
871: terminal and a hardcopy terminal.
872:
873: "No such file or directory" -- I think there should be a distinction
874: between these two cases, because of the important distinction in the
875: consequences when the user tries to quit the editor:
876: The kernel doesn't distinguish, so it's hard for vi to. This is just a perror
877: string.
878: If the directory exists, the file is created, but
879: if not, the results are more complicated -- I seem to recall on one
880: occasion simply losing what I had written on my second try
881: at quitting; though I just now did an experiment and this time
882: repeated ZZ's and :x's simply gave repeated error messages.
883: Well, if it can't be reproduced, it doesn't stand much chance of getting fixed.
884: (Not that it would if you could reproduce it, of course.)
885:
886: "File already exists..." -- The ``List of changes from 3.5 to 3.6'' says
887: ``If you get I/O errors, the file is considered "not edited"... .''
888: I presume that this correction is somehow the cause of the fact that
889: I frequently get the above message when trying to leave the editor
890: on a machine with version 3.7, and have to use
891: :w! %|q
892: Ick! Most of us just type
893: :wq!
894: which is equivalent and much shorter.
895: to exit. But I've never seen any evidence that there were I/O errors;
896: it mainly seems to happen when I've written some lines to another
897: file in the process of editing. So the criteria the editor is using
898: to decide when there have been ``I/O errors'' should be rechecked.
899: Actually, if you get ANY error (e.g. :foo<cr>) it resets the "buffer modified"
900: condition. I have finally been convinced this is not right. For a while, I
901: considered it a necessary evil in case your /tmp/Ex* file got an I/O error.
902:
903: "no such command from open/visual" -- This confused me in my first
904: few days of using the editor, when I didn't understand that one
905: couldn't use i and a (in either their vi or ex senses) from the bottom
906: line of vi. A message "i -- no such command from open/visual"
907: was perplexing because I knew that "i" was indeed a vi command.
908: Perhaps it should say "no such command from open/visual bottom line".
909: OK.
910:
911: MISCELLANEOUS PROBLEMS
912:
913: In ex search and replacement patterns, \\ is supposed to represent
914: a real \-character, but something goes wrong when this occurs
915: at the end of a global command. E.g., though
916: :s/^/\\
917: works OK (in vi or ex), the variant
918: :.g/^/s//\\
919: definitely does not. In vi it turns everything off, in ex it seems to
920: behave as though there were just a single \, and in a scriptfile,
921: it -- does something still different, which you can discover if you
922: don't know!
923: Backslash is special at the end of a line in global. You need more \\'s.
924:
925: The Ex Reference Manual says, ``For sanity with use from within
926: visual mode, ex ignores a ":" preceding any command.'' But it
927: ignores it in the wrong place! -- not at the beginning of the
928: command line, but just before the command letter itself. I.e.,
929: it accepts 1,3:s/^/ /, but not :1,3s/^/ /.
930: Hmm.
931:
932: SUGGESTIONS FOR MINOR ADDED CAPABILITIES
933:
934: In a multiline substitute command with the "c" option, when
935: each line is displayed one has three choices: y, n or break. There
936: are some further options that would be useful. One would be "p" --
937: at present, "p" can only be included on the command line, which
938: means that one has a choice between seeing the result of every
939: substitution or none. In practice, one would generally like to see
940: the results of the first few cases to make sure that the command one has
941: written does what one meant it to, and maybe a few tricky cases that
942: come up; but not every case! Another might be "u" -- to undo the last
943: case for which one gave a "y". Still another might be an option that
944: would mean ``undo the "c" option -- I see that the substitute command
945: is doing what I wanted, go ahead and finish it without me.''
946: If I were going to do something this involved (I didn't know anybody used the
947: c option anymore - most people use "n" and "." in vi) I would do query-replace
948: ala EMACS right.
949: In a command g/pattern/p, the pattern in question is occasionally
950: such that it takes a while to figure out where on the line it occurs.
951: For this purpose, an option that ``pointed out'' the instance of the
952: pattern, in the same manner that the pattern to be replaced is pointed
953: out in substitute command with option c, would be desirable.
954: When g/pattern/p gives more than a screenful of lines, it would
955: be nice to have it piped through the equivalent of ``more''.
956: Nice but unlikely. Unless, of course, you have page mode in your tty driver,
957: like we do, in which case you get it for free.
958:
959: ex has the command line option "-", which ``is useful in processing
960: editor scripts''. But if one wants to use a script in the course of
961: an otherwise interactive editing session, it would be desirable to have
962: a corresponding resettable option ``:se -'' (or ``:se nofb'').
963: Seems like a good idea.
964:
965: In strings in pattern-searches, it would be useful to have
966: ^ and $ retain their ``magic'', so that /x[a$]/ could
967: search for all occurrences of x before an a or a newline.
968: (Of course, one would then have to decide whether /x[^y]/ should
969: include the case of x followed by a newline or not.)
970: This sounds pretty hard to do.
971:
972: Just as ex allows the command :vi, so I think that vi should
973: have some bottom-line command equivalent to the regular-mode
974: command Q. When one has done some text-changing bottom-line
975: commands, and realizes one wants to go into ex, it can be time-
976: consuming to hit return and then Q, and wait for the screen to be
977: redrawn for vi before one gets the ex prompt.
978: This would be ugly, since the ex command routine would have to return an
979: indication to the vi routine to exit back to the top level ex command.
980: But I suppose it could be done.
981:
982: The option of putting several commands on one line, separated
983: by, "|" is particularly useful in the vi bottom-line mode, because
984: it avoids having the screen redrawn several times. It would be
985: useful to be able sometimes do the same thing with non-bottom-line
986: commands, e.g. in editing a troff file at a low baud rate on a dumb
987: terminal one might like to be able to do i\fI^]3Ea\fR^] without
988: watching the line get redrawn twice. Perhaps some key that would
989: cause any sequence of commands to be ``held'' until some complementary
990: key was hit would be useful.
991: It would also be desirable to have a sequence of commands that had
992: been given in this way available as one unit to be repeated by ``.'',
993: if desired.
994: See above. And get yourself a terminal with insert/delete char!
995:
996: The parenthesis-matching facility with % might be extended
997: to match ` with ' and < with >.
998: OK.
999:
1000: I will mention one facility that I discovered by surprize is
1001: possessed by ed but not ex -- sequences such as \1 can be used
1002: within ed search-patterns. E.g. (for the most trivial case)
1003: /\(.\)\1/
1004: will search for doubled letters.
1005: This surprises me.
1006:
1007:
1008: DEBATABLE SUGGESTIONS
1009: I will mention here some possible changes which have the
1010: difficulty that they would change the meaning of existing commands,
1011: so that it could be argued that the disadvantage of users having
1012: to change their habits might outweigh the advantages.
1013:
1014: First, one might try to resolve, one way or another, the
1015: contradiction between the count arguments taken by the join commands
1016: in vi and ex: In ex, jN joins N+1 lines; in vi, NJ joins N lines
1017: (except if N=1).
1018: Yeah, ex should be N, not N+1.
1019:
1020: Second, the movement commands tx and Tx of vi (x any character)
1021: seem poorly defined. Just as fx will ignore the character on which
1022: the cursor is presently sitting, even if it is an x, and move to the
1023: next occurrence, so I would think that tx should ignore the character
1024: immediately after the cursor, and Tx the character immediately before
1025: the cursor. The point is that when one does Nfx, and finds that one
1026: had failed to count one occurrence of x and fallen short of where one
1027: wanted to go, one can hit ; and get there. Likewise, on doing Ntx
1028: and finding one has fallen short, one should be able to hit ; and get
1029: to the the next occurrence; but at present, hitting ; leaves
1030: the cursor in the same position; one must hit ``2;'' to get any
1031: further. In effect, Ntx is presently defined as Nfxh; I am
1032: suggesting that it be defined as lNfxh.
1033: Agreed.
1034:
1035: The sequences cw, dw and yw are presently violations of the
1036: principle that c[movement], d[movement] and y[movement] change,
1037: delete, or yank everything from the current cursor position through
1038: the endpoint of the movement command. cw does what one would expect of
1039: ce (in fact, they seem to be synonyms), while there is no way to get
1040: the effect which cw would have if it were treated ``consistently''.
1041: (E.g., if I have a line beginning ``And if'', and I want to change it
1042: to ``If'', I cannot just put the cursor on the A and hit cwI^].) dw
1043: and yw delete up to the character immediately before the point to
1044: which ``w'' would take the cursor. I would have to agree that this
1045: behavior of dw and yw is more useful than that which a literal
1046: interpretation of the movement rule would lead to; but perhaps it
1047: would become still more useful if when applied to the last word on
1048: a line, it deleted or yanked the space immediately before the word
1049: along with the word... . On the other hand, one could argue for
1050: making a distinction between cw and ce.
1051: This is to make the user interface friendlier, and is a fact of life.
1052: If I wanted to change "And if" to "If", I'd type "dw~".
1053:
1054: Though I see the motivation for the above definitions,
1055: I see no sensible reason why Y should be equivalent to yy, when
1056: C and D are equivalent to c$ and d$. I would vote for changing
1057: Y to mean y$.
1058: The users wouldn't stand for such a change. Too many are used to it like it is.
1059: But you could always map it.
1060:
1061: RADICAL SUGGESTIONS
1062:
1063: Is there any reason for maintaining the distinction between
1064: the ``:'' state of vi, and ex itself? At present, there are
1065: relative advantages that lead one to choose to go into one or the
1066: other for a given operation: From the vi-: state, it is easier
1067: to return to the regular vi state; from ex, one has a more powerful
1068: range of commands; and it is easier to give a series of commands
1069: because each carriage-return gives one a new prompt. My suggestion
1070: is that from vi, ``:'' should carry you directly to ex, and when you
1071: are in ex, carriage-return (^M) after a command should give you a new
1072: prompt, while ^] should put you into vi. Conceivably, things might be
1073: simplified even further, and carriage return rather than : could
1074: be the key that would carry one from the regular mode of vi into ex:
1075: The basic problem here is that if : put you into ex mode, you'd have to redraw
1076: the screen when you hit return. The motivation for : commands is that you
1077: don't have to go through a conceptually hard mode change and wait for a
1078: screen redraw.
1079:
1080: .-------. .-------.
1081: .-------. a,i... | basic | ^M | |
1082: | vi |<------ | |----->| ex |<---.
1083: | insert| | vi | | | |^M
1084: | mode | ------>| |<-----| mode | ---'
1085: `-------' ^] | mode | ^] | |
1086: `-------' `-------'
1087:
1088: (Of course, ^M presently has a meaning in vi, but
1089: it has a synonym +.) Clearly, there would also be no need for a
1090: special "Hit return to continue" state.
1091: I have not distinguished vi and open in the above diagram.
1092: My idea here is that ^] would actually return you to either vi
1093: or open, whichever you had last been in, and that to switch
1094: to the other, you could enter ex and type vi^] or o^] respectively.
1095: (Or you could type vi^M, respectively o^M, and further ex commands,
1096: and the mode would be saved for the next time you hit a ^].) Or
1097: alternatively, these could be made settable options: se visual
1098: respectively se novisual.
1099: Having gotten used to the editor as it now exists, I admit that
1100: I feel uneasy about the above idea -- the sense of knowing that
1101: I am ``still in vi'' when I hit :, and not that ``other land'' of ex,
1102: represents a kind of of orientation that it is disconcerting
1103: to abandon. But I can't see any logical disadvantage in making
1104: such a change. Can you? Certainly, there would be things that
1105: would have to be thought out, such as what happens to bottom-line
1106: vi pattern-searches. My thought would be that ``/'' from vi should
1107: give :/ (i.e., put one in ex at the start of a pattern-search),
1108: and ^] after a pattern-search should put one into vi at the appropriate
1109: character on the line, in contrast to ^M after a pattern search,
1110: which would leave one in ex at the appropriate line. In general,
1111: I think such changes would lead to greater simplicity and learnability
1112: of the editor.
1113: I would also hope that excursions between vi and ex and back
1114: could be allowed in scriptfiles. It might also be desirable for
1115: ex to have, in addition to a concept of ``current line'', one of
1116: ``current cursor position''... .
1117:
1118: Well, on to another subject. One of the inconveniences I
1119: found very vexing when first learning to use the editor was that
1120: when in either vi insert mode, or ex/vi-bottom-line, it was very hard
1121: to edit what I was doing. Within insert mode the only ``editing''
1122: I could do, without escaping, was with the three operations ^H,
1123: ^W and the kill character. And on a slow line with a dumb terminal,
1124: escaping to make changes could be very time-consuming because large
1125: parts of the screen would insist on being redrawn. Perhaps some
1126: other control-character could serve as
1127: a modified escape, that allowed one to edit what one had entered
1128: in the current insertion without having everything below it redrawn,
1129: and then return to it. Obviously, if carried to its logical
1130: limit this idea could lead to ridiculous nests of
1131: editing operations; but there would be no need to carry it to its
1132: logical limit.
1133: Why not just get a terminal with insert char? You're paying in performance
1134: for having an obsolete terminal.
1135: Anyway, the problem of editing ex-style commands
1136: was even worse, because there was no way to ``escape and
1137: revise''. I eventually learned enough to realize that the solution
1138: was to edit complicated commands in another file and source it.
1139: This is a standard complaint about a moded editor. It couldn't be fixed
1140: without taking away the property of ESC ending command lines. Besides,
1141: allowing editing on the bottom line would really break a lot of code.
1142: But it is sometimes very useful to have the text on which the
1143: commands are to act in front of you when composing them (e.g., you can
1144: yank and modify various pieces), which led to the variant of writing
1145: command lines within the file I was editing, and then writing
1146: those lines into another file and sourcing that, without ever leaving
1147: the current file. But this is distracting to deal with
1148: when concentrating on the editing task itself, which led me
1149: to divise a scriptfile which would handle the writing-to-another-file-
1150: and-sourcing for me. Or actually, several such files: One for
1151: single-line commands to be used essentially once; one for single-line
1152: commands that I would want to use on the same file during various
1153: editing sessions, and so would want to keep available in that
1154: file, and one for multi-line commands (to be used once). When
1155: I first got the idea, I thought one scriptfile would be enough, and
1156: I would call it ``do'', so that the command to execute a script I
1157: had written in a file I was editing would be ``:so do''. The
1158: file it would write to and source would be ``do.again'', so that
1159: if I wanted to reuse it, I could ``:so do.again''. When I realized
1160: the need for several versions, ``do'' became a directory. Here,
1161: for your amusement, are the three files. (Re the lines ``se prompt'',
1162: cf. my comment on that under PROBLEMS WITH SOURCE etc.):
1163:
1164: do/1 (for 1-time use of 1-line commands)
1165: .w! ~/do/again
1166: d
1167: so #
1168: se prompt
1169:
1170: do/1+ (like above, without deleting the command)
1171: .w! ~/do/again
1172: so #
1173: se prompt
1174:
1175: do/: (to use this, write a multi-line command script, put : at
1176: the beginning of the first line, put the cursor on the last
1177: line of the script, and then source the following:)
1178: ?^:?s/:/
1179: ,''w! ~/do/again
1180: ,''d
1181: so #
1182: se prompt
1183:
1184: (I also created another version to use in case the script had
1185: to have an internal line beginning with ``:'', so that this couldn't
1186: unambiguously mark the beginning of the script. This used
1187: a line which explicitly specified the address-range of the script.
1188: But I have never had a need for it, so I will not bother you with it.)
1189: Finally, having gotten an account on a machine with a version 3
1190: editor recently, I have divised still another way of doing this. I
1191: have put in my EXINIT the command
1192:
1193: 'map ^A "ayy:@a^M'
1194:
1195: and now, gratifyingly, the single stroke ^A has essentially the effect
1196: of ``:so do/1+'' -- except for the restrictions to which vi ``map''
1197: commands are subject. But I've only been using this for a
1198: couple of weeks; so I have yet to learn how chafing those restrictions
1199: will or won't be.
1200: Anyway, it might be worth thinking about whether some of these
1201: things that I've done with macros should be incorporated in some form
1202: into the editor itself; or else whether these macros might be written
1203: up in the documentation (or some tutorials) on the editor.
1204:
1205: Next subject: Complicated pattern-searches in long files
1206: can be time-consuming. I have seen the point mentioned
1207: that if a pattern-description can be begun with "^",
1208: this can speed up the search -- since the pattern-comparisons need
1209: only be begun at beginnings of lines. In some cases, this might
1210: not be possible, but the user might be aware of some other
1211: character or character-sequence in the search-pattern
1212: that will occur relatively rarely in the file. In such cases it would
1213: be desirable if the user could specify one spot from which the pattern
1214: search should start, working forward and backward from there, to
1215: minimize false starts. E.g., if for some reason one wants to
1216: delete every word containing the letter m, the script
1217: %s/[^ ]*m[^ ]*//
1218: would become much less time-consuming if one could mark the point
1219: at which to begin, say writing
1220: %s/[^ ]*\!m[^ ]*//
1221: so as to instruct the editor to search for m's, and each time
1222: one was found, to find the longest possible strings of non-space
1223: characters before and after it, and delete these. (This is a silly
1224: example, but I think the idea is clear.)
1225: Isn't worth doing - this is fast enough for most people in most cases.
1226:
1227: Something that I've seriously felt the need for is the
1228: capability of searching for lines that satisfy more than one
1229: condition. If one just wants to locate such lines, one can
1230: of course leave the editor and do a pipeline of two or
1231: more greps; but it would be nice to be able to perform global
1232: commands on such lines.
1233: You want the PWB "or" operator. This is hard to put in - their code
1234: is really convoluted.
1235:
1236: Finally, any possibility of introducing the capability of searching
1237: for patterns including embedded newlines, a la sed?
1238: Newlines aren't stored - the data structure is an array of lines.
1239: So this is nearly impossible.
1240: Multiple windows, a la emacs?
1241: Would be easy after a rewrite, but impossible with current code.
1242: What you really want is a window manager, anyway, most of the time.
1243:
1244: ADDENDA
1245: I logged in this morning on an adm3a at 300 baud to go over this
1246: letter once more before sending it, and ran into another bug! I had
1247: done 15^D to get a large scroll despite the low speed, and at one point
1248: I saw a line with a typo scrolling up. So I noted its line-number, 402
1249: and without waiting for the screen to stop moving typed something like
1250: 402Gfsrd. What happened was that the change was made on line 407 rather
1251: than 402 -- presumably the cursor was sent to where 402 had been when
1252: the command was received... .
1253: Knowing the internals of vi, I'd say this is impossible. It probably just
1254: screwed up your screen from line noise (or your terminal isn't truly full
1255: duplex), or you got the wrong line number.
1256: Editing this letter this morning reminded me of another feature I
1257: have thought would be desirable for editing on dumb terminals at low
1258: speeds: An option that would cause lines read from a file or typed
1259: in at the bottom of the screen to appear double spaced, with @ signs
1260: @
1261: between them, such as one gets when one deletes a line on such a
1262: @
1263: terminal. (I have faked this effect here, though the fake will not be
1264: @
1265: very successful if you have se nu or se list on.) The point is that
1266: @
1267: editing operations that presently cause painfully slow screen-redrawings
1268: would simply put material in in place of these fillers -- as happens
1269: now when one is lucky enough to be adding material just above a place
1270: where material was previously deleted.
1271: Again, it would cost less to buy a real terminal. You can get one for $500
1272: or so now from Falco or Liberty or Zenith.
1273:
1274: Thanks again for the input.
1275:
1276: Mark
1277:
1278:
1279: From gbergman@UCBCARTAN Fri Jul 29 16:07:10 1983
1280: Date: 29 Jul 83 16:02:06 PDT (Fri)
1281: From: gbergman@UCBCARTAN (George Mark Bergman)
1282: Subject: editor
1283: Message-Id: <[email protected]>
1284: Received: by UCBCARTAN.ARPA (3.342/3.7)
1285: id AA09635; 29 Jul 83 16:02:06 PDT (Fri)
1286: Received: from UCBCARTAN.ARPA by UCBERNIE.ARPA (3.336/3.7)
1287: id AA06658; 29 Jul 83 16:07:04 PDT (Fri)
1288: To: cc-03@ucbcory, danh@kim, lindahl@topaz, mckusick@ernie, ralph@ucbarpa
1289: Status: RO
1290:
1291: 29/7/83
1292: I got a reply from Horton: a copy of my (first) letter,
1293: annotated with comments that this should indeed be fixed, that
1294: would be impossible, etc.. I'll send a copy to anyone who'd
1295: like (or a copy of his comment on some specific bug they're
1296: interested in). Meanwhile, I'll send you my reply to him, since
1297: it discusses still more bugs and possible improvements.
1298:
1299: Dear Mark,
1300: Got your comments on my first letter! Did you get the second,
1301: shorter one? Glad to see that some things, at least, can be fixed.
1302: Robert has put version 3.9 on this machine and I'm using it.
1303: Using movement arrows within insert mode is amusing; though when there
1304: is documentation, there should be a warning to the user that these
1305: prevent ``u'' from undoing anything before those commands. But
1306: the first thing there needs to be documentation for is vedit! Is
1307: any being written?
1308: In your comment on ``Can't yank inside global/macro'' you said
1309: that one can, of course, always yank to a named buffer. I checked,
1310: in the case of @a scripts, and the answer is yes and no: The yank
1311: works, but one still gets that diagnostic, and anything else in the
1312: sequence of commands is aborted.
1313: And concerning the diagnostic ``Can't undo in global commands'' --
1314: I understand what you say about why one can't, but it still seems an
1315: unenlightening and perhaps inappropriate diagnostic to get when one has
1316: done @a and buffer a contains say
1317: x:g/foo/s//bar
1318: Here the initial ``x'', deleting the character the cursor was on when
1319: the command was given, creates the text-modified condition which,
1320: as I mention, seems to cause globals in @-scripts to give this
1321: diagnostic. I've just tested the above script -- several times,
1322: because I found it hard to believe what was happening -- and it did
1323: indeed give the diagnostic in question, but instead of replacing foo's
1324: with bar's, it replaced the first line containing a foo with a copy of
1325: the last line of the file! I leave it to you to figure that one out!
1326: (This is on version 3.9. Incidentally, I've used a true ^M in that
1327: script, so it is ready for you to try.)
1328:
1329: Further observations on some of the bugs I mentioned in my
1330: second letter: The business with yb is both more general and more
1331: complicated than I realized. The general fact seems to be that when
1332: one does a yank to a position earlier on the same line, the cursor does
1333: not move, but the editor thinks it has, so that any subsequent command,
1334: e.g. a movement, a delete, etc., has the effect that it would if it had
1335: been done with the cursor starting from the new position. The
1336: complication is that yanks to named buffers don't behave the same as
1337: simple yanks: They also leave the cursor unmoved, but what they actually
1338: yank into the buffer is the text from the cursor location to the end of
1339: the line; and whether they cause the editor to consider the cursor to
1340: be in a different location from where it really is seems to depend on
1341: the movement in question: with "ayNb, no, with "ayN|, yes (where N
1342: again stands for a positive integer). So what I called a snake in the
1343: grass seems to be a can of worms!
1344: In experimenting with this, incidentally, I've found that, while a
1345: put from a named buffer can be undone with u, if one attempts the
1346: command U, ``undo all changes made since coming onto this line'', only
1347: changes made since the last named-buffer-put are undone.
1348:
1349: I mentioned various abbreviations that were hard to unabbreviate,
1350: but could be done with the help of ^V -- but that I had found no way
1351: to undo
1352: :ab if if\pq
1353: To be precise, I had found that :una ^Vif, :una ^V^Vif, and
1354: :una ^Vif where each ^V represents two ^V's typed in, didn't work.
1355: I've finally found something that does: :una i^Vf.
1356:
1357: I find the diagnostic ``No tail recursion'' strange,
1358: since the occurrence of an abbreviation at the end of the item
1359: abbreviated shouldn't cause a recursive loop; while circumstances that
1360: do cause such a loop, namely the occurrence of the abbreviation within
1361: the item abbreviated, preceded by a space and followed by punctuation,
1362: are not censored, e.g. :ab x ( x ), or with more subtle effect,
1363: :ab x x sup 2.
1364: It seems that if one has :ab x word, then the abbreviation works
1365: when x is preceded by a beginning-of-insert, a space, a tab, or a
1366: newline, and followed by most any nonalphabetic character. For
1367: word-processing use, it would be natural to allow it to also be
1368: preceeded by (, ", `, [, perhaps even a user-specified set of
1369: characters.
1370:
1371: To my list of vi commands which I think should be able to take
1372: counts, add p and P. I often want to put in a large number of copies of
1373: one or more lines, as ``forms'' in which I will enter various kinds of
1374: additional data, and it would be convenient to be able to do compose
1375: such a line and then duplicate it the desired number of times all at
1376: once. What I currently do is produce a copy and then go
1377: yypk2yypk4yyp... till I have enough.
1378:
1379: Two more commands I think would be useful: (1) One which "puts" to
1380: the screen (in the sense of g/pattern/p, i.e. without affecting the
1381: buffer) the contents, or the first lines in cases that are longer than
1382: one line, of all nonempty buffers, named or numbered, with an
1383: indication, of course, of which each was. (Ideally one would like to
1384: be able to specify some subset of the buffers, whether one wants the
1385: first line, or everything, or some specified number of lines, etc..)
1386: (2) One which would show the script of the command stored to be used as
1387: ``.''. (And perhaps ditto with the last search pattern.)
1388: Oh, yes: it would also be nice to have a way to give commands
1389: without having them displace the one specified to be repeated by ``.'',
1390: e.g. if one wants to do a certain change time after time at various
1391: points in the file (using ``n'' and ``.'') but occasionally sees other
1392: changes to be made along the way. An alternative to the above would be
1393: a way to read the command stored to be used as ``.'' into a named
1394: buffer, so that one can give other commands and then return to
1395: that one. This would also allow one to reread the text of the command:
1396: useful if it isn't behaving as one meant it to.
1397:
1398: You might as well send any future mail to me here as
1399: gbergman@cartan -- I was using brahms while cartan's terminals were
1400: being moved but I'll probably be using cartan more from now on. But
1401: I'll check mail on both. (However, I'll be on vacation in New York
1402: State from the 3d to the 16th of August.)
1403: Best regards,
1404: George
1405:
1406: From gbergman@ucbcartan Fri Sep 23 13:57:06 1983
1407: Date: Fri, 23 Sep 83 13:53:36 PDT
1408: From: gbergman@ucbcartan (George Mark Bergman)
1409: Message-Id: <[email protected]>
1410: Received: by ucbcartan.ARPA (4.6/3.7)
1411: id AA02960; Fri, 23 Sep 83 13:53:36 PDT
1412: Received: from ucbcartan.ARPA by UCBERNIE.ARPA (3.336/3.7)
1413: id AA20684; 23 Sep 83 13:57:01 PDT (Fri)
1414: To: cc-03@ucbcory, danh@kim, lindahl@topaz, mckusick@ucbernie, ralph@ucbarpa
1415: Status: RO
1416:
1417: Latest letter on ex~vi to Horton:
1418:
1419: Dear Mark,
1420:
1421: I hope I can assume that after my long letter to which you
1422: replied, you did get my two shorter notes (one sent the same day,
1423: the other about a week later); and that you've simply been to busy
1424: to think about them or reply.
1425: However, since I have had bad experiences with Mail, I am worried
1426: that either you may never have gotten them or that you may have replied
1427: and your replies not reached me. I hope you can send me a one-liner to
1428: relieve my doubts.
1429:
1430: Not many bugs to report this time, but I will modify or discuss
1431: a few of the suggestions I've made before.
1432:
1433: One that I want to modify is my suggestion that % should also
1434: match < with > and ` with '. All right in itself, but terrible if it
1435: would also mean that with :set match, every time one typed a > or a '
1436: the cursor would look for the last occurrence of < or `, since <, >, and
1437: ' can occur in ways that have nothing to do with matching. So I think
1438: that making matchable pairs user-specifiable would be much more useful.
1439: Faith Fich (who send her regards -- she and Mike were our neighbors till
1440: a month ago, but have left for their new jobs at U. Seattle) suggested
1441: that user-settable matches would be particularly useful for those
1442: like herself who use distinct opening and closing delimiters with eqn.
1443: Actually, on further thought this isn't quite right, since eqn
1444: delimiters behave differently from parentheses -- if I want to use =
1445: as my delimiter to enter equation mode, and & as my delimiter to leave
1446: it, then eqn will not give any special treatment to &'s in text mode or
1447: ='s in equation mode; so perhaps a different kind of matching for
1448: that kind of use might be desirable; one would set :set dmatch =&
1449: for the delimiters suggested above; or :set dmatch $$ if one uses $
1450: for both delimiters as in the eqn tutorials. I know checkeq is
1451: supposed to serve this function; but it would certainly be convenient
1452: to have it in the editor; and anyway, my experience was that checkeq
1453: didn't understand that one could have distinct opening and closing
1454: delimiters. (But this is a disinterested suggestion; I haven't used
1455: eqn for a long time; I put in my equations in raw troff.)
1456:
1457: The suggestion in my long original letter about an alternative to
1458: the diagnostic "using open mode" was based on a misunderstanding -- but
1459: one that might be worth making a reality. I had been assuming,
1460: since tutorials referred to the "three states" ex, vi, and open, and
1461: since I knew one could enter the editor by typing % ex filename or
1462: % vi filename, that a third way to enter the editor was by typing
1463: % open filename, and that this is what one should do when editing
1464: with a device not having an addressable cursor (which I had never done).
1465: So I supposed that the diagnostic "using open mode" would only be
1466: received if one were trying to use the wrong mode of the editor for the
1467: tty type shown in one's environment. Perhaps one should indeed have
1468: special way to enter the editor when one intended to edit in "open
1469: mode". (If "open" has other uses as a command, the command might be
1470: "vo" or "op".) Then if a user gave the command vi and his
1471: environment did not indicate a device with an addressable cursor, it
1472: would indeed be appropriate to give a diagnostic informing him that his
1473: environment was not compatible with this command. I suggest this
1474: because of the frustrating experiences I had as a beginner, of
1475: being put into open mode (because my tty type had somehow been lost)
1476: and not knowing what I could do about it.
1477:
1478: I am somewhat confused by your explanation that editor scripts
1479: that would go back and forth between ex and vi modes (using the :vi
1480: and Q commands) are impossible because "The internals of getting a
1481: character from the tty are completely different in ex and vi. Pushing
1482: input for one doesn't affect the other." A vi "script" (i.e. a mapping
1483: or a macro called by @x) can presently include bottom-line commands
1484: called with ":". I would suppose that the way such commands get
1485: characters from the terminal is about the same as the way ex does.
1486: You also write that "Any : command that outputs more than 1 line puts
1487: you into "ex mode"," -- is this a different sense of "ex mode"? If
1488: not, what happens when a vi script does this?
1489: I mentioned that the :so command from vi ignored anything after
1490: any global command in the sourced file. I also find that it will not
1491: accept the ex commands i and a; I realize that a prohibition against
1492: these is part of the way vi's bottom line differs from genuine ex.
1493: I've just done some experimenting, and I find that a script sourced
1494: from the bottom line of vi also interprets the command vi as a command
1495: to edit another file. Do we really want script files to be interpreted
1496: so differently when sourced from ex mode and from the bottom line of vi?
1497: Or if these differences are inevitable, can't the vi version at least
1498: have the positive difference of being able to go to visual mode with
1499: ^M^M or something, and continue following the script, interpreting
1500: characters as screen mode commands, just as a mapping or @x macro will
1501: if it has gone down to the bottom line with ":" and come back again?
1502: I am also still reluctant to give up the idea of a version of the
1503: editor in which there is no difference between the line-oriented mode
1504: and the bottom line of the visual mode. Suppose you took the editor as
1505: it exists now, and modified it so that in visual mode, ":" was
1506: interpreted as "Q", and in ex mode, ^[ was interpreted as ^Mvi. The one
1507: obvious disadvantage would be that it would insist on redrawing the
1508: screen after minor editing operations in ex mode. So suppose you made
1509: it remember the previous state of the screen every time it entered ex
1510: mode, and make the necessary adjustments on return to visual mode if the
1511: editing done was fairly trivial -- using the same criteria it now uses
1512: after bottom-line commands. What would be the problem?
1513: Of course, I know I am quite ignorant of what is involved, and what
1514: I am suggesting as possible may be quite impossible, or may have to wait
1515: for that far-off day when you rewrite the editor.
1516:
1517: You write that some of the restrictions on global commands are due
1518: to the fact that the state of the buffer before the command is stored in
1519: the "last deleted" buffer. But couldn't this situation be modified?
1520: Let's call the "last deleted" buffer buffer 0, since material from it
1521: seems to progress up to 1, 2, etc. with successive changes made.
1522: Suppose things were set up so that during the operation of a global or
1523: macro, deleted material, yanked material, etc. went by default into
1524: buffer 1 instead of 0...? Or alternatively, that the state before the
1525: global were saved in buffer 9, and this was then set outside of the
1526: chain of buffers into which material got pushed with successive
1527: deletions, during the operation of the global? Would this eliminate
1528: the objection to nested globals as well? Presumably, in a global within
1529: a global, the previous state would be stored in buffer 1, and new yanks
1530: put by default in buffer 2 (if the first of the above suggestions were
1531: followed).
1532: You mention in your comments to my letter that the difficulty of
1533: editing command lines "is a standard complaint about a moded editor"
1534: that would be hard to fix. But I point out in that same letter how
1535: appropriate macros or script-files can overcome that difficulty. (My
1536: files "do/1", "do/:" and the "map ^A ..." in my EXINIT.) It should be
1537: possible to introduce commands that would have the
1538: same effects as those macros. (Or at least, to describe such macros
1539: in the documentation. I have realized, by the way, that ^A was a poor
1540: choice of character for me to map, because it occurs in the output of
1541: function keys on a lot of terminals.)
1542:
1543: It would be nice to extend the kinds of "regular expressions"
1544: allowed in searches, e.g. a la egrep. Sometimes I also want to indicate
1545: something like "a substring of precisely 40 characters". This can be
1546: rendered as "........................................" at present,
1547: but things like that can easily lead to commands that
1548: exceed length limits. (Suppose one wants to look for a string of
1549: 40 successive characters other than whitespace. [^ ][^ ][^ ] ... is
1550: too long.) Have you checked out what I mentioned in my first long
1551: letter, that ed allows you to search for (e.g.) successive
1552: identical characters as \(.\)\1?
1553:
1554: Let me pass on a suggestion made recently in a system message by
1555: someone named nye. He was worried about what would happen
1556: if while one person was editing a file, someone else with write
1557: permission for that file also began editing it. Presumably, whoever
1558: did a "write" last would overwrite the other person's work. He
1559: suggested that there be a diagnostic "file has been changed since last
1560: write" for such a situation. (In particular, he wondered what would
1561: happen if he got his mail by editing /usr/spool/mail/name, rather than
1562: by using Mail -- which is certainly tempting if one is more comfortable
1563: with the editor than with Mail -- and if unbeknownst to him new mail
1564: arrived while he was editing.)
1565:
1566: I have discovered the hard way that when one has done a
1567: vi -r filename and decided one was satisfied with the version that
1568: was saved, ZZ or :x are n o t the same as :wq -- the first two
1569: discard the saved file, and only the last one writes it over the
1570: previous version. (I actually haven't checked this out on version 3.9.
1571: I tried to, and found that robert hadn't brought
1572: /usr/lib/ex3.9{preserve,recover}, if that's what they're still
1573: called, from arpa along with the rest of 3.9. But he's getting them for
1574: me.) If you don't want to make ZZ and :x actually equivalent to
1575: :wq, you might at least make them give error messages forcing the
1576: user to make the explicit choice of :wq to keep the saved version, or :q
1577: to discard it.
1578:
1579: I've been having fun using recursive "map" commands from time to
1580: time. For example, a file of mailing addresses of Math Departments is
1581: being prepared, for use with a new Computer Services command "label".
1582: This requires that each address constitute one line of the file, with
1583: the intended lines of each label separated by
1584: semicolons rather than newlines, each being no longer than 34
1585: characters. At present, the lines in the file are of the form
1586: [university-name];[city-state-zip]
1587: and I wanted to find cases where the university name the secretaries
1588: had typed in was over 34 characters long. So I did
1589: :map ^A +36^V|F;^A0
1590: Then, when I hit ^A, the cursor went bopping down the file, passing
1591: through each line at which it could find a ";" before the 36th position,
1592: but stopping when it hit a line where it could not. When I had
1593: corrected such a line, by abbreviating a long word or whatever, I could
1594: hit ^A again and find the next case. The "0" at the end of the map
1595: command is to prevent the "No tail recursion" rule from aborting my
1596: mapping. It has no other effect, because it is never reached.
1597: Of course, the above example of a recursive mapping is guaranteed
1598: to stop eventually, if only by reaching the end of the file. But I find
1599: that mappings that can go on indefinitely are very hard to stop. E.g.
1600: :map q ax^[q0
1601: I've tried some like that, and sometimes hitting <break> or whatever
1602: enough times successfully stops them (often leaving a bit of a mess --
1603: characters that ought to have come after the string of x's embedded
1604: among them), while other times the only thing I can do is to go to
1605: another terminal and kill the editing process. Maybe it is to prevent
1606: things like that that you put in the "No tail recursion" rule --
1607: though clearly it can be gotten around. Might it not be better to
1608: somehow make the editor not quite so deaf to <break>s during such a
1609: process?
1610:
1611: I will mention one curious experience which I have not been able to
1612: reproduce. I use :set nu. After a delete near the beginning of a file,
1613: I found myself looking at a screen with line-numbers beginning around
1614: -2! The lines with nonpositive numbers were blank, if I recall; lines
1615: 1, 2, etc. were as they should be. I mentioned this to someone
1616: who said he'd had the same thing had happened at times, but had
1617: never been able to figure out what conditions caused it.
1618:
1619: Best regards,
1620: George
1621:
1622: From gbergman@ucbcartan Thu Nov 3 22:32:01 1983
1623: Received: from ucbcartan.ARPA by ucbernie.ARPA (4.17/4.13)
1624: id AA25163; Thu, 3 Nov 83 22:31:44 pst
1625: Date: Thu, 3 Nov 83 22:28:11 PST
1626: From: gbergman@ucbcartan (George Mark Bergman)
1627: Message-Id: <[email protected]>
1628: Received: by ucbcartan.ARPA (4.6/3.7)
1629: id AA06097; Thu, 3 Nov 83 22:28:11 PST
1630: To: cc-03@BERKELEY, danh@kim, lindahl@topaz, mckusick@ucbernie, ralph@ucbarpa
1631: Status: R
1632:
1633: Latest letter to Mark Horton re editor bugs etc.:
1634:
1635: copies sent to
1636: cc-03@ucbcory
1637: ralph@ucbarpa, lindahl@topaz, mckusick@ucbernie 25/7/83
1638: danh@kim 26/7
1639: Mark Horton's reply: anderson@kim 30/7/83
1640:
1641: Dear Mark,
1642: I got your reply to my last letter, but you don't say
1643: whether you got the two preceding ones -- in particular, I'm
1644: curious as to what you'd say about the peculiar behavior of
1645: abbreviations terminated by \[character]. (E.g., suppose
1646: someone did :ab ac artistic, and then, supposing the file was for
1647: troffing, typed ac\fP. -- Try it!) And likewise, about what
1648: happens if you hit @x, when register "x contains
1649: x:g/foo/s//bar
1650: (To see this wierd effect, you have to have a file with
1651: an occurrence of ``foo'', and a distinctive l a s t line.)
1652:
1653: In an earlier letter I commented that the mapping that
1654: the editor sets up to enable the tvi's right-arrow key makes
1655: ^L unavailable for refreshing the screen. You replied that,
1656: of course, the editor could not distinguish a ^L generated by
1657: the arrow key from one typed as <ctrl>-L by the user. True,
1658: but some users, such as myself, are quite happy using hjkl
1659: to move around the screen (I use them completely by reflex)
1660: and so have no wish to enable special arrow keys, but do
1661: want to have ^L available to redraw the screen when
1662: a message or something messes it up.
1663: The problem with ^L occurred in using a tvi; now, using
1664: a Z29 (in h19 mode), another version of the problem arises.
1665: It has arrow keys that transmit things like ^]A, ^]B, etc.,
1666: and version 3.9 not only maps these sequences, but also
1667: map!s them. What I found happening is that if in typing
1668: I made a change somewhere in the body of a line and then
1669: wanted to add something at the end of the line, I would often
1670: type a ^] to end the first change and then an A to
1671: begin the second, with less than a second between them, and
1672: this sequence would then be map!ed into ^]ka or
1673: something, landing me in a different place from the one
1674: I wanted. Aside from this major problem, there is the minor
1675: inconvenience that the map! mechanism apparently waits
1676: a second every time I type an ^] from insert mode to see
1677: whether this is going to be one of the map!ed sequences, and
1678: this makes exiting from insert mode sluggish. My temporary
1679: solution has been to write a file of the form
1680: unmap ^]A| unmap ^]B| ...|unmap! ^]A| unmap! ^]B|
1681: which I source every time I go into vi on the Z29. I
1682: guess what I should do is create simplified termcaps that
1683: leave out the arrow keys for my own use when in version 3.7.
1684: Kevin Layer tells me that when he puts 3.9 on all systems here,
1685: there will be documentation on how to create terminfo files;
1686: so I will be able to avoid these inconveniences in 3.9 as well.
1687: What would be better, for these two-or-more character sequences,
1688: though, would be if the "timeout" feature on mappings
1689: could involve a variable interval, which could be set in the
1690: millisecond range for terminal-generated sequences (I suppose
1691: it would have to depend on the baud rate), and longer
1692: for user-mapped sequences. The likelihood of the user
1693: accidentally typing in one of the special sequences so fast
1694: is negligible.
1695: Incidentally, I notice that when I type :map to look
1696: at the automatic mappings, these are labeled "up", "down" etc.,
1697: though for mappings that I create the corresponding position
1698: just shows a repeat of the mapped sequence. Is there
1699: any way the user can put mnemonics in with his own mappings?
1700:
1701: Two other minor points:
1702:
1703: In your reply to my first letter, where I suggested that
1704: N/pattern should take one to the Nth occurrence of /pattern,
1705: you said that N/pattern actually resets the window size to N
1706: while carrying one to /pattern. The tutorial says the same,
1707: I believe, but nonetheless, it doesn't work!
1708: When one has pulled a command into a buffer,
1709: say "x, and invoked it with @x, if one then tries to get
1710: a copy of this command by doing "xp, it doesn't seem to work.
1711: The way I've found to make it work is to do any other
1712: yank-and-put (using, say, the last-deleted
1713: buffer). This somehow unfreezes the mechanism, and (after undoing
1714: this last put, unless one wanted it), one can then successfully
1715: do "xp.
1716: Yours,
1717: George
1718:
1719: (Message inbox:32)
1720: Date: Sun, 10 Jun 84 16:29:50 pdt
1721: From: gbergman@ucbcartan (George Mark Bergman)
1722: To: cc-03@ucbcory, danh@kim, decvax!tarsa, gbergman@ucbcartan,
1723: hplabs!intelca!omsvax!isosvax!root, ihnp4!burl!we13!ltuxa!jab,
1724: leblanc@ucbdali, lindahl@topaz, mckusick@ucbernie, [email protected],
1725: ralph@ucbarpa, reiser@ruby, [email protected], unisoft!eryk,
1726: uw-beaver!ubc-vision!mprvaxa!sonnens
1727: Subject: more editor bugs & ideas
1728:
1729: Here's another letter of comments on the editor that I'm
1730: sending to Mark Horton (mark@cbosgd).
1731: If any of you to whom I'm sending this aren't interested in
1732: staying on this mailing list, just let me know.
1733: Horton replied to an earlier letter by saying he had no idea
1734: when he'd have any time to work on the editor again, so I don't
1735: expect replies from him to this and further such letters in the near
1736: future.
1737: For those who are not familiar with the subject of item "A."
1738: below, modeline is a feature that he added without publicizing it much,
1739: whereby if any line in the vicinity of the top or bottom of the file
1740: (top and bottom 10 lines? I don't remember) contains the string
1741: vi: or ex: and then another :, everything between these is
1742: interpreted as a command and executed when this file is read by the
1743: editor. There was a big squall in net.news when someone discovered
1744: it by chance (an accidental string of this sort occurred in their
1745: /etc/password; fortunately the "command" was meaningless, and evoked
1746: a diagnostic from the editor). Some serious dangers of this
1747: feature were pointed out by various contributors, one of whom described
1748: for all who were interested how to eliminate it from the source file.
1749:
1750: Dear Mark,
1751: Here's another few month's collection of comments...
1752:
1753: A. Modeline
1754: I presume that in following the net.news discussion of the
1755: ``MAJOR BUG (modeline)'' you saw my two contributions; but I'll
1756: summarize the relevant points (not in the order I made them):
1757:
1758: 1) One possible feature that would be about as convenient as
1759: the modeline, and would avoid the dangers that people have pointed
1760: out, would be `enhanced tags', in which the 3d entry of a line of the
1761: tags file could be not merely a pattern search, but an arbitrary
1762: command line.
1763:
1764: 2) I described (both in net.news and in an earlier letter to you) a
1765: mapping in my EXINIT which makes one keystroke yank the current line
1766: (or the next N lines if preceded by a count) to a named buffer
1767: and then execute that buffer. If one keeps a set of initializing
1768: commands within a file to which they are to apply, one can then
1769: easily execute them on beginning an editing session, which gives
1770: almost the convenience of the modeline feature, without the dangers,
1771: and has an enormous range of other uses. So I think the modeline
1772: feature could be dropped.
1773:
1774: Let me add to those points:
1775:
1776: 3) A modeline
1777: vi:r %:
1778: leads to an infinite recursion! Fortunately, ^C cuts it off.
1779:
1780: 4) I agree with others' comments in net.news that if the modeline
1781: feature is not dropped altogether, it should be a settable option
1782: with default ``nomodeline''.
1783:
1784: 5) It should certainly be off when ``novice'' is set!
1785:
1786: B. Tags
1787: Having mentioned these in point A(1), I will give some other
1788: comments I have: One of your update documents mentions the fixing
1789: of a bug that left ``nomagic'' set if the file named in the tags
1790: file did not exist. Very good, but one still ends up with ``nomagic''
1791: if the file exists but the pattern-search is unsuccessful!
1792: It would also be nice if the tags file could include file addresses
1793: of the form ~user/filename, in particular ~/filename, and if the
1794: command :set tags= recognized the same. (I suppose this makes no
1795: difference to people who get their tags from ctags, but for me, the
1796: tags file is maintained as a collection of items I have been working on
1797: recently, or mean to soon, and entries are put in or removed by
1798: hand regularly.)
1799:
1800: C. Reversal of n and N
1801: I also mentioned in one of my net.news comments a peculiar behavior
1802: that often seems to occur after I've been using my yank-and-execute
1803: mapping a lot, in which, after a command-line pattern-search :/pattern
1804: (rather than simply /pattern), the screen-mode commands n and N give
1805: searches in the reverse of the expected direction, with ? and /
1806: respectively instead of vice versa. Perhaps you can figure out what
1807: causes this; if not, would it help for me to do something like make
1808: a core dump of the editor when it is happening and send it to you?
1809: (I don't know how to send a nonascii file, though... .)
1810: A few more observations on this behavior: Though I commonly
1811: discover it when I am using my yank-and-execute mapping, it has
1812: happened on at least one occasion when I hadn't use that at all,
1813: so far as I could recall. It may actually happen quite frequently,
1814: but people just don't notice it because they usually use /pattern
1815: instead of :/pattern. (My mapping makes it more convenient for
1816: me to use the latter when the pattern is complicated, or I want to
1817: store it for repeated use.)
1818:
1819: D. Update on dangerous recursions
1820: Discovering that ^C interrupted the recursive modeline led me
1821: to test it out on a recursive mapping, :ab x ( x ). It interrupts
1822: it OK. Problem solved courtesy of 4.2BSD, I guess.
1823:
1824: I will collect under the next heading my usual list of:
1825:
1826: E. Minor bugs and modest suggestions
1827:
1828: ye and yE yank one character less than they should.
1829:
1830: If the command Ne (N a count) would land one on a 1-letter
1831: word, one generally lands at the end of the next word instead
1832: (even if it is also a 1-letter word. Exception: if one starts
1833: at or after the end of the preceding word, e behaves as it should.)
1834:
1835: Note also that in the line
1836: Sentence... . Sentence
1837: if the cursor is on the second S, the command ( causes no motion
1838: at all.
1839:
1840: I suggest that the motion commands { and } should accept indented
1841: lines as paragraph-starts, or at least that there should be some
1842: way of requesting this in the ":set para=" command. After all, these
1843: motions shouldn't be useful only to people writing troff files!
1844:
1845: In general, the command NC (where N is a count) changes material
1846: from the cursor position to the end of the Nth line, leaving material
1847: before the cursor on the current line unchanged. But if the line
1848: is indented, and the cursor is on or before the first nonwhite
1849: character, the preceding white text (spaces and tabs) is lost.
1850:
1851: It should be possible to use
1852: :unmap #1 :unmap! #1 :unab #1
1853: when function-keys have been mapped.
1854:
1855: Sometimes a noisy phone-line, termcap padding errors, etc.
1856: cause just one or two lines of the screen to be messed up, and one
1857: may only wish to refresh those lines. Could a command be introduced
1858: which would do this? Ironically, on a dumb terminal one can generally
1859: do this by moving the cursor over the line, but not on a smart terminal.
1860: Another way one can do it is ddP, but I would sometimes feel uneasy
1861: about unnecessarily modifying the text. I would
1862: suggest that the form of the command be 1^L (2^L for 2 lines, etc.).
1863: Currently, ^L apparently ignores counts. (Actually, I'm writing at
1864: the moment on a tvi, so I've verified this for ^R rather than ^L.)
1865:
1866: If one uses the source command, and the file sourced contains
1867: a command
1868: :e newfile
1869: where newfile does not already exist, the diagnostic ``No such file
1870: or directory'' aborts the sourcing process. One ought to be able to
1871: use such commands in a sourced file.
1872:
1873: In vi screen command mode, ^[ is supposed to ``cancel partially
1874: formed commands'' and generally does so without protesting, but if the
1875: partially formed command is a count (e.g., if one has typed 110 instead
1876: of 10 and wishes to start over) it feeps, which depending on one's
1877: terminal can be a minor or a major annoyance. (Also depending on
1878: whether someone is trying to sleep in the next room.)
1879:
1880: The diagnostic, ``First address exceeds second'' should not be
1881: needed with one-address commands! The case where a series of addresses
1882: before a command, of which the first may exceed the second, is most
1883: useful is when the last address is a pattern-search preceded
1884: by a ";", e.g.
1885: :$;?^\.PP?-r otherfile
1886: but let me give simpler examples; of the two commands
1887: :3,1,2ka :1,3,2ka
1888: the first correctly marks line 2, but the second is aborted by the
1889: diagnostic quoted.
1890:
1891: F. A feature that would be very desirable, and might or might not
1892: be easy to implement.
1893:
1894: In general, when one is inserting text on a smart terminal in vi,
1895: the context below the text being added is pushed downward, line by line,
1896: till none is left on the screen. I would like a settable option that
1897: kept a certain number of lines of following context on the screen
1898: during additions. The point is that one should see the material that
1899: what one is writing will have to mesh with. What would be involved in
1900: implementing this would, of course, depend on terminal capabilities.
1901: If it would be difficult to keep an arbitrary number of lines,
1902: would it at least be possible to have an option that would keep one
1903: line, using the special bottom-line feature of some terminals?
1904:
1905: G. More radical suggestions (wishlist).
1906:
1907: 1) Editing text with _u_n_d_e_r_l_i_n_i_n_g.
1908: Although one of the valuable features of vi is the explicitness
1909: with which most nonprinting characters are shown, this can be annoying
1910: when one wants to deal with text in which many characters
1911: are ``emphasized'' using the sequence _^H; e.g. nroff output. I
1912: suggest a settable option under which such sequences would be shown as
1913: with ul.
1914: I realize that this would involve working out a great number
1915: of details, e.g. would motion commands treat _^Hx as one
1916: character or as three? How would the nth column be defined? How
1917: would one place the cursor on one of the elements of the string
1918: _^Hx for editing purposes? What would be done with _^H^A or _^H_^H....?
1919: I think the best solution would be to treat _^Hx as a single
1920: character for the purposes of motion commands, definition of nth
1921: column, deletions, etc. when this option was set. In terms of placing
1922: the cursor, two possibilities occur to me. One would be to only allow
1923: the cursor to sit on the underlined character ``as a whole'', and to
1924: have changes in underlining done by special commands: perhaps ^E as a
1925: toggle to turn emphasis on and off in insert mode, _ to change
1926: underlining in screen command mode as ~ changes capitalization
1927: ("_" is at present a synonym to "^", except
1928: that it takes counts. ^ could be modified to take
1929: counts, and _ then used as suggested above), and \e in replacement
1930: patterns. The other would be to consider a cursor sitting ``on''
1931: a sequence _^Hx to actually be on the x, and to set things up so that
1932: if the cursor is on any of the other members of this sequence, the
1933: sequence is ``expanded'' on the screen, i.e. shown as it is in the
1934: present vi. Then define a single vi command so as not to skip over
1935: the _ and ^H in such a sequence; namely ^H. (This would mean
1936: making a distinction between h and ^H in screen command mode.)
1937: This one motion would allow one to edit parts of such a sequence.
1938:
1939: 2) Editing several files at once.
1940: When I have to do work that involves more than one file, the
1941: repeated use of :w|e#, yanking text to named buffers to move it, losing
1942: marked lines when I return to a previous file, etc. becomes
1943: annoying. I think it would be desirable if one could make a group
1944: of files behave like one file during an editing session, and move
1945: around within that file as comfortably as one move within one file.
1946: I suggest that visually, each file be separated from the next
1947: by a pattern
1948: :::::::::::::::::::
1949: as when ``more'' is applied to a group of files.
1950: For ``Go to file 3, line 20'' I suggest a screen command syntax
1951: *3*20G. *-1* and *+2* could mean ``the preceding file'' and ``the
1952: file after next'' in such commands. (The initial * could be optional
1953: if there is no preceding + or -, as in the first example.) In a
1954: command such as :w, the default address range would be all of the file
1955: to which the current line belongs (i.e.,
1956: it would be a synonym for :*.*w) To write all files, I suggest :**w.
1957: :q, :x and ZZ would quit the editing session entirely, while :*1*q
1958: would remove the buffer of file 1 from the object being edited.
1959: On the other hand, relative motions such as 10j, H, etc. would work
1960: within the ``visible object'', the union of the files.
1961: %s/pattern/repl/ would apply to the file containing the current line,
1962: and would have the synonym *.*s/pattern/repl/, while
1963: *1,2,4*s/pattern/repl/ would affect the 3 indicated files, and
1964: **s/pattern/repl/ would affect all files.
1965:
1966: 3) Input and output of shell escapes.
1967: The various commands involving shell escapes that you have
1968: set up allow four possible relations between the text being edited
1969: and the input and output of the commands: none (:!command);
1970: specified line-range as input with output not affecting text
1971: (:address-range w !command); no input from text but output inserted at
1972: specified line (:address r !command); and specified input from text
1973: with output replacing input (:address-range !command).
1974: It would be nice to have more flexibility; in particular, to
1975: be able to include input from the file and place the output somewhere
1976: else in the file without destroying the input text, and to input
1977: more than one segment of text, e.g.
1978: !egrep -f[addr.range] [other.addr.range] > [place of insertion]
1979: Obviously, there would be a problem of setting up a syntax that would
1980: avoid confusion with strings that look like address-ranges in the
1981: shell command. Perhaps \[...\] could enclose address-ranges where
1982: I have used [...] above.
1983:
1984: 4) ;
1985: The ; syntax, allowing one to do a pattern-search starting
1986: from a specified line is useful, but in setting up 2-address commands,
1987: one does not necessarily want the point from which one starts the
1988: search for the second address to be the first address. If this business
1989: were being set up now, I would suggest that
1990: address;/pattern/
1991: should simply be a way of specifying the result of doing the indicated
1992: pattern-search relative to the indicated address, so that
1993: :address1,address2;/pattern/d
1994: would delete from address1 to the location found by the pattern-search
1995: relative to address2. Since people are used to the existing
1996: syntax of ;, I suggest that some other symbol be used in the above
1997: way, e.g. ], so that
1998: :address1,address2]/pattern/d
1999: could be interpreted as described.
2000:
2001: 5) Insertions into long lines on smart terminals at low or medium
2002: baud rate (e.g. 1200).
2003: This is annoying because the material coming after the point
2004: of insertion begins to wrap around, and the cursor must jump back and
2005: forth, inserting characters at the beginning of the
2006: continuation line, then going back to the point of insertion, and so
2007: on. (At least, this is my experience on my Z29. I haven't done
2008: editing by phone connection on any other smart terminal.) It's
2009: actually nicer on a dumb terminal, where the editor just overwrites,
2010: and shows you the result after you escape. I suppose that the need
2011: for the cursor to jump back and forth is due to the deficiency of the
2012: terminals -- has anyone suggested to terminal manufacturers that along
2013: with the wraparound feature, they add a feature which ``remembers''
2014: when a line is a continuation of the preceding line, and automatically
2015: pushes material from the preceding line into the continuation line
2016: when characters are added to the former, eliminating the need to send
2017: all these instructions in over a slow line? (Do terminal manufacturers
2018: listen to editor-software specialists?) If not, it might just
2019: be best to not show the pushed-over earlier material till the insertion
2020: is complete.
2021:
2022: 6) Filename convention
2023: This is really a suggestion for UNIX generally, but it could be
2024: implemented on the editor separately. It is that for any file,
2025: filename/.. denote the directory in which the file lies. (This
2026: does not mean that every file should be treated as a directory, or
2027: that the ls command should show filename/..; it would just
2028: be a convenient way to refer to the directory containing a given
2029: nondirectory file, consistent with the existing convention for
2030: directories.) Within the editor, the important cases would be
2031: %/.. and #/.., allowing commands such as:
2032: :1,10w %/../othername
2033:
2034: All for now! Yours,
2035: George
2036:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.