vi '_' command

[Laws at SRI-AI.ARPA]

From:  Ken Laws <Laws at 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.
-------