Question: xterm.js 4.0+ handling of EL when cursor is in deferred EOL position

[DHowett]

Details

• Browser and browser version: Chromium Edge, 84.0.522; VS Code 1.46
• OS version: This does not appear to matter
• xterm.js version: 4.0.1+ - tested on 4.7, 4.1, 4.0.1, 3.14.5

Steps to reproduce

Print 80 characters in an 80x25 terminal, then emit an EL. What should happen?

term.open(document.getElementById('terminal'));
term.resize(80, 25);
term.write("0        10        20        30        40        50        60        70        8\x1b[K~\x1b[1;5H");

Result <= 3.15

Result >= 4.0

This manifests in VSCode 1.46 with the new console host changes in Windows 21H1 as buffer corruption when running Windows VIM.

I'm not certain this is a bug, exactly, but it does present an interesting conundrum.

• VTE handles it like <=3.15 (therefore so does gnome-terminal)
• Konsole handles it like <=3.15
• Alacritty handles it like <=3.15
• PuTTY handles it like <=3.15
• Conhost handles it like <=3.15
• Xterm-344 (and the newest version, Xterm-356) handles it like >=4.0
• rxvt-unicode v9.22 does both (it destroys the 8 but leaves the ~ on the next line)

[Tyriar]

@jerch thoughts?

[jerch]

Imho thats a result of the cursor restriction code made in #2288, which was needed to get several cursor misplacements fixed.

What happens under the hood is roughly:

• write content with 8 in last cell
• terminal acknowledges, that another char would wrap (if DECAWM is set), but the cursor still sticks to the last cell
• now EL handling kicks in: delete all to the right side including current cursor position (which is still last one) --> 8 gets deleted

I came to that way of handling things after some serious testing against xterm behavior with our sequence files, so yes it should be in line with what xterm does (hopefully).

But whether this is an error or intended behavior - tbh I dont know. Following the old DEC standard our 4+ way seems to be what DEC did here too:

// taken from DEC 070 STD
case 0:
  for (x=active_position.column;                          // here: start from current cursor pos
       x <= end_of_line(line); x++)
    {
    if (display[line][x].attribute.selective_erase)       // we dont support that cell attribute
      display[line][x].code = 32; /* Space */
    }
  break;

I admit, that this way is semantically flawed, but it seems to be what was done in the old devices. Also there are more awkwardities around the content of the last cell in a line and the cursor handling there for other commands.

Edit:
If this turns out as a major limitation, we could try to lift the cursor restriction up to term.cols instead of term.cols - 1 for EL (prolly ED as well). But this needs serious testing to not introduce side effects on other ends.

[jerch]

@DHowett #3365 will restore the old behavior as in version <3.15 (prolly lands in 4.13). Just in case you have dependent code...