No wraparound when inserting

[javier-godoy]

Wraparound is only honored when typing at the end of the line. The line is not wrapped if characters are inserted at any other place.

FWIW, I had implemented a workaround for xterm 4.19, which relied on the private _dirtyRowService.

Details

• Browser and browser version: Chrome 108
• xterm.js version: 5.1.0 + fit addon 0.7.0

Steps to reproduce

1. Enable insert mode and wraparound mode
2. Type some characters
3. Move to the beginning of line
4. Type more characters
5. Observe that the line is not wrapped

terminal.write('2345678');
terminal.write('\x1b[7D');
terminal.write('1'.repeat(terminal.cols-1));

[Tyriar]

It's up to your shell to set wraparound mode and re-render the prompt

[jerch]

@javier-godoy xtermjs implements IRM and DECAWM following these DEC VT semantics:

If the DECAWM function is set, then graphic characters received when the cursor is at the right border of the page appear at the beginning of the next line. Any text on the page scrolls up if the cursor is at the end of the scrolling region.
If IRM mode is set, then new characters move characters in page memory to the right. Characters moved past the page's right border are lost.

Thus wrap-around does not apply in insert mode to moved chars, that are right of the current cursor position. Also xterm and gnome-terminal behave the same way (tested with echo -en '\x1b[4h2345678\x1b[7D' && sleep 20 and inserting chars while the shell is sleeping).

Btw an interactive shell typically would handle this case correctly by fixing the screen with partial line reprints, therefore I wonder why this is an issue for you at all?

[javier-godoy]

Thanks! Given those examples I understand that xterm.js works as intended.

Btw an interactive shell typically would handle this case correctly by fixing the screen with partial line reprints, therefore I wonder why this is an issue for you at all?

I implemented an interactive shell for a web application. All the presentation logic is contained in the browser, so I have to handle the reprint from xterm.js state. The backend only receives the typed line after the user presses enter, thus it cannot reprint the line while it's being typed.

Now that you explained it, I realized that "fixing the screen with partial line reprints" is what my workaround does (I've just migrated it to xterm.js 5.1.0 and it seems to work):

• If the inserted characters would overflow the last line in wrapped range (for the current position), then wrap the next row
• Wrap-move characters in page memory to the next line (copyCellsFrom) and allocate null-cell space for the characters to be inserted (insertCells) so that the remaining characters are moved to the right in the same line.
• Call the original implementation of printHandler(data, start, end), which will actually write the text in the intended position.

[jerch]

Ah well, xtermjs is a dumb terminal intented to be used behind a PTY (providing minimal line editing functionality) or as raw IO device for apps fully in control of the screen state (eg. an editor controlling every single char position from its own memory screen state).
What you are looking for is either a fake PTY shimming the missing bits (https://github.com/wavesoft/local-echo might be helpful for that). Or even an editor mode, which several more clever terminals in the 70/80s provided (several mainframe terminals worked that way). As a dumb terminal xtermjs does not provide any of that.

So yeah - you'd have to do that on your own.