.
Last update: 1997-05-20
9945-2-64
_____________________________________________________________________________
Topic: ex/vi (part iii)
Relevant Sections: 5.10.7, page 519, lines 1178-1179
Defect Report:
-----------------------
For each of the areas discussed below I believe that the
POSIX wording does not match historic practice.
(1) Extended Description
Section 5.10.7, page 519, lines 1178-1179
Historically, parsing the command line was a bit more complex than
described here.
There are three normal termination cases for an ex command. They
are the end of the string, or unescaped (by literal next characters)
<newline> or '|' characters. Once you get past the addresses, you
can figure out how long the command is. There are three exciting
special cases:
1: The bang, global, vglobal and the filter versions of the read and
write commands are delimited by newlines only (they can contain
shell pipes).
2: The ex, edit and visual in vi mode commands take ex commands as
their first arguments.
3: The substitute command takes an RE as its first argument, and
wants it to be specially delimited.
Historically, '|' characters in the first argument of the ex, edit,
and substitute commands did not delimit the command. And, in the
filter cases for read and write, and the bang, global and vglobal
commands, they did not delimit the command at all.
For example, the following commands were legal:
:edit +25|s/abc/ABC/ file.c
:substitute s/|/PIPE/
:read !spell % | columnate
:global/pattern/p|l
It's not quite as simple as it sounds, however. The command:
:substitute s/a/b/|s/c/d|set
was also legal, i.e. the historic ex parser (using the word loosely,
since "parser" implies some regularity of format) delimited the RE's
based on its delimiter and not anything so irretrievably vulgar as
a command syntax. However, the delimiter had to be nonalphanumeric,
so it was possible to detect commands like "sgc" which were also
permitted.
Once these special cases were handled, the rest of the command
parsing happened pretty much as described by the standard.
Suggestion:
Conform to historic practice.
There was no way to escape any character in the +cmd argument,
as the historic vi ignored all escape characters in that area.
Fix this by allowing literal next characters to escape
whitespace characters.
(2) Addressing
Section 5.10.7.1, page 520, lines 1197
Addressing
Section 5.10.7.1, page 520, lines 1204
Historically, the RE could be empty, i.e. "//" was a valid
address, and the last RE was used.
Historically, the form "\/" and "\?" were equivalent to
"//" and "??".
Suggestion:
Conform to historic practice.
(3) Addressing
Section 5.10.7.1, page 520, lines 1224
Command Descriptions
Section 5.10.7.2, page 521, lines 1241-1252
Historically, a bunch of the ex commands could be given an address
of 0, and/or % could be used in an empty file.
Suggestion:
Conform to historic practice.
(4) Command Descriptions
Section 5.10.7.1, page 521, line 1236
Historical practice is that commands with counts were permitted
to go past the end of file. For example, if the file only has
5 lines, the ex command 1,6> fails, but the command >300 succeeds.
Suggestion:
Conform to historic practice.
(5) Command Descriptions
Section 5.10.7.2, page 521, line 1238
Historically, whatever the terminal reprint character was, could
be entered and it caused ex to repaint the current line.
Suggestion:
Conform to historic practice.
(6) Command Descriptions
Section 5.10.7.2, page 521, lines 1242
The wording after range that permits multiple addresses applies to
the specification of a line as well as a range. The command "3,5,8="
works historically, using 8 as the command address.
Suggestion:
Conform to historic practice.
(7) Command Descriptions
Section 5.10.7.2, page 521, lines 1253
Historic ex/vi permitted commands with counts to go past EOF.
So, for example, if the file only had 5 lines, the ex command
"1,6>" would fail, but the command ">300" would succeed.
Suggestion:
Conform to historic practice.
(8) Command Descriptions
Section 5.10.7.2, page 521, lines 1255-1266
The current standard requires that all '+' and '-' offsets follow the
flags. Historic practice for dealing with flags in vi was bizarre, at
best. As an example, the command ":3+++p--#" prints the SIXTH line of
the file, with a leading number. This means that the '#' flag and the
'+' offsets were recognized and the '-' offsets were not. Regardless,
it was not historically required that offsets come after the flags.
Suggestion:
As the flags and offsets are unambiguous, document the '+'
and '-' offsets as flags, and require that they be handled
in any order.
(9) Command Descriptions
Section 5.10.7.2, page 523, line 1309
Historically, if both a count and range were specified, the offset
was from the LAST address, not the first. The offset in the case
was inclusive, so ":2,5c7" changes line 5 and 6 others. There is
one exception to this, the join command, for which the offset was
NOT inclusive, so the command "2,3join3" joins 3 lines, not 2.
Suggestion:
Conform to historic practice.
(10) Command Descriptions
Section 5.10.7.2, page 523, line 1313
Historically, if only a line or range was specified while in
visual mode, vi just moved to the line.
Suggestion:
Conform to historic practice.
(11) Command Descriptions
Section 5.10.7.2, page 523, lines 1316-1317
Historically, the line number was incremented THEN the line was
displayed.
Suggestion:
Conform to historic practice.
(12) Command Descriptions
Section 5.10.7.2, page 523, lines 1319
Historically, the substitute command was pretty much a special
case from beginning to end. For example, "sgc3p" was a legal
ex command.
Suggestion:
Conform to historic practice.
(13) abbrev
Section 5.10.7.2.1, page 523, lines 1328
Historically, `word' could contain non-word characters, but it was
impossible to make the abbreviation fire, i.e. you could enter
":ab ;ab AB"
as an abbreviation command, but you could never get it to work
because the ';' character wasn't part of a "word".
Suggestion:
It would be possible to permit non-word characters in the word,
but that would require some seriously nasty data structures
in the implementation to avoid quadratic performance, as
you'd have to search for a matching string, from the end of
the string, on each character. Not pretty. It's also a bit
tricky to explain, since you probably don't want to permit
this to work for white space characters.
I'd suggest conforming to historic practice, but requiring an
error message if the user tries to enter an abbreviation with
an illegal character in word.
(14)edit
Section 5.10.7.2.8, page 525, line 1389
Extended Description
Section 5.10.7, page 519, lines 1178-1179
Historically, the "[+line]" could be any ex command, not just
an address.
It is not historic practice for the /pattern command to start
searching from the beginning of the file. The +cmd commands
were always executed with the current line set to the last line
of the file. To make vi conform to the current spec, the +cmd
would have to be run through the ex parser -- consider what
has to happen when the user enters "+s/foo/bar|/pattern" as the
+cmd field. It's not going to be pretty.
It is historic practice that additional commands appended to the
edit command (e.g. "edit file|/pattern") were executed from the
first line in the file, and not the last.
To sum up, the "/pattern" search will work if the wrapscan option
is set or if it's appended to the command instead of being entered
as a +cmd option.
Suggestion:
Conform to historic practice.
(15) join
Section 5.10.7.2.12, page 526, line 1439
Historically, counts to ex commands were (last address + count - 1).
To join, it was (last address + count).
Suggestion:
Conform to historic practice.
(16) map
Section 5.10.7.2.14, page 527, line 1458
Historic practice is that keys which map to themselves are returned
without further remapping, e.g. ":map n nz." is a legal mapping and
will not loop infinitely.
Suggestion:
Conform to historic practice.
(17) move
Section 5.10.7.2.16, page 527, line 1487
Historically, a target line of 0 placed the lines at the beginning of
the file.
Suggestion:
Conform to historic practice.
(18) next
Section 5.10.7.2.17, page 527, line 1491
Historically, the :next command took an ex command preceded by a plus
sign, similar to the edit commands.
Suggestion:
Conform to historic practice.
(19) number
Section 5.10.7.2.18, page 527, line 1507
Historically, the format was "%6d " (that's TWO spaces). Neither
tabs nor a sign were used.
Suggestion:
Conform to historic practice.
(20) Quit
Section 5.10.7.2.23, page 528, line 1539
wq
Section 5.10.7.2.37, page 532, line 1673
xit
Section 5.10.7.2.38, page 532, line 1539
ZZ
Section 5.35.7.1.87, page 654, line 5859
Historically, quit, wq, ZZ and xit wouldn't quit if there were more
files to edit, unless the force option was given or any combination
of them were entered twice without any intervening commands.
Suggestion:
Conform to historic practice.
(21) Recover
Section 5.10.7.2.25, page 529, line 1557
The recover command historically took a force flag which behaved
as other vi force flags. The wording about "if the current buffer
has been modified ..." should be duplicated for :recover. Autowrite
did not affect :recover.
Suggestion:
Conform to historic practice.
(22) substitute
Section 5.10.7.2.30, page 530, line 1596
The delimiter of a substitute command could be any non-alphanumeric
character.
Historic ex accepted any of the following forms:
:s/abc/def/ change "abc" to "def"
:s/abc/def change "abc" to "def"
:s/abc/ delete "abc"
:s/abc delete "abc"
If the pattern string was empty, the last RE specified to any
command was used, not just the last substitution RE.
Historically, substitute commands set the search direction.
In historic System V, if the entire replacement pattern was %,
the last replacement pattern was used.
There is no explanation of quoting in the substitute command.
Generally, escapes in the command were only interesting if
they escaped special characters. This means that "s/A/\\\\f"
replaced "A" with "\\f".
Suggestion:
Conform to historic practice.
(23) visual
Section 5.10.7.2.36, page 531, line 1661
Historically, :visual was different if executed while in visual
mode than if executed while in ex mode.
In visual mode, it was equivalent to "edit[!] [+cmd] [file]".
Suggestion:
Conform to historic practice.
(24) Escape
Section 5.10.7.2.41, page 533, line 1724
Historically, the program named by the shell option was run with
the -c flag followed by the rest of the arguments as a single argv
entry. The SHELL environment variable doesn't enter the picture
other than as the initial value of the shell option.
Historically, the line was set to the first line of the range if a
range was specified, e.g. "3,5!date" while on line 10 changes the
current line to 3.
Suggestion:
Conform to historic practice.
(25) Shift left
Section 5.10.7.2.42, page 534, line 1742
Shift right
Section 5.10.7.2.43, page 534, line 1748
Historically, the < and > characters could be repeated to shift left
or right a specific number of indentation levels.
Suggestion:
Conform to historic practice.
(26) Shift left
Section 5.10.7.2.42, page 534, line 1742
Shift right
Section 5.10.7.2.43, page 534, line 1748
The shift command in historic ex had the usual bizarre collection
of cursor semantics. If called from vi, the cursor was repositioned
to the first non-blank character of the lowest numbered line shifted.
If called from ex, the cursor was repositioned to the first non-blank
of the highest numbered line shifted.
Suggestion:
If the cursor isn't part of the set of lines that are moved,
move it to the first non-blank of the last line shifted. (This
makes ":3>>" in vi work reasonably.) If the cursor is part of
the shifted lines, it doesn't get moved at all. This permits
shifting of marked areas, i.e. ">'a." shifts the marked area
twice, something that couldn't be done with historic vi.
(27) Edit Options
Section 5.10.7.5, page 536 1817
Historically, whitespace characters in set commands were protected
by backslashes.
Suggestion:
Conform to historic practice.
(28) list
Section 5.10.7.5.7, page 537 1886
Historically, the list option only affected tab characters and
the end-of-line display. More specifically, when entering an
ex command in visual mode, it only affected tab characters.
Suggestion:
Conform to historic practice.
(29) report
Section 5.10.7.5.16, page 539 1936
Historically, yanks (which don't modify lines) were also reported
by the editor. In addition, the test for yanked lines was >=, not
> as it was for everything else.
Suggestion:
Laugh hysterically and conform to historic practice.
(30) wrapmargin
Section 5.10.7.5.30, page 541 2012
Historically, if the user entered a <blank> which caused the
lines to split, and then entered a <space>, it was discarded.
Suggestion:
Conform to historic practice.
(31) Asynchronous Events
Section 5.35.5.4, page 627, lines 4835-4837
Historic practice was that the buffer was saved unless a COMPLETE
write had been accomplished, i.e. the whole file had to have been
written, not just part of it. I'm also confused why there's any
reference here to the 'e' command.
This problem is repeated throughout the standard, basically, any ex or
vi command (e.g. :edit, ZZ, etc.) that discusses whether or not a file
is written, if it's been modified, needs to be changed.
Suggestion:
Change all of these to say something like "if the file
has been modified since it was last completely written...",
and add something that defines a "complete write".
(32) Vi Command Descriptions
Section 5.35.7.1, page 629, lines 4904
I think that the current column is documented badly. The line is
documented as a physical line, i.e. there's no attempt to describe that
a "current line" may change because of an 'l' command on a line that
wraps. The column, however, is documented as a logical column, i.e.
the actual column on the screen that the cursor is on instead of the
character it is on. The confusion for me comes as a result of it not
being documented that the column is longer than a screen line.
For example, in the <control-H> command (page 634, line 5117) note
that the Synopsis paragraph says that the cursor moves "back count
characters", but the "Current column" paragraph says that the column
is set to "column - the number of columns occupied by count characters".
Note: I believe that the specification currently is correct in this
regard, this change does not have to be made. But, I think that it
would be significantly simpler and clearer to describe the column in
terms of the character that the cursor sits on, not the column number.
Suggestion:
Reword the command descriptions that describe the column
in terms of the character that the cursor is on.
What I don't believe is documented correctly is that if the line changes,
for, say, the 'j' command, the "current column" may change too, and the
standard doesn't acknowledge this. (Line 5135, the 'j' command states
that the current column is unchanged.) The problem is if you have the file:
ABCDEFGH
foo^Abar
with the cursor on the 'D', and you enter the 'j' command. Because
of the display rules, the cursor must move to either the 'o' in "foo"
or the A in "^A". The specification currently doesn't handle this.
In nvi, there's the concept (in the documentation) of a "most attractive"
cursor position. What happens is that when the cursor is forced to
change lines, it tries to get as close as possible to the previous
logical column, which is a function of the screen column and line wrap.
This seems to work well.
(33) Vi Command Descriptions
Section 5.35.7.1, page 630, lines 4956-4964.
The current vi specification is a bit confusing on the relationship
between the numeric, unnamed and user specified buffers. The reason
for this confusion was that historic vi (stupidly) tossed the contents
of the unnamed buffer after just about every operation. For example,
if you do `"add|p', you can recover the delete, but in `"add|"ap|p',
the put of the unnamed buffer will fail. However, more to the point,
note that the commands `"add|p', `"add|"ap', and `"add|"1p' all recover
the deleted line.
In addition, the current vi specification requires that any and all
deleted text be placed into the numeric buffers. Historic practice
was that deleted text was only placed in numeric buffers if AT LEAST
one line was deleted from the file or the change/delete crossed a line
boundary.
Suggestion:
The way to document this is that if the user specifies a buffer,
the text is copied into it. If the delete is a line or if it
crosses a line boundary, it is placed into both the unnamed
buffer and the numeric buffers. Don't document that historic
vi tossed the unnamed buffer every chance it got, it's a bug,
not a feature.
(34) Vi Command Descriptions
Section 5.35.7.1, page 630, lines 4960-4971.
The current vi specification disallows users from entering text into the
numeric buffers. Historic practice was that this was permitted, although,
to be fair, vi could then be convinced to do genuinely strange things.
(It behaved differently if you deleted text than if you yanked text; in
the latter case, the text was appended to the buffer instead of
replacing the contents.)
Suggestion:
Specify that numeric buffers be treated no differently than
any other buffer when specified by users. Document that the
buffer rotation happen before the replacement of, or the
appending to, of the buffer's contents.
(35) Vi Command Descriptions
Section 5.35.7.1, page 631, lines 4989-4999.
The current vi specification requires that motion regions be "from the
current cursor position to just before the cursor position indicated by
the motion command." This doesn't work for backward motions. Historic
practice was that the region was from the earliest cursor position in
the file, (regardless of whether that was the starting cursor position
or the one indicated by the motion command) to just before the later
cursor position. Naturally, there were some special cases where this
wasn't true, but that's the general rule. As an example, note the
commands "fgdTc" on the string "abcdefg" or the commands "fgd?c" on the
same string.
In addition, historic practice had several special cases for motion
commands. For example, "dl" succeeds when the cursor is on the last
character of the line, and, obviously "l" fails.
Suggestion:
Conform to historic practice.
(36) Vi Command Descriptions
Section 5.35.7.1, page 631, lines 4995-4998.
The determination of whether or not a command affected "lines" was
actually a lot trickier than is described here. (It's bad enough that
nvi does it on a command-by-command basis -- I was unable to construct
general rules that were close enough to historic practice.)
As a single example, consider searches as a motion component. The
standard notes (page 642, line 5402) that a delta to the search makes
it line oriented. However, it doesn't note that:
+ searches that start and end at the first column of a
line become line mode operations.
+ backward searches starting at column 0, and forward
searches ending at column 0 are corrected to the last
column of the previous line.
Note also that forward and backward searches can occur (based on
the wrapscan option) for any search command.
Suggestion:
Document on a command-by-command basis what can cause
motions to become line oriented.
(37) Vi Command Descriptions
Section 5.35.7.1, page 631, lines 5000-5012.
I don't believe that <control-B>, <control-D>, <control-E>, <control-F>,
<control-T>, <control-U>, or <control-Y> were historical cursor motion
commands.
I do believe that +, _ and h were historical cursor motion commands.
Suggestion:
Delete the first set, add the second set.
(38) Vi Command Descriptions
Section 5.35.7.1, page 631, lines 5013-5015
This paragraph doesn't fully describe historic practice. In commands
that take motion arguments, any count provided was applied to the motion
command, e.g. "2cw" was identical to "c2w". If counts were provided
for both commands, the effect was multiplicative, e.g. "4cw" is
identical to "2c2w".
Suggestion:
Conform to historic practice.
(39) Vi Command Descriptions
Section 5.35.7.1, page 632, lines 5024-5025
I don't believe that <form-feed> characters were traditional section
delimiters (I tested 4BSD and SunOS 4.1).
Suggestion:
I don't really object if it's useful, but I don't think it's
widespread historic practice.
(40) Vi Command Descriptions
Section 5.35.7.1, page 632, lines 5036
Allowing any number of double quotes is actually not historic practice,
although it IS historical documentation. Allowing any number of single
quotes is both historic practice and documentation.
Suggestion:
Add single quotes to the list. Note in the Rationale
that POSIX is requiring that the documentation be
supported.
(41) Vi Command Descriptions
Section 5.35.7.1, page 632, lines 5041-5048.
This paragraph doesn't fully describe historic practice. Words were
delimited by the beginning of the file as well as the end. (The
bigword definition gets it right, incidentally.)
Suggestion:
Conform to historic practice.
(42) Vi Command Descriptions
Section 5.35.7.1, page 632, lines 5053-5056
You don't want to scroll if it's (window - 1) lines away, only if it's
half a screen or less. Historic vi would repaint at far less
provocation than this states. In 4BSD's vi, a 9 line movement at the
bottom of a 32 line screen was sufficient, and in SunOS 4.1, a 12 line
movement in the bottom of a 31 line screen was sufficient. This is also
terminal/hardware specific. It can be faster to clear and repaint the
screen than to scroll the terminal, particularly over slow lines.
Suggestion:
Reword this to leave it up to the implementation, but
suggest that window / 2 be scrolled.
(43) Vi Command Descriptions
Section 5.35.7.1, page 632, lines 5059-5064
Historic practice as to whether or not a motion command failed at the
top or bottom of the screen was very command specific. There aren't
any general rules that you can specify. For example, <control-U> fails
if the cursor is on line 1 of the file, but succeeds if the cursor is
on line 2. For most movements, the end/beginning of the file was a
movement sink, but it was an error if the cursor was already there.
An even worse example: the ]] command fails if it's on the last line of
the file. The } command SUCCEEDS on the last line and moves to the last
character of the last line, only failing if it's already on the LAST
CHARACTER of the last line. This behavior is mirrored on the first line
of the file with the reverse directions of these commands, by-the-way.
Suggestion:
Specify the motion failure modes on a command-by-command
basis.
(44) Move cursor backwards
Section 5.35.7.1.6, page 634, lines 5118
Scroll backwards
Section 5.35.7.13, page 635, line 5169
Delete word
Section 5.35.7.1.15, page 636, line 5187
Historically, the erase commands could not erase autoindent characters
(or characters inserted using the <control-T> command). This is a good
change, and should be permitted.
Suggestion:
Note in the Rationale that the erase commands are now permitted
to erase any character, no matter how it was entered. Change
the specification to permit implementations to NOT erase any
autoindent characters or characters inserted using <control-T>.
(45)
Replace text with results from shell command
Section 5.35.7.1.9, page 637, lines 5238
Historic practice is to use the contents of the shell option,
not the SHELL environment variable.
Suggestion:
Conform to historic practice.
(46)
Move forwards with tabs
Section 5.35.7.1.12, page 635, lines 5164-5166
Historically, <control-T> only worked if nothing other than auto-indent
characters were in the line, similar to <control-D> erasure. The change
IS CORRECT, and should be retained.
Suggestion:
Note the change in the Rationale.
(47)
Replace text with results from shell command
Section 5.35.7.1.9, page 637, lines 5238
Historic practice is to use the contents of the shell option,
not the SHELL environment variable.
Suggestion:
Conform to historic practice.
(49)
Move forwards with tabs
Section 5.35.7.1.12, page 635, lines 5164-5166
Historically, <control-T> only worked if nothing other than auto-indent
characters were in the line, similar to <control-D> erasure. The change
IS CORRECT, and should be retained.
Suggestion:
Note the change in the Rationale, and that it was deliberate.
(50)
Move forwards with tabs
Section 5.35.7.1.12, page 635, lines 5164-5166
Historically, <control-T> didn't move forward shiftwidth characters,
but moved to the next shiftwidth column boundary.
Suggestion:
Conform to historic practice.
(51)
Scroll backwards
Section 5.35.7.1.13, page 635, line 5169
Historically, <control-U> in text input mode erased the current line.
Suggestion:
Conform to historic practice.
(52)
Return to previous context (at beginning of line)
Section 5.35.7.1.23, page 639, line 5292
Return to previous context
Section 5.35.7.1.24, page 639, line 5306
Historic practice was that the commands '` and `' worked, too.
Suggestion:
Conform to historic practice.
(53)
Move back to beginning of sentence
Section 5.35.7.1.28, page 640, lines 5345
Move forwards to beginning of sentence
Section 5.35.7.1.29, page 640, lines 5351
Move back to preceding paragraph
Section 5.35.7.1.30, page 640, lines 5357
Move forwards to next paragraph
Section 5.35.7.1.31, page 641, lines 5365
There's no discussion of how empty lines work with (, ), { and }.
Suggestion:
Match historic practice, documenting that groups of empty
lines count as a single sentences and paragraphs.
(54)
Move backwards to preceding word
Section 5.35.7.1.47, page 645, line 5509
Move backwards to preceding bigword
Section 5.35.7.1.47, page 645, line 5521
Move to end-of-word
Section 5.35.7.1.53, page 646, line 5564
Move to end-of-bigword
Section 5.35.7.1.54, page 647, line 5576
Move to beginning of word
Section 5.35.7.1.80, page 653, line 5796
Move to beginning of bigword
Section 5.35.7.1.81, page 653, line 5807
The current specification says that for all word commands, an
empty/blank line is considered to contain exactly one word.
This is not historic practice, although historic practice was far from
consistent. In historic vi, the 'w', 'W' and 'B' commands would treat
groups of empty lines as individual words, i.e. the command would move
the cursor to each new empty line. The 'e' and 'E' commands would treat
groups of empty lines as a single word, i.e. the first use would move
past the group of lines. The 'b' command would just beep at you, or,
if you did it from the start of the line as part of a motion command,
go absolutely nuts. If the lines contained only white-space characters,
the 'w' and 'W' commands would just beep at you, and the 'B', 'b', '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.
Suggestion:
Since some of the commands already treat groups of empty lines
and whitespace only lines as a single word, and the (, ), {, and
} commands behave that way, too, and it's probably more useful
to users that groups of empty lines be skipped, change the standard
to require that empty lines, or lines with only whitespace characters
are treated as a single word. Note the change in the Rationale.
(This is the way that nvi behaves, incidentally, and I've had no
complaints so far.)
(55)
Vi Command Descriptions
Section 5.35.7.1, page 633, line 5069-5078
These rules are not historically correct. For example, "dl "
is permitted at the end of a line. My guess is that the only
thing that can be done is to describe the boundary cases on
a command-by-command basis. (That's how it had to be implemented.)
Suggestion:
Conform to historic practice.
(56)
Vi Command Descriptions
Section 5.35.7.1.1, page 633, line 5079
Vi Command Descriptions
Section 5.35.7.1.4, page 634, line 5104
The ^B and ^F calculations are not historically correct.
The correct ^F calculation is:
top_line = top_line + count * text_rows - 2;
The correct ^B calculation is:
top_line = (top_line - count * text_rows) + 2;
A simpler approach is to note that both ^B and ^F scroll:
count * text_rows - 2
lines.
Suggestion:
Conform to historic practice.
(57)
Vi Command Descriptions
Section 5.35.7.1.27, page 640, line 5340
Historically, the ^ command took a count which it then ignored.
Suggestion:
Conform to historic practice.
(58)
Vi Command Descriptions
Section 5.35.7.1.32, page 641, line 5378
Historically, the | command was placed on the character that
spanned the column, not the one following it.
Suggestion:
Conform to historic practice.
(59)
Vi Command Descriptions
Section 5.35.7.1.36, page 642, line 5403
Vi Command Descriptions
Section 5.35.7.1.42, page 644, line 5466
Historically, both / and ? took counts.
Suggestion:
Conform to historic practice.
(60)
Vi Command Descriptions
Section 5.35.7.1.43, page 644, line 5470
Historic practice was that <newlines> were (logically) added
to each line in a line oriented buffer, and to all but the last
line of a character oriented buffer. For example, if buffer a
contained the following:
:3p|4p
:5p
cut with "ay6w, the 3p and 4p are executed, and the cursor waits
after the 5p has been displayed on the colon command line.
Suggestion:
Conform to historic practice.
(61)
Vi Command Descriptions
Section 5.35.7.1.86, page 654, line 5848
The z command historically had '+' and '^' arguments.
The '+' character was the same as <newline> if count1 was specified,
otherwise, it displayed the next screen after the current one, like
^F, with the exception that there was no overlap between the screens.
The '^' character displayed the screen after the screen with count1
on the bottom line, if count1 was specified, otherwise, it displayed
the screen after the current one, like ^B, with the exception that
there was no overlap between the screens.
Suggestion:
Conform to historic practice, or, note that those characters
shouldn't be used for other extensions.
WG15 response for 9945-2:1993
-----------------------------------
Q1:
The standard states rules and behavior for the ex parser, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q2:
The standard clearly states that a null BRE (//) shall be equivalent to the
last BRE encountered, and conforming implementations must conform to this.
Q3:
The standard states the behavior for addressing in ex, and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.
Q4:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q5:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q6:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q7:
The request is substantially identical to interpretation #Q4 (above), and the
resolution of that interpretation applies in this case.
Q8:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q9:
The standard states the behavior for ranges and counts in ex, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q10:
The standard states the implied behavior when only a line or range is specified
in ex, and conforming implementations must conform to this. However,
concerns have been raised about this which are being referred to the sponsor.
Q11:
The standard states the sequence of behavior when no range or count is
specified and the command line is a blank line, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q12:
The standard clearly states the syntax when a object follows the command name,
and conforming implementations must conform to this.
Q13:
The standard clearly states the behavior for word in the abbrev command, and
conforming implementations must conform to this. Concerns about this issue
are being referred to the sponsor.
Q14:
The standard states the behavior for the '[+line]', '/pattern', '?pattern',
and appended command execution, and conforming implementations must conform
to this. However, concerns have been raised about this which are being
referred to the sponsor.
Q15:
The standard states the behavior for counts in the ex command, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q16:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q17:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q18:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q19:
The standard states the format for number, and conforming implementations must
conform to this. However, concerns have been raised about this which are
being referred to the sponsor.
Q20:
The standard states the behavior for quit in ex, and conforming implementations
must conform to this. However, concerns have been raised about this which
are being referred to the sponsor.
Q21:
The standard states the syntax for the recover command, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q22:
paragraph 1)
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
paragraph 2)
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
paragraph 3)
The standard states the pattern to use if the pattern string is empty, and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.
paragraph 4)
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
paragraph 5)
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
paragraph 6)
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q23:
The standard states the behavior for the visual command, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q24:
paragraph 1)
The standard states the relationship between escape and SHELL, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
paragraph 2)
The standard states the behavior for escape and ranges, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q25:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q26:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q27:
The standard clearly states on page 529 line 1582 that any <blank>s in
strings can be included as is by preceding each such character with a
backslash, and conforming implementations must conform to this.
Q28:
The standard clearly states the behavior for list, and conforming
implementations must conform to this.
Q29:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q30:
The standard states the effect defined for wrapmargin ,and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.
Q31:
The standard is unclear on this issue, and no conformance distinction can
be made between alternative implementations based on this. This is being
referred to the sponsor.
Q32:
The standard is unclear on this issue, and no conformance distinction can
be made between alternative implementations based on this. This is being
referred to the sponsor.
Q33:
The standard states the behavior of numeric buffers, and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.
Q34:
The standard clearly states that "text cannot be placed directly into
the numbered buffers, and conforming implementations must conform to this.
Q35:
The standard states the behavior of the motion argument, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q36:
The standard states the rules for determining the range of "lines" which
will be affected by commands, and conforming implementations must conform
to this. However, concerns have been raised about this which are being
referred to the sponsor.
Q37:
The standard states that <control-B>, <control-D>, <control-E>, <control-F>,
<control-T>, <control-U>, <control-Y>, +, and _ are cursor motion commands,
and conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor.
Q38:
The standard is unclear on this issue, and no conformance distinction can
be made between alternative implementations based on this. This is being
referred to the sponsor.
Q39:
The standard states that a <form-feed> character is a section delimiter, and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.
Q40:
The standard states that any number of double-quote characters are allowed,
and conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor.
Q41:
The standard states the definition for word, and conforming implementations
must conform to this. However, concerns have been raised about this which
are being referred to the sponsor.
Q42:
The standard states rules for scrolling within vi, and conforming
implementations must conform to this. However, concerns have been
raised about this which are being referred to the sponsor.
Q43:
The standard states the rules for motion, and conforming implementations
must conform to this. However, concerns have been raised about this which
are being referred to the sponsor.
Q44:
The standard clearly states the behavior for delete word, and conforming
implementations must conform to this.
Q45:
The standard states that the SHELL environment variable is to be used, and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.
Q46:
The standard clearly states the behavior for <control-T>, and conforming
implementations must conform to this.
Q47:
The request is substantially identical to interpretation #Q45 (above), and the
resolution of that interpretation applies in this case.
Q49:
The request is substantially identical to interpretation #Q46 (above), and the
resolution of that interpretation applies in this case.
Q50:
The standard states that the cursor is to be moved forwards shiftwidth
positions, and conforming implementations must conform to this. However,
concerns have been raised about this which are being referred to the sponsor.
Q51:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q52:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q53:
The standard states the behavior for areas of text in the sentence and
paragraph descriptions on page 632, and conforming implementations must
conform to this. However, concerns have been raised about this which are
being referred to the sponsor.
Q54:
The standard states that an empty or blank line shall be considered to
contain exactly one word, and conforming implementations must conform to
this. However, concerns have been raised about this which are being
referred to the sponsor.
Q55:
The standard states the rules for handling position exceptions, and
conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor.
Q56:
The standard states the calculations for <control-B> and <control-F>, and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.
Q57:
The standard clearly states the definition for the ^ command, and conforming
implementations must conform to this. Concerns about this issue are being
referred to the sponsor.
Q58:
The standard states that the cursor shall be placed on the character following
the count-th column position, and conforming implementations must conform to
this. However, concerns have been raised about this which are being
referred to the sponsor.
Q59:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Q60:
The standard states the behavior for <newlines> and buffers, and conforming
implementations must conform to this. However, concerns have been raised
about this which are being referred to the sponsor.
Q61:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
Rationale for Interpretation:
-----------------------------
None.
_____________________________________________________________________________