---

   vi.1p    ( 1 )

---

Обоснование (Rationale)

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.