EL behavior at end of line

[egmontkob]

Environment

Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0

Steps to reproduce

Issue an EL (clear to end of line, \e[K) when the cursor is at the rightmost position, in "pending wrap" a.k.a. "delayed eol wrap" state. Print further characters. E.g.:

printf "%$(tput cols)s\e[K%s\n" 0123456789 abcdef

Expected behavior

xterm's behavior, and as far as I know the "official" one is that EL clears the "delayed eol wrap" state along with erasing the last column (9), resulting in (denoting the right margin by a "left one eighth block" ▏):

          012345678a▏
bcdef               ▏

Some terminals, including VTE, iTerm2, Kitty, Konsole, PuTTY 0.73 intentionally deviate: make EL not clear the "delayed eol wrap" flag and not erase the last character either:

          0123456789▏
abcdef              ▏

Rationale:

There are several utilities that want to just simply print some text with colors or other attributes, without caring about the terminal width or doing anything more complex terminal driving. If these attributes include a background color too, the behavior is messy across a linewrap, due to the terribly designed bce (background color earse) feature. (Now, VTE, and perhaps some other emulators too, intentionally implement bce differently, as another means of mitigating the problem I'm describing here, but let's leave that to another day.)

As a workaround for the background color problem, several utilities decide to also emit an EL after restoring the background color, to earse the faulty color there. And they often don't realize that this introduces an even more serious issue: at linewrap, a character might get dropped from the output. An example is grep with its default settings. PuTTY 0.73's changelog refers to gcc.

Notes We (VTE) haven't received any bugreport about it, nor did I saw one in Kitty's, Konsole's or iTerm2's bugtracker. Also there's no vttest test case for this.

I do recommend that you follow our behavior here. :)

Actual behavior

The last digit 9 is wiped out by EL for no apparent reason since the "delayed eol wrap" state isn't cleared, the first letter a is printed in the next line anyway:

          012345678 ▏
abcdef              ▏

Or, at 38 columns:

echo 'The quick brown fox jumps over the lazy dog.' | GREP_COLORS='ms=1;91' grep z

The quick brown fox jumps over the la ▏
y dog.                                ▏

[j4james]

Personally I'm in favor a following the spec (which in this case matches XTerm) and clearing the delayed eol wrap flag for all the commands that require it. At the moment we're only doing it for commands that change the cursor position, so these are some of the ones I think we're missing:

• ECH (erase character)
• DCH (delete character)
• ICH (insert character)
• EL (erase in line)
• ED (erase in display)

Note that there are other commands that should reset the flag but which we don't yet implement.

[DHowett-MSFT]

This is also related to #780, where we're keeping all of the world's knowledge on "how we handle deferred EOL and writing characters to the buffer and all that jazz." 😄

[j4james]

For a summary of how other terminals handle wrapping see also: https://github.com/mattiase/wraptest/blob/master/results.txt

Looking at those results, and noting the way the later VT terminals diverged from the STD 070 spec, I'm now more inclined to accept that we shouldn't be clearing the delayed eol flag when a tab character is received (as @egmontkob was suggesting in issue #3168). But as this requires undoing our default behaviour, it's probably going to be a more complicated fix than the operations that just need the flag clearing added to them.