decot@cwruecmp.UUCP (Dave Decot) (03/14/84)
What does the undocumented vi 3.7 command '_' (underline) mean? What are its implications? It seems to be a synonym for 0 or ^ or something, but I haven't figured out why you would want it. And what is the :ab command? Seems to allow abbreviations, but I don't have any documentation on it. Nobody answered Jim Davis's question about the ~ (capitalize one character) command, either. My manual says both of these characters are "Unused." Dave Decot (No address, moving to CA)
merlyn@sequent.UUCP (03/16/84)
/--\ | o | | < . . . . . ... food for the line gobbler \--/ Dave Decot, of Nowhere, USA, writes: What does the undocumented vi 3.7 command '_' (underline) mean? What are its implications? It seems to be a synonym for 0 or ^ or something, but I haven't figured out why you would want it. And what is the :ab command? Seems to allow abbreviations, but I don't have any documentation on it. Nobody answered Jim Davis's question about the ~ (capitalize one character) command, either. My manual says both of these characters are "Unused." Well, Dave, here's your answer, because You Asked For It! The "_" (underline) command means "line", like "w" means word, and "G" means end-of-file (kinda). It exists in most, if not all, versions of vi. Its presence isn't document, because using it is just like doubling the verb! That means, "dd" is the same as "d_", "yy" is the same as "y_", and so on. The comments in the source read to something like "this command was phased out... stuttering on a key seems like a more natural action". You're right in asking "why you would wan't it", because it isn't really needed... it's just there for backward compatibili- ty. Now, for the other things you mentioned, they are all document quite nicely in the Berkeley paper entitled "Ex changes -- Ver- sion 3.1 to 3.5". True, true, this isn't the original spec, but then again, the original spec says that it documents Version 3.1! [Hmm, I just noticed that my version is 3.7... I wonder what else they've added!] And that, Dave, is your answer, because You Asked For It! For asking this week's question, Dave wins a $10 bit-twiddler... guaranteed to change bits right before your eyes. [Editors note: we can't send it to Dave, since he has no address.] Randal L. Schwartz, esq. Sequent Computer Systems, Inc. UUCP: ...!tektronix!ogcvax!sequent!merlyn BELL: (503)626-5700
Laws@SRI-AI.ARPA (03/16/84)
From: Ken Laws <Laws@SRI-AI.ARPA> 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//\<CR> will enter an infinite loop, and if you change it to ":1,$s/pattern/\<CR>" 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/<CR> 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 <CR> :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. -------
srini@ut-sally.UUCP (Srinivasan Sundararajan) (03/18/84)
:ab in vi ========= You're right there - it is meant for abbreviations. For instance : ( in command mode ), the command - :ab xy xylophone makes vi automatically expand - xy (to) xylophone as you are typing text. It's not necessary for the "ab"-ed form to be the first few letters of the expanded form. Even this is okay - :ab q xylophone But as you type in the abbreviation, leave a blank after it so that vi will know that it needs to expand. This makes it possible to type in a word like quiet without having it suddenly expanded to - xylophoneuiet !!
chris@umcp-cs.UUCP (03/19/84)
As long as we're pointing out things in vi, here's some info that may be of interest to people. The '_' command is very similar to the '^' command in that it moves to the first nonblank character of the current line. The key difference is that '_' is a *line* command while '^' is a *character* command. This is important for all functions that read an "address", for example, "d", "y", "c". In fact "d"(elete), "y"(ank), etc, all call a common internal routine in vi to get an "address". If the address is of a particular character, then a character-mode delete/yank/whatever is done. If it is a line address, a line mode operation is performed. The "address" command may be any of the regular positioning commands (e.g. W b $ /pattern/) or the original character repeated (as in dd or yy). Some examples: You type VI does -------- ------- dd Deletes the current line. d'a Deletes all lines between the current line and the line containing mark "a", inclusive. d`a Deletes all characters between the current character and the character at mark "a". This works much like an Emacs ^W in that the two endpoints are considered to be between two characters. Note that a character oriented delete may delete newlines. c/accord/ Changes all characters (NOT lines!) between the current character up to but not including the "a" in "accord". (However, see Note below). c?accord? Changes all characters betwen the current character and the "accord", including the word "accord". ** Note: if you have "wrapscan" set (the default), a search may wrap from the beginning of the file to the end. This can cause unexpected results (which is why I have "set nows" in my .exrc). yj Yanks two lines, the current line and the one below. yH Yanks all the lines from the top of the screen to the current line, inclusive. <G Dedents the lines between the current line and the last line, inclusive. (The variable "shiftwidth" determines the amount of dedenting.) Note that this command turns character addresses into line addresses (so does ">"). !}fmt Runs the lines between the current line and the end of the paragraph through the program "fmt". Vi combines the repeat count (if any) on the command character with the repeat count on the motion command, so that "2y2j" yanks five lines. Interestingly, "2y2_" yanks 4 lines (so does "2y2y") since the _ command moves down (repeat count minus 1) lines. Beware, however, of using repeat counts on all the motion commands; they're not all implemented the same. 4$ moves to the end of the third line below the current; 4^ merely moves to the first nonblank character of the current line. '|' is apparently a synonym for '0'; given a repeat count it goes that many characters to the right of the beginning of the line (as if you had typed '|' (rept-1) 'l'). (Exercise for the reader: why can't you give a repeat count to '0'?) Capital letters do different things depending on the command. D acts like d$; Y acts like YY. Don't ask me why. By the way, capital ! doesn't seem to do anything :-). Well, this article seems to be degenerating at this point, so I guess I'd better wrap it up. Bye! -- In-Real-Life: Chris Torek, Univ of MD Comp Sci UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay
grt@hocda.UUCP (G.TOMASEVICH) (03/22/84)
Subject: Re: vi '_' command This is to Ed Laws; my mail attempt failed again, as usual. Those are interesting comments. I have somewhat different opinions on some of them: 1. ^X is the ASCII cancel code, and I use is as my kill-line character. I do not want to see it used for anything else. 2. !wq does not let me quit if there are any more files. I dunno about yours. 3. The arrow keys on HP terminals do things to 'vi' that I have not seen documented. On the HP 2647A, they send escape sequences. On that terminal, 'vi' sends "\033&s1A" to allow it to read those keys. It then synthesizes a move command; try turning on display functions if your terminal has it. ESC must have a timeout so 'vi' can tell whether you typed ESC or one of those arrow keys. 4. On some terminals, ^\ is the UNIX quit signal, which causes a core dump if not caught. 5. Your suggestion on wrapscan telling one it wrapped around is a good idea. I never use wrapscan, because I hate having an unannounced wraparound. George Tomasevich, AT&T Bell Laboratories
preece@ccvaxa.UUCP (03/29/84)
#R:sequent:-42500:ccvaxa:27200001:000:262 ccvaxa!preece Mar 27 13:36:00 1984 One useful difference between "dd" and "d_" is that while stuttering on the same key may be more natural, keyboard stuttering is also quite common. At least with different characters a bouncy 'd' key won't kill lines. scott preece ihnp4!uiucdcs!ccvaxa!preece