WG15 Defect Report Ref: 9945-2-63
Topic: ex/vi (part ii)


This is an approved interpretation of 9945-2:1993.

.

Last update: 1997-05-20


								9945-2-63

 _____________________________________________________________________________

	Topic:			ex/vi (part ii)
	Relevant Sections:	5.10.7.2.30, page 530, line 1596


Defect Report:
-----------------------


(From: bostic@vangogh.CS.Berkeley.EDU (Keith Bostic))

For each of the areas discussed below, I believe that,
although the standard matches historic practice, historic
practice is flawed and that the POSIX standard precludes
superior (i.e. reasonable) implementations.


(1) Command Descriptions
	Section 5.10.7.2.30, page 530, line 1596

The current specification requires that when the substitution is
done in visual mode, that the line be redisplayed, with carat
characters writting underlying the about-to-be-changed string.
This is an horrendous user interface, requiring that vi not provide
the user any context other than the single line, and requiring
that the screen be repainted after the changes are made.  In 
addition, it's going to be almost impossible in this model to
display changes for search patterns that cross <newline> boundaries.
Ex doesn't even get confirmation of changes to the space between
the last character on the line and the end-of-line right now!

Suggestion:
	Permit implementations to do something reasonable.


(2) Output Files
	Section 5.35.6.3, page 628, lines 4849-4851

It's reasonable to permit vi to add the <newline> when the user writes
the file, it's unreasonable to require it.  Admittedly, the standard
does not describe what happens when vi edits a non-text file, but the
wording here would require vi to decide if a file was a text file and
THEN add a <newline> if it was, and not add one if it wasn't.
Otherwise, when vi edits a binary, it has to add an extra character.

Suggestion:
	Allow the extra character, but do not require it.

(3) Vi Command Descriptions
	Section 5.35.7.1, page 630, lines 4960-4961.

The current specification requires that the numbered buffers only be
available from visual mode.  This isn't necessary.  The reason you
can't get to the numeric buffers from ex mode is that the commands
like "d2" are ambiguous, since the 'd' command takes an optional count.
If someone wants to make numeric buffers available from ex, that's
okay by me, as long as they don't break ex's current syntax.

Suggestion:
	Delete this sentence, it doesn't add anything to the standard.


(4) Page backwards
	Section 5.35.7.1.1, page 633, line 5079
Scroll forwards
	Section 5.35.7.1.2, page 633, line 5087
Scroll forwards by line
	Section 5.35.7.1.3, page 633, line 5095
Page forward
	Section 5.35.7.1.4, page 634, line 5104
Scroll backwards
	Section 5.35.7.1.13, page 635, line 5169
Scroll backwards
	Section 5.35.7.1.16, page 636, line 5196
Move to top of screen
	Section 5.35.7.1.58, page 648, line 5611
Move to bottom of screen
	Section 5.35.7.1.62, page 649, line 5646
Move to middle of screen
	Section 5.35.7.1.64, page 649, line 5661

The historic vi had a problem in that all movements were by physical
lines, not by logical (i.e. screen) lines.  Arguments can be made that
this is the right thing to do.  For example, single line movements,
such as 'j' or 'k', should work on physical lines.  Commands like "dj",
or "j.", where '.' is a change/delete command, make more sense for
physical lines than they do for logical lines.

These arguments, however, don't apply to scrolling commands like
<control-D> and <control-F> -- when the window is fairly small (a
console window, for example), using physical lines can result in a
half-page scroll repainting the entire screen, which is not what the
user wanted.  Second, if the line is larger than the screen, using
physical lines can make it IMPOSSIBLE to display parts of the line --
there aren't any commands that don't display the beginning of the line
in historic vi, and if both the beginning and end of the line can't be
on the screen at the same time, you lose.  This is even worse in the
case of the H, L, and M commands -- for large lines, they will ALL
refer to the same line, which results in no movement at all.

Another issue is that page and half-page scrolling commands historically
moved to the first non-blank character in the new line.  If the line is
approximately the same size as the screen, this loses because the cursor
before and after a <control-D>, will refer to the same location on the
screen.

The bottom line is that it's a fundamental flaw (not to mention a
security problem) if an editor can create lines which it can't display.

Suggestion:

	POSIX should permit implementations to do scrolling (<control-B>,
	<control-D>, <control-F>, <control-U>, <control-Y>, <control-E>),
	and cursor positioning (H, L, M) commands using logical lines,
	not physical.  The only changes required are that POSIX allow
	this implementation, and note that, in this case, <control-D> and
	<control-U> must only set the cursor to the first non-blank
	character of the line if the current line changed.

	Nvi is implemented this way, and, so far, noone has ever even
	noticed.

(6) 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

The current standard prevents implementations from allowing users to
erase past the current input line, i.e. once the user inserts a new
line, they can no longer erase characters before that line.  This is
wrong, and prevents superior implementations.

Suggestion:
	Change the specification to permit implementations to erase past
	the beginning of the line, and back to the start of the input text.



WG15 response for 9945-2:1993 
-----------------------------------



Q1: 

The standard states the behavior for the line to be substituted and the 
current line indicator, 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 <newline> character shall be added, and 
conforming implementations must conform to this.

Q3: 

The standard states that numbered buffers 1-9 shall be accessible only from 
visual mode, and conforming implementations must conform to this.  However, 
concerns have been raised about this which are being referred to the sponsor.

Q4: 

The standard states the behavior for scrolling, paging, and moving, and 
conforming implementations must conform to this.  However, concerns have 
been raised about this which are being referred to the sponsor.

Q6:

The standard states the behavior for moving, scrolling, and deleting, and 
conforming implementations must conform to this.  However, concerns have 
been raised about this which are being referred to the sponsor.

Rationale for Interpretation:
-----------------------------
None.
 _____________________________________________________________________________