See the RATIONALE for ex(1p) for more information on vi. Major
portions of the vi utility specification point to ex to avoid
inadvertent divergence. While ex and vi have historically been
implemented as a single utility, this is not required by
POSIX.1‐2008.
It is recognized that portions of vi would be difficult, if not
impossible, to implement satisfactorily on a block-mode terminal,
or a terminal without any form of cursor addressing, thus it is
not a mandatory requirement that such features should work on all
terminals. It is the intention, however, that a vi implementation
should provide the full set of capabilities on all terminals
capable of supporting them.
Historically, vi exited immediately if the standard input was not
a terminal. POSIX.1‐2008 permits, but does not require, this
behavior. An end-of-file condition is not equivalent to an end-
of-file character. A common end-of-file character, <control>‐D,
is historically a vi command.
The text in the STDOUT section reflects the usage of the verb
display in this section; some implementations of vi use standard
output to write to the terminal, but POSIX.1‐2008 does not
require that to be the case.
Historically, implementations reverted to open mode if the
terminal was incapable of supporting full visual mode.
POSIX.1‐2008 requires this behavior. Historically, the open mode
of vi behaved roughly equivalently to the visual mode, with the
exception that only a single line from the edit buffer (one
``buffer line'') was kept current at any time. This line was
normally displayed on the next-to-last line of a terminal with
cursor addressing (and the last line performed its normal visual
functions for line-oriented commands and messages). In addition,
some few commands behaved differently in open mode than in visual
mode. POSIX.1‐2008 requires conformance to historical practice.
Historically, ex and vi implementations have expected text to
proceed in the usual European/Latin order of left to right, top
to bottom. There is no requirement in POSIX.1‐2008 that this be
the case. The specification was deliberately written using words
like ``before'', ``after'', ``first'', and ``last'' in order to
permit implementations to support the natural text order of the
language.
Historically, lines past the end of the edit buffer were marked
with single <tilde> ('~') characters; that is, if the one-based
display was 20 lines in length, and the last line of the file was
on line one, then lines 2-20 would contain only a single '~'
character.
Historically, the vi editor attempted to display only complete
lines at the bottom of the screen (it did display partial lines
at the top of the screen). If a line was too long to fit in its
entirety at the bottom of the screen, the screen lines where the
line would have been displayed were displayed as single '@'
characters, instead of displaying part of the line. POSIX.1‐2008
permits, but does not require, this behavior. Implementations are
encouraged to attempt always to display a complete line at the
bottom of the screen when doing scrolling or screen positioning
by buffer lines.
Historically, lines marked with '@' were also used to minimize
output to dumb terminals over slow lines; that is, changes local
to the cursor were updated, but changes to lines on the screen
that were not close to the cursor were simply marked with an '@'
sign instead of being updated to match the current text.
POSIX.1‐2008 permits, but does not require this feature because
it is used ever less frequently as terminals become smarter and
connections are faster.
Initialization in ex and vi
Historically, vi always had a line in the edit buffer, even if
the edit buffer was ``empty''. For example:
1. The ex command = executed from visual mode wrote ``1'' when
the buffer was empty.
2. Writes from visual mode of an empty edit buffer wrote files
of a single character (a <newline>), while writes from ex
mode of an empty edit buffer wrote empty files.
3. Put and read commands into an empty edit buffer left an empty
line at the top of the edit buffer.
For consistency, POSIX.1‐2008 does not permit any of these
behaviors.
Historically, vi did not always return the terminal to its
original modes; for example, ICRNL was modified if it was not
originally set. POSIX.1‐2008 does not permit this behavior.
Command Descriptions in vi
Motion commands are among the most complicated aspects of vi to
describe. With some exceptions, the text region and buffer type
effect of a motion command on a vi command are described on a
case-by-case basis. The descriptions of text regions in
POSIX.1‐2008 are not intended to imply direction; that is, an
inclusive region from line n to line n+5 is identical to a region
from line n+5 to line n. This is of more than academic interest—
movements to marks can be in either direction, and, if the
wrapscan option is set, so can movements to search points.
Historically, lines are always stored into buffers in text order;
that is, from the start of the edit buffer to the end.
POSIX.1‐2008 requires conformance to historical practice.
Historically, command counts were applied to any associated
motion, and were multiplicative to any supplied motion count. For
example, 2cw is the same as c2w, and 2c3w is the same as c6w.
POSIX.1‐2008 requires this behavior. Historically, vi commands
that used bigwords, words, paragraphs, and sentences as objects
treated groups of empty lines, or lines that contained only
<blank> characters, inconsistently. Some commands treated them as
a single entity, while others treated each line separately. For
example, the w, W, and B commands treated groups of empty lines
as individual words; that is, the command would move the cursor
to each new empty line. The e and E commands treated groups of
empty lines as a single word; that is, the first use would move
past the group of lines. The b command would just beep at the
user, or if done from the start of the line as a motion command,
fail in unexpected ways. If the lines contained only (or ended
with) <blank> characters, the w and W commands would just beep at
the user, the E and e commands would treat the group as a single
word, and the B and b commands would treat the lines as
individual words. For consistency and simplicity of
specification, POSIX.1‐2008 requires that all vi commands treat
groups of empty or blank lines as a single entity, and that
movement through lines ending with <blank> characters be
consistent with other movements.
Historically, vi documentation indicated that any number of
double-quotes were skipped after punctuation marks at sentence
boundaries; however, implementations only skipped single-quotes.
POSIX.1‐2008 requires both to be skipped.
Historically, the first and last characters in the edit buffer
were word boundaries. This historical practice is required by
POSIX.1‐2008.
Historically, vi attempted to update the minimum number of
columns on the screen possible, which could lead to misleading
information being displayed. POSIX.1‐2008 makes no requirements
other than that the current character being entered is displayed
correctly, leaving all other decisions in this area up to the
implementation.
Historically, lines were arbitrarily folded between columns of
any characters that required multiple column positions on the
screen, with the exception of tabs, which terminated at the
right-hand margin. POSIX.1‐2008 permits the former and requires
the latter. Implementations that do not arbitrarily break lines
between columns of characters that occupy multiple column
positions should not permit the cursor to rest on a column that
does not contain any part of a character.
The historical vi had a problem in that all movements were by
buffer lines, not by display or screen lines. This is often the
right thing to do; for example, single line movements, such as j
or k, should work on buffer lines. Commands like dj, or j., where
. is a change command, only make sense for buffer lines. It is
not, however, the right thing to do for screen motion or
scrolling commands like <control>‐D, <control>‐F, and H. If the
window is fairly small, using buffer lines in these cases can
result in completely random motion; for example, 1<control>‐D can
result in a completely changed screen, without any overlap. This
is clearly not what the user wanted. The problem is even worse in
the case of the H, L, and M commands—as they position the cursor
at the first non-<blank> of the line, they may all refer to the
same location in large lines, and will result in no movement at
all.
In addition, if the line is larger than the screen, using buffer
lines can make it impossible to display parts of the line—there
are not any commands that do not display the beginning of the
line in historical vi, and if both the beginning and end of the
line cannot be on the screen at the same time, the user suffers.
Finally, the page and half-page scrolling commands historically
moved to the first non-<blank> in the new line. If the line is
approximately the same size as the screen, this is inadequate
because the cursor before and after a <control>‐D command will
refer to the same location on the screen.
Implementations of ex and vi exist that do not have these
problems because the relevant commands (<control>‐B, <control>‐D,
<control>‐F, <control>‐U, <control>‐Y, <control>‐E, H, L, and M)
operate on display (screen) lines, not (edit) buffer lines.
POSIX.1‐2008 does not permit this behavior by default because the
standard developers believed that users would find it too
confusing. However, historical practice has been relaxed. For
example, ex and vi historically attempted, albeit sometimes
unsuccessfully, to never put part of a line on the last lines of
a screen; for example, if a line would not fit in its entirety,
no part of the line was displayed, and the screen lines
corresponding to the line contained single '@' characters. This
behavior is permitted, but not required by POSIX.1‐2008, so that
it is possible for implementations to support long lines in small
screens more reasonably without changing the commands to be
oriented to the display (instead of oriented to the buffer).
POSIX.1‐2008 also permits implementations to refuse to edit any
edit buffer containing a line that will not fit on the screen in
its entirety.
The display area (for example, the value of the window edit
option) has historically been ``grown'', or expanded, to display
new text when local movements are done in displays where the
number of lines displayed is less than the maximum possible.
Expansion has historically been the first choice, when the target
line is less than the maximum possible expansion value away.
Scrolling has historically been the next choice, done when the
target line is less than half a display away, and otherwise, the
screen was redrawn. There were exceptions, however, in that ex
commands generally always caused the screen to be redrawn.
POSIX.1‐2008 does not specify a standard behavior because there
may be external issues, such as connection speed, the number of
characters necessary to redraw as opposed to scroll, or terminal
capabilities that implementations will have to accommodate.
The current line in POSIX.1‐2008 maps one-to-one to a buffer line
in the file. The current column does not. There are two different
column values that are described by POSIX.1‐2008. The first is
the current column value as set by many of the vi commands. This
value is remembered for the lifetime of the editor. The second
column value is the actual position on the screen where the
cursor rests. The two are not always the same. For example, when
the cursor is backed by a multi-column character, the actual
cursor position on the screen has historically been the last
column of the character in command mode, and the first column of
the character in input mode.
Commands that set the current line, but that do not set the
current cursor value (for example, j and k) attempt to get as
close as possible to the remembered column position, so that the
cursor tends to restrict itself to a vertical column as the user
moves around in the edit buffer. POSIX.1‐2008 requires
conformance to historical practice, requiring that the display
location of the cursor on the display line be adjusted from the
current column value as necessary to support this historical
behavior.
Historically, only a single line (and for some terminals, a
single line minus 1 column) of characters could be entered by the
user for the line-oriented commands; that is, :, !, /, or ?.
POSIX.1‐2008 permits, but does not require, this limitation.
Historically, ``soft'' errors in vi caused the terminal to be
alerted, but no error message was displayed. As a general rule,
no error message was displayed for errors in command execution in
vi, when the error resulted from the user attempting an invalid
or impossible action, or when a searched-for object was not
found. Examples of soft errors included h at the left margin,
<control>‐B or [[ at the beginning of the file, 2G at the end of
the file, and so on. In addition, errors such as %, ]], }, ), N,
n, f, F, t, and T failing to find the searched-for object were
soft as well. Less consistently, / and ? displayed an error
message if the pattern was not found, /, ?, N, and n displayed an
error message if no previous regular expression had been
specified, and ; did not display an error message if no previous
f, F, t, or T command had occurred. Also, behavior in this area
might reasonably be based on a runtime evaluation of the speed of
a network connection. Finally, some implementations have
provided error messages for soft errors in order to assist naive
users, based on the value of a verbose edit option. POSIX.1‐2008
does not list specific errors for which an error message shall be
displayed. Implementations should conform to historical practice
in the absence of any strong reason to diverge.
Page Backwards
The <control>‐B and <control>‐F commands historically considered
it an error to attempt to page past the beginning or end of the
file, whereas the <control>‐D and <control>‐U commands simply
moved to the beginning or end of the file. For consistency,
POSIX.1‐2008 requires the latter behavior for all four commands.
All four commands still consider it an error if the current line
is at the beginning (<control>‐B, <control>‐U) or end
(<control>‐F, <control>‐D) of the file. Historically, the
<control>‐B and <control>‐F commands skip two lines in order to
include overlapping lines when a single command is entered. This
makes less sense in the presence of a count, as there will be, by
definition, no overlapping lines. The actual calculation used by
historical implementations of the vi editor for <control>‐B was:
((current first line) - count x (window edit option)) +2
and for <control>‐F was:
((current first line) + count x (window edit option)) -2
This calculation does not work well when intermixing commands
with and without counts; for example, 3<control>‐F is not
equivalent to entering the <control>‐F command three times, and
is not reversible by entering the <control>‐B command three
times. For consistency with other vi commands that take counts,
POSIX.1‐2008 requires a different calculation.
Scroll Forward
The 4BSD and System V implementations of vi differed on the
initial value used by the scroll command. 4BSD used:
((window edit option) +1) /2
while System V used the value of the scroll edit option. The
System V version is specified by POSIX.1‐2008 because the
standard developers believed that it was more intuitive and
permitted the user a method of setting the scroll value initially
without also setting the number of lines that are displayed.
Scroll Forward by Line
Historically, the <control>‐E and <control>‐Y commands considered
it an error if the last and first lines, respectively, were
already on the screen. POSIX.1‐2008 requires conformance to
historical practice. Historically, the <control>‐E and
<control>‐Y commands had no effect in open mode. For simplicity
and consistency of specification, POSIX.1‐2008 requires that they
behave as usual, albeit with a single line screen.
Clear and Redisplay
The historical <control>‐L command refreshed the screen exactly
as it was supposed to be currently displayed, replacing any '@'
characters for lines that had been deleted but not updated on the
screen with refreshed '@' characters. The intent of the
<control>‐L command is to refresh when the screen has been
accidentally overwritten; for example, by a write command from
another user, or modem noise.
Redraw Screen
The historical <control>‐R command redisplayed only when
necessary to update lines that had been deleted but not updated
on the screen and that were flagged with '@' characters. There is
no requirement that the screen be in any way refreshed if no
lines of this form are currently displayed. POSIX.1‐2008 permits
implementations to extend this command to refresh lines on the
screen flagged with '@' characters because they are too long to
be displayed in the current framework; however, the current line
and column need not be modified.
Search for tagstring
Historically, the first non-<blank> at or after the cursor was
the first character, and all subsequent characters that were word
characters, up to the end of the line, were included. For
example, with the cursor on the leading <space> or on the '#'
character in the text "#bar@", the tag was "#bar". On the
character 'b' it was "bar", and on the 'a' it was "ar".
POSIX.1‐2008 requires this behavior.
Replace Text with Results from Shell Command
Historically, the <, >, and ! commands considered most cursor
motions other than line-oriented motions an error; for example,
the command >/foo<CR> succeeded, while the command >l failed,
even though the text region described by the two commands might
be identical. For consistency, all three commands only consider
entire lines and not partial lines, and the region is defined as
any line that contains a character that was specified by the
motion.
Move to Matching Character
Other matching characters have been left implementation-defined
in order to allow extensions such as matching '<' and '>' for
searching HTML, or #ifdef, #else, and #endif for searching C
source.
Repeat Substitution
POSIX.1‐2008 requires that any c and g flags specified to the
previous substitute command be ignored; however, the r flag may
still apply, if supported by the implementation.
Return to Previous (Context or Section)
The [[, ]], (, ), {, and } commands are all affected by ``section
boundaries'', but in some historical implementations not all of
the commands recognize the same section boundaries. This is a
bug, not a feature, and a unique section-boundary algorithm was
not described for each command. One special case that is
preserved is that the sentence command moves to the end of the
last line of the edit buffer while the other commands go to the
beginning, in order to preserve the traditional character cut
semantics of the sentence command. Historically, vi section
boundaries at the beginning and end of the edit buffer were the
first non-<blank> on the first and last lines of the edit buffer
if one exists; otherwise, the last character of the first and
last lines of the edit buffer if one exists. To increase
consistency with other section locations, this has been
simplified by POSIX.1‐2008 to the first character of the first
and last lines of the edit buffer, or the first and the last
lines of the edit buffer if they are empty.
Sentence boundaries were problematic in the historical vi. They
were not only the boundaries as defined for the section and
paragraph commands, but they were the first non-<blank> that
occurred after those boundaries, as well. Historically, the vi
section commands were documented as taking an optional window
size as a count preceding the command. This was not implemented
in historical versions, so POSIX.1‐2008 requires that the count
repeat the command, for consistency with other vi commands.
Repeat
Historically, mapped commands other than text input commands
could not be repeated using the period command. POSIX.1‐2008
requires conformance to historical practice.
The restrictions on the interpretation of special characters (for
example, <control>‐H) in the repetition of text input mode
commands is intended to match historical practice. For example,
given the input sequence:
iab<control>-H<control>-H<control>-Hdef<escape>
the user should be informed of an error when the sequence is
first entered, but not during a command repetition. The character
<control>‐T is specifically exempted from this restriction.
Historical implementations of vi ignored <control>‐T characters
that were input in the original command during command
repetition. POSIX.1‐2008 prohibits this behavior.
Find Regular Expression
Historically, commands did not affect the line searched to or
from if the motion command was a search (/, ?, N, n) and the
final position was the start/end of the line. There were some
special cases and vi was not consistent. POSIX.1‐2008 does not
permit this behavior, for consistency. Historical implementations
permitted but were unable to handle searches as motion commands
that wrapped (that is, due to the edit option wrapscan) to the
original location. POSIX.1‐2008 requires that this behavior be
treated as an error.
Historically, the syntax "/RE/0" was used to force the command to
cut text in line mode. POSIX.1‐2008 requires conformance to
historical practice.
Historically, in open mode, a z specified to a search command
redisplayed the current line instead of displaying the current
screen with the current line highlighted. For consistency and
simplicity of specification, POSIX.1‐2008 does not permit this
behavior.
Historically, trailing z commands were permitted and ignored if
entered as part of a search used as a motion command. For
consistency and simplicity of specification, POSIX.1‐2008 does
not permit this behavior.
Execute an ex Command
Historically, vi implementations restricted the commands that
could be entered on the colon command line (for example, append
and change), and some other commands were known to cause them to
fail catastrophically. For consistency, POSIX.1‐2008 does not
permit these restrictions. When executing an ex command by
entering :, it is not possible to enter a <newline> as part of
the command because it is considered the end of the command. A
different approach is to enter ex command mode by using the vi Q
command (and later resuming visual mode with the ex vi command).
In ex command mode, the single-line limitation does not exist.
So, for example, the following is valid:
Q
s/break here/break\
here/
vi
POSIX.1‐2008 requires that, if the ex command overwrites any part
of the screen that would be erased by a refresh, vi pauses for a
character from the user. Historically, this character could be
any character; for example, a character input by the user before
the message appeared, or even a mapped character. This is
probably a bug, but implementations that have tried to be more
rigorous by requiring that the user enter a specific character,
or that the user enter a character after the message was
displayed, have been forced by user indignation back into
historical behavior. POSIX.1‐2008 requires conformance to
historical practice.
Shift Left (Right)
Refer to the Rationale for the ! and / commands. Historically,
the < and > commands sometimes moved the cursor to the first
non-<blank> (for example if the command was repeated or with _ as
the motion command), and sometimes left it unchanged.
POSIX.1‐2008 does not permit this inconsistency, requiring
instead that the cursor always move to the first non-<blank>.
Historically, the < and > commands did not support buffer
arguments, although some implementations allow the specification
of an optional buffer. This behavior is neither required nor
disallowed by POSIX.1‐2008.
Execute
Historically, buffers could execute other buffers, and loops,
infinite and otherwise, were possible. POSIX.1‐2008 requires
conformance to historical practice. The *buffer syntax of ex is
not required in vi, because it is not historical practice and has
been used in some vi implementations to support additional
scripting languages.
Reverse Case
Historically, the ~ command ignored any associated count, and
acted only on the characters in the current line. For consistency
with other vi commands, POSIX.1‐2008 requires that an associated
count act on the next count characters, and that the command move
to subsequent lines if warranted by count, to make it possible to
modify large pieces of text in a reasonably efficient manner.
There exist vi implementations that optionally require an
associated motion command for the ~ command. Implementations
supporting this functionality are encouraged to base it on the
tildedop edit option and handle the text regions and cursor
positioning identically to the yank command.
Append
Historically, counts specified to the A, a, I, and i commands
repeated the input of the first line count times, and did not
repeat the subsequent lines of the input text. POSIX.1‐2008
requires that the entire text input be repeated count times.
Move Backward to Preceding Word
Historically, vi became confused if word commands were used as
motion commands in empty files. POSIX.1‐2008 requires that this
be an error. Historical implementations of vi had a large number
of bugs in the word movement commands, and they varied greatly in
behavior in the presence of empty lines, ``words'' made up of a
single character, and lines containing only <blank> characters.
For consistency and simplicity of specification, POSIX.1‐2008
does not permit this behavior.
Change to End-of-Line
Some historical implementations of the C command did not behave
as described by POSIX.1‐2008 when the $ key was remapped because
they were implemented by pushing the $ key onto the input queue
and reprocessing it. POSIX.1‐2008 does not permit this behavior.
Historically, the C, S, and s commands did not copy replaced text
into the numeric buffers. For consistency and simplicity of
specification, POSIX.1‐2008 requires that they behave like their
respective c commands in all respects.
Delete
Historically, lines in open mode that were deleted were scrolled
up, and an @ glyph written over the beginning of the line. In the
case of terminals that are incapable of the necessary cursor
motions, the editor erased the deleted line from the screen.
POSIX.1‐2008 requires conformance to historical practice; that
is, if the terminal cannot display the '@' character, the line
cannot remain on the screen.
Delete to End-of-Line
Some historical implementations of the D command did not behave
as described by POSIX.1‐2008 when the $ key was remapped because
they were implemented by pushing the $ key onto the input queue
and reprocessing it. POSIX.1‐2008 does not permit this behavior.
Join
An historical oddity of vi is that the commands J, 1J, and 2J are
all equivalent. POSIX.1‐2008 requires conformance to historical
practice. The vi J command is specified in terms of the ex join
command with an ex command count value. The address correction
for a count that is past the end of the edit buffer is necessary
for historical compatibility for both ex and vi.
Mark Position
Historical practice is that only lowercase letters, plus
backquote and single-quote, could be used to mark a cursor
position. POSIX.1‐2008 requires conformance to historical
practice, but encourages implementations to support other
characters as marks as well.
Repeat Regular Expression Find (Forward and Reverse)
Historically, the N and n commands could not be used as motion
components for the c command. With the exception of the cN
command, which worked if the search crossed a line boundary, the
text region would be discarded, and the user would not be in text
input mode. For consistency and simplicity of specification,
POSIX.1‐2008 does not permit this behavior.
Insert Empty Line (Below and Above)
Historically, counts to the O and o commands were used as the
number of physical lines to open, if the terminal was dumb and
the slowopen option was not set. This was intended to minimize
traffic over slow connections and repainting for dumb terminals.
POSIX.1‐2008 does not permit this behavior, requiring that a
count to the open command behave as for other text input
commands. This change to historical practice was made for
consistency, and because a superset of the functionality is
provided by the slowopen edit option.
Put from Buffer (Following and Before)
Historically, counts to the p and P commands were ignored if the
buffer was a line mode buffer, but were (mostly) implemented as
described in POSIX.1‐2008 if the buffer was a character mode
buffer. Because implementations exist that do not have this
limitation, and because pasting lines multiple times is generally
useful, POSIX.1‐2008 requires that count be supported for all p
and P commands.
Historical implementations of vi were widely known to have major
problems in the p and P commands, particularly when unusual
regions of text were copied into the edit buffer. The standard
developers viewed these as bugs, and they are not permitted for
consistency and simplicity of specification.
Historically, a P or p command (or an ex put command executed
from open or visual mode) executed in an empty file, left an
empty line as the first line of the file. For consistency and
simplicity of specification, POSIX.1‐2008 does not permit this
behavior.
Replace Character
Historically, the r command did not correctly handle the erase
and word erase characters as arguments, nor did it handle an
associated count greater than 1 with a <carriage-return>
argument, for which it replaced count characters with a single
<newline>. POSIX.1‐2008 does not permit these inconsistencies.
Historically, the r command permitted the <control>‐V escaping of
entered characters, such as <ESC> and the <carriage-return>;
however, it required two leading <control>‐V characters instead
of one. POSIX.1‐2008 requires that this be changed for
consistency with the other text input commands of vi.
Historically, it is an error to enter the r command if there are
less than count characters at or after the cursor in the line.
While a reasonable and unambiguous extension would be to permit
the r command on empty lines, it would require that too large a
count be adjusted to match the number of characters at or after
the cursor for consistency, which is sufficiently different from
historical practice to be avoided. POSIX.1‐2008 requires
conformance to historical practice.
Replace Characters
Historically, if there were autoindent characters in the line on
which the R command was run, and autoindent was set, the first
<newline> would be properly indented and no characters would be
replaced by the <newline>. Each additional <newline> would
replace n characters, where n was the number of characters that
were needed to indent the rest of the line to the proper
indentation level. This behavior is a bug and is not permitted by
POSIX.1‐2008.
Undo
Historical practice for cursor positioning after undoing commands
was mixed. In most cases, when undoing commands that affected a
single line, the cursor was moved to the start of added or
changed text, or immediately after deleted text. However, if the
user had moved from the line being changed, the column was either
set to the first non-<blank>, returned to the origin of the
command, or remained unchanged. When undoing commands that
affected multiple lines or entire lines, the cursor was moved to
the first character in the first line restored. As an example of
how inconsistent this was, a search, followed by an o text input
command, followed by an undo would return the cursor to the
location where the o command was entered, but a cw command
followed by an o command followed by an undo would return the
cursor to the first non-<blank> of the line. POSIX.1‐2008
requires the most useful of these behaviors, and discards the
least useful, in the interest of consistency and simplicity of
specification.
Yank
Historically, the yank command did not move to the end of the
motion if the motion was in the forward direction. It moved to
the end of the motion if the motion was in the backward
direction, except for the _ command, or for the G and ' commands
when the end of the motion was on the current line. This was
further complicated by the fact that for a number of motion
commands, the yank command moved the cursor but did not update
the screen; for example, a subsequent command would move the
cursor from the end of the motion, even though the cursor on the
screen had not reflected the cursor movement for the yank
command. POSIX.1‐2008 requires that all yank commands associated
with backward motions move the cursor to the end of the motion
for consistency, and specifically, to make ' commands as motions
consistent with search patterns as motions.
Yank Current Line
Some historical implementations of the Y command did not behave
as described by POSIX.1‐2008 when the '_' key was remapped
because they were implemented by pushing the '_' key onto the
input queue and reprocessing it. POSIX.1‐2008 does not permit
this behavior.
Redraw Window
Historically, the z command always redrew the screen. This is
permitted but not required by POSIX.1‐2008, because of the
frequent use of the z command in macros such as map n nz. for
screen positioning, instead of its use to change the screen size.
The standard developers believed that expanding or scrolling the
screen offered a better interface for users. The ability to
redraw the screen is preserved if the optional new window size is
specified, and in the <control>‐L and <control>‐R commands.
The semantics of z^ are confusing at best. Historical practice is
that the screen before the screen that ended with the specified
line is displayed. POSIX.1‐2008 requires conformance to
historical practice.
Historically, the z command would not display a partial line at
the top or bottom of the screen. If the partial line would
normally have been displayed at the bottom of the screen, the
command worked, but the partial line was replaced with '@'
characters. If the partial line would normally have been
displayed at the top of the screen, the command would fail. For
consistency and simplicity of specification, POSIX.1‐2008 does
not permit this behavior.
Historically, the z command with a line specification of 1
ignored the command. For consistency and simplicity of
specification, POSIX.1‐2008 does not permit this behavior.
Historically, the z command did not set the cursor column to the
first non-<blank> for the character if the first screen was to be
displayed, and was already displayed. For consistency and
simplicity of specification, POSIX.1‐2008 does not permit this
behavior.
Input Mode Commands in vi
Historical implementations of vi did not permit the user to erase
more than a single line of input, or to use normal erase
characters such as line erase, worderase, and erase to erase
autoindent characters. As there exist implementations of vi that
do not have these limitations, both behaviors are permitted, but
only historical practice is required. In the case of these
extensions, vi is required to pause at the autoindent and
previous line boundaries.
Historical implementations of vi updated only the portion of the
screen where the current cursor character was displayed. For
example, consider the vi input keystrokes:
iabcd<escape>0C<tab>
Historically, the <tab> would overwrite the characters "abcd"
when it was displayed. Other implementations replace only the 'a'
character with the <tab>, and then push the rest of the
characters ahead of the cursor. Both implementations have
problems. The historical implementation is probably visually
nicer for the above example; however, for the keystrokes:
iabcd<ESC>0R<tab><ESC>
the historical implementation results in the string "bcd"
disappearing and then magically reappearing when the <ESC>
character is entered. POSIX.1‐2008 requires the former behavior
when overwriting erase-columns—that is, overwriting characters
that are no longer logically part of the edit buffer—and the
latter behavior otherwise.
Historical implementations of vi discarded the <control>‐D and
<control>‐T characters when they were entered at places where
their command functionality was not appropriate. POSIX.1‐2008
requires that the <control>‐T functionality always be available,
and that <control>‐D be treated as any other key when not
operating on autoindent characters.
NUL
Some historical implementations of vi limited the number of
characters entered using the NUL input character to 256 bytes.
POSIX.1‐2008 permits this limitation; however, implementations
are encouraged to remove this limit.
<control>‐D
See also Rationale for the input mode command <newline>. The
hidden assumptions in the <control>‐D command (and in the vi
autoindent specification in general) is that <space> characters
take up a single column on the screen and that <tab> characters
are comprised of an integral number of <space> characters.
<newline>
Implementations are permitted to rewrite autoindent characters in
the line when <newline>, <carriage-return>, <control>‐D, and
<control>‐T are entered, or when the shift commands are used,
because historical implementations have both done so and found it
necessary to do so. For example, a <control>‐D when the cursor is
preceded by a single <tab>, with tabstop set to 8, and shiftwidth
set to 3, will result in the <tab> being replaced by several
<space> characters.
<control>‐T
See also the Rationale for the input mode command <newline>.
Historically, <control>‐T only worked if no non-<blank>
characters had yet been input in the current input line. In
addition, the characters inserted by <control>‐T were treated as
autoindent characters, and could not be erased using normal user
erase characters. Because implementations exist that do not have
these limitations, and as moving to a column boundary is
generally useful, POSIX.1‐2008 requires that both limitations be
removed.
<control>‐V
Historically, vi used ^V, regardless of the value of the literal-
next character of the terminal. POSIX.1‐2008 requires
conformance to historical practice.
The uses described for <control>‐V can also be accomplished with
<control>‐Q, which is useful on terminals that use <control>‐V
for the down-arrow function. However, most historical
implementations use <control>‐Q for the termios START character,
so the editor will generally not receive the <control>‐Q unless
stty ixon mode is set to off. (In addition, some historical
implementations of vi explicitly set ixon mode to on, so it was
difficult for the user to set it to off.) Any of the command
characters described in POSIX.1‐2008 can be made ineffective by
their selection as termios control characters, using the stty
utility or other methods described in the System Interfaces
volume of POSIX.1‐2017.
<ESC>
Historically, SIGINT alerted the terminal when used to end input
mode. This behavior is permitted, but not required, by
POSIX.1‐2008.
