.
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: [email protected] (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. _____________________________________________________________________________