Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!hao!hplabs!sri-unix!Laws@SRI-AI.ARPA From: Laws@SRI-AI.ARPA Newsgroups: net.unix Subject: Re: vi '_' command Message-ID: <17626@sri-arpa.UUCP> Date: Fri, 16-Mar-84 14:55:48 EST Article-I.D.: sri-arpa.17626 Posted: Fri Mar 16 14:55:48 1984 Date-Received: Mon, 19-Mar-84 07:51:12 EST Lines: 370 From: Ken Laws The underscore character apparently means "move to the first character on the line." Abbreviation mode is mentioned in the last paragraph of the Berkeley "Ex changes" document, "Vi Tutorial Update" section. Since I didn't get roasted too badly for my suggestions about upgrading the C environment, I will pass along my rather lengthy list of suggestions for improving vi. If you choose to wade through this, please bear in mind that vi is my favorite editor and that I have defended it at great length against EMACS and other competitors. I make these suggestions because vi is good enough to be worth the trouble. -- Ken Laws 11-Jul-82 Laws at SRI-IU There have been several good changes to vi lately, but I think the following still need fixing: ^Y on our system is now used to interrupt a process, but this sometimes screws up from vi and should be disabled. Typing ^C has no effect except to leave a garbage "^C" on the screen. This should be cleaned up. The sequence "i[esc]" should be a no-op instead of backing up one character. There should be an "insert next character" command, just as "r" is a "replace with next character". I suggest that the "v" key be used for this, although g, V, K, *, or any of several control commands could be used. If v is used, V might be made the same as i to create a parallelism with r and R. (The i command might better have been used for upward motion, substituting jkil for the current hjkl. I would also like to have HKL for the three "home" commands, instead of HML. Sometimes spatial layout is easier to remember than mnemonic names.) There has been some innconsistency in the insert-mode editing commands available from vi and ex. (Perhaps this has been fixed.) ^C is a backspace in vi, an interrupt in ex. ^W is a backward delete word in vi, a no-op in ex. I believe there has also been some inconsistent use of ^Q as a quote character (like ^V). ^X is listed as unused in the vi command summary, but is usually the kill character that deletes an entire insertion line. The action of the insert-mode delete key is a little strange. I do not see any advantage in backspacing over characters instead of deleting them from the screen. I suppose this was for compatibility with the shell's old command-line editing facilities, but 1) I never liked the way the shell left deleted garbage on my screen, and 2) vi has no need to "preserve text so that you can retype it", since vi gives you the ability to back up and insert text in the middle of a line. This type of deletion just encourages an inefficient form of editing in which one backs up and retypes large amounts of text instead of switching to command mode and making the correction. The editing functions available within insert mode could be expanded. A good model would be the EMACS control commands, since EMACSers are stuck in insert mode permanently. This can be done using the mapping capability, but I would like to see an extensive set of defaults. I would also like to see some parallelism between the insert-mode editing functions and those available in command mode. Cursor motion using "j" and "k" should use the full screen, not track the ends of text lines. This tracking makes the cursor very difficult to drive to a visible location above or below the current paragraph, and is particularly obnoxious when editing code. The Rand and Yale editors (NED, Z) use full 2-D motion and it works very well. (There should be a switch so that those who want to track ends of lines may do so.) The autoindent facility is in the right spirit. Word motions (w, b) always leave you on the first letter of a word. I like this, but I notice that EMACS leaves you on the space before the word. Perhaps a user-settable switch is needed to make things easier for EMACS users. Paragraph motions should, by analogy, leave you on the first character of a paragraph. I have never quite adapted to being left on the preceding blank line. There is evidently a way to use macros to set the paragraph and section actions, but the documentation is not clear on whether predefined macros exist and what their values are. Examples of how to set the macros should be given in the documentation. There needs to be a query function for determining what macros have been mapped and what the mappings are. Vi does not allow a newline (\n) to be embedded in a replacement string even when the : escape is used; it is necessary to drop into ex to make such substitutions. (Evidently this is because vi only has a single line on which to echo the substitution command. Still, a \n could be inserted to mark the break.) Further, a vi command of :g/pattern/s//\ will enter an infinite loop, and if you change it to ":1,$s/pattern/\" the system takes off and does a lot of null substitutions without waiting for any more characters in the replacement string. This is silly. Vi and ex object to exceedingly large files; I once had to use sed instead. Evidently they give up because they can't handle "undo" on such a file. Very well, skip the undo but still give me a visual editor. I can write intermediate copies if I need checkpoint protection. While I'm on the subject, thanks for implementing undo. I love it! I have no particular feelings about whether forward and backward searches should wrap around the end of the file; both choices have merit, and it is reasonable to have a user-settable switch. However, if wraps are enabled and a wrap takes place, I want to be notified by some beep or flag line on the screen. Otherwise it can be very difficult to tell whether I am seeing new occurrences or just the same ones over and over. The DEL key does nothing in command mode. It might as well be wired the same as "X" -- delete previous character with immediate erasure. There should be a switch to determine whether deletion in insert mode should be allowed to affect characters that existed prior to the insertion. (I really don't see any reason for disallowing it.) Macro functions, using @, generate an extra return at the end. This forces me to add a "-" command to undo the return (which is not precisely the same as having no return). ":*" seems to have some function now, but it is undocumented. There is a need for a "remember" function that would generate a macro as you edit some text. This would be much easier to use than generating some text commands and then deleting them into a buffer. There is a tendency for vi to forget a macro if there is an error during its execution. This makes it difficult to edit the macro and try again. The :! escape should expand aliased commands. The arrow keys on my terminal have rather mysterious functions. (->, for instance, is the same as C; up arrow is the same as A.) I suppose this is due to the ASCII codes for these characters. The documentation needs a set of keyboard charts. Unfortunately the special symbols vary with the terminal, but any keyboard chart is better than none. The yank paragraph function, "y}", is faulty when used to pick up the last paragraph of a file. If there is no final linefeed, vi thinks that the buffer contains a string instead of a set of whole lines. This shows up when the "p" command is used to put the paragraph somewhere. Wrapmargin screws up if a long string is appended to the end of a line by using the repeat (.) command. It trashes several lines of text, and undo doesn't completely restore the previous state. There needs to be a "justify/fill" action for reformatting paragraphs. The simplest would be to have the wrapmargin take effect after editing a line (in the middle) or joining lines with "J". (This action could be controlled with a user-settable switch.) [Note: there is a separate justify paragraph command, fmt, invoked as an ! filter. It should be extended so that the user can control the line length.] Wrapmargin should be able to break hyphenated words at the hyphen. This needs to be optional since some text formatters are unable to reattach hyphenated fragments separated by a linefeed. The "^\" command is documented as unused, but puts me into ex. The "~" command is documented as unused, but now inverts the case of a character and moves forward one character. (Nice, but there should also be commands for inverting the case of arbitrary regions and for capitalizing a word and moving to the next one.) Underscore is documented as unused, but moves to the first non-whitespace character of a line. (Also nice.) The % command in ex is strange. It seems to be a "scroll to end of file". This is not documented. Apparently ":%s///" is a global replacement command -- this seems very handy, and should reduce the number of times that I foul up the ":g//s///" syntax. Perhaps just /pattern/replacement/ could be recognized as a substution, or .s could be used for a one-line substitution and s by itself could operate over ".,$". There should be a rest-of-line-is-a-comment character for documenting editor scripts in shell files and ex.rc files. Page display (due to scroll, forward page, search, etc.) can be halted by ^O so that another command can display another page. This is useful, but would be even easier to use if the second command could be given without the ^O. This must be possible since EMACS does it. The vi documentation of "!" in the appendex give incorrect cross- references to section 7.3. These should read 8.3. Despite all of the above, I think that vi/ex/ed/sed is an excellent editor. -- KIL More suggestions about advanced features: The "dw" command is not very useful, and is even annoying, when issued from within a word. It should work like "cw", deleting to the end of the word instead of to the start of the next word. The search operator, /, may position the located line anywhere in the window, depending on how far the line was from the previous window location. This is no doubt efficient, but I would sometimes like to be able to control the context which is displayed with the line. This can be done with fancy mappings, but it would seem sensible to have a switch to force the line to the top, middle, or bottom of the window. The "v" command, particularly "v/pattern/d", seems to be exceedingly slow -- like 15 minutes on a 12,000-line file. It is usually much faster to do a "g/pattern/m$" and then to delete blocks of text. This should be documented. A global replacement of more than about 700 instances halts with a "replacement loop" message. The loop detector should be smarter. It is sometimes very difficult to convert stream-oriented lists to columnar tables using vi. I would like a command to right-adjust or left-adjust the current word against a specified column number. Macros are not able to execute "p" commands. This is very inconvenient. Mappings and macros generally cannot be used as primitives in "g" commands. Neither can they be given a repetition factor. It would be much more convenient if macros acted like new keystroke commands instead of as string abbreviations. Macros tend to be slow, probably because of the undo facility. I would occasionally like to disable undo to gain a little speed. Macros would be much more powerful if they could make tests of text content, such as comparing the first word on a line with that one the next line to see if they are the same. Sometimes I also want to pick up some numbers on one line and add them into corresponding positions on another line. (I suppose for such functions I should use awk or EMACS.) The command ":1,20d" does not put the deleted lines into a numeric buffer the way that other forms of deletion do. This means that if you don't undo the deletion immediately, the text is lost forever. The autoindent feature uses tabs to space over to the start of text. This is exceedingly annoying; it makes it difficult for me to change the indentation of code sections where some lines are autoindented and others are not. I would like to have a switch available so that I can turn off automatic tabbing. The editor should accept ":wn" and ":xn" just as it accepts ":wq" and ":w :n". Both "p" and "P" leave the cursor on the first line of an inserted text section. I keep expecting "P" to leave me on the last line. It would be convient to have it do so. Note, though, that for words or line fragments both "p" and "P" leave the cursor at the >>end<< of the new text. I have no particular preference here, but I suppose for consistency and flexibility one of them should leave the cursor at the start. Very minor point: after a "yw" to yank a word, a "p" followed by a "u" should be a no-op; instead it spaces the cursor one column. (The "Pu" combination correctly puts the cursor where it was.) Deleting a line and then undoing puts the cursor at the start of the line. Undoing a ":%s///" command puts you at the top of the file. In general undo does not always guarantee correct cursor placement, even though the ' mechanism may remember where you were. The vi "J" command understands that a "." represents the end of a sentence and should be followed by two spaces. However neither vi nor troff understands that ".)" at the end of a line is also the end of a sentence and should be followed by two spaces. The ^X command for upward scroll has not been documented. It would be nice if the ":e" command could accept a list of files, although I realize that this could complicate the ":e #" and rewind mechanisms. After a shell escape or certain other commands, vi offers a "[Hit return to continue]". If you instead enter ":e filename", vi will switch to editing the new file. Good. However, the "[Hit return to continue]" is still active on entry to the new file. Vi should be smart enough to turn this off and just display the text. (I suppose this should be controlled by another switch. Someone might want to edit the new file without distroying info displayed on the screen.) The "^B" command does not respond properly to a count specification. A "2^B" will back up only two lines, and a "6^B" will go forward several pages. The command "16z." is also somewhat unusual: it should be identical to "z.", I suppose, but instead it pages backward. There might be a place in this world for a wrapmargin algorithm that went to a new line after every punctuation mark. This would break lines at phrases in a manner compatible with text formatter use. Some people like to edit by moving phrases around. The :% operator loses track of where the user was. A subsequent '' command returns to line 1 instead of the line where the :% was issued. Overwriting text with the "R" command fails badly if you enter the wrapmargin. The line is broken and text that was overwritten reappears on the new line. The escape command ":!echo $a" echoes "$a" instead of expanding the value of the symbol. The :! command does not expand {foo,bar} names in the manner of the C-shell. The command ":map * 2x p" has a strange side effect. After using the resulting * command, one is then unable to insert the contents of named buffers (as with "bp) until after an open, delete, or other text-altering command is executed. After yanking or deleting text into a named buffer, you can move the cursor and then insert the text with the "p" command. This capability is lost if you change to a new file with the "e" command. The text is still available, but vi has forgotten which buffer was last yanked. It should be easy enough to retain this information. I wanted to apply a "4x" command at the start of each line in a range in order to delete the first four blanks. I made the mistake of using ":'a,'b4x", which had the effect of exiting and deleting all of my file except the lines in the indicated range. My fault, but beware of this mode error! Perhaps it should be pointed out in the documentation. The ":wq" command does not check whether there are additional files waiting to be edited. Whereas ":w" followed by ":q" requires an "!" to terminate editing, ":wq" allows you to quit without one. (I suppose that an "!" in this position would apply to the write rather than to the quit. Vi should thus not allow a quit at all unless given as a separate ":q!" command.) When editing a read-only file, the :f command does not list the file name. Perhaps this is a "feature", but I find it annoying to lose information this way. -------