Printed space goes missing when using grep --color at end of line

[Tyriar]

Might be a combination of the space and the \x1b[0m?

VS Code issue: microsoft/vscode#125605

[Tyriar]

Space is getting written to 86, so is a:

[mofux]

I can reproduce as well, also only with --color=always. Resizing the terminal (reflow) doesn't fix nor produce the bug, so I guess it's happening somewhere during parsing. Maybe some limiting logic (Math.max, Math.min, ...) that causes an off-by-one error for this edge case?

[jerch]

It is caused by this line:

xterm.js/src/common/InputHandler.ts

Line 1322 in 19c9fef

this._restrictCursor();

xterm.js inherits this behavior from xterm, disabling it here will let the xterm test t0055-EL.in fail.

Edit:
It is indeed questionable, whether EL should restrict the cursor or not. Related issue: #2979

[mofux]

@jerch In #2979 you conclude:

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.

Do you think that would fix this particular bug?

I've just run the test case above in Terminal.app and it does not show this bug.

[jerch]

Yes I think it will fix both of these issues, maybe all we need is this:

  this._restrictCursor(this._bufferService.cols);

which would allow the cursor to stick up to cols. Technically this is an error for any cursor sequence, since the cell is undefined. But we use the same trick during normal print to get the wrapping done, therefore I think it should not cause further trouble. EL internal code itself is guarded against overflows.

[Tyriar]

Silly me just debugged into it to find the cause before I read the responses 😛

@jerch I'll defer to you for how we should handle this, my thinking is we should align with the modern terminals for this as it feels like a bug. Any testing in particular you had in mind? If iTerm/VTE behave like this it's probably a fairly safe change?

[jerch]

@Tyriar Yes it feels like a bug to me. Also #2979 indicates, that most TEs allow the cursor overflow here (not resetting wrap-around). Imho we should fix it for ED/EL.

Regarding tests - the renderers should not overflow here, as we do the same with print just fine. But I need to check other cursor sequences, if they restrict the cursor in a pre- or post step and if their internal code is properly guarded (some test cases should do).