revisit missing sequences

[jerch]

There are a couple of useful sequences we currently dont support and prolly should for better user experience / xterm compliance.

• DECLRMM: Analogous to DECOM with DECSTBM VT420+ supports left/right margins to restrict the cursor during normal input with DECLRMM + DECSLRM - imho we should implement this as it makes partial screen refreshs easier for multiplexer...
• left/right scroll SL / SR (ECMA-48) Works analogous to SD / SU - covered by column sequences #2360
• insert / remove columns DECIC / DECDC (VT420+), analogous to IL / DL - covered by column sequences #2360
• area functions
  Not sure about those, there are several area functions to deal with rectangular areas in a specific way. Guess this needs further eval whether we want that at all. Examples:
  • DECCARA / DECRARA
  • DECCRA
  • DECERA / DECSERA
  • DECRQCRA
  • DECFRA
  • DECEFR
    this gets a downvote as there was not a single request for this in over 4 years, no need to complicate terminal state with ancient unused stuff
• protection attributes
  Some of the DEC private variants like DECSED and DECSEL respect protection flags whether they can operate or not. - same as above, no need to complicate things with unused stuff
• media copy (MC)
  There are actually sequences to dump buffer content in various formats, might be useful in conjunction with serialization. - this gets a downvote as it might reveal sensitive data to app side from other terminal sessions
• raw key reports
  As indicated by Support win32-input-mode for more complete key support on Windows #2357 (ff.) we might want/need a way to allow/route raw key reports to pass through. Also see https://gitlab.freedesktop.org/terminal-wg/specifications/issues/1. To get proper support in this area we might have to support DECUDK as well. - not yet decided...
• window manipulation (CSI .... t)
  Not all are useful for xterm.js, at least reports should work, some of the stack save/restore functions are used by multiplexers. Imho some are no-gos for xterm.js like size manipulations as it would screw up the integration. - covered by Support for window options #2393
• new SGR modes
  Eval enhancements in SGR regarding underline with colors and line style. (Note that this is already used by some editors.) Also check for other color modes like transparent and CMYK. - already implemented on parser side, frontend still missing though...
• several missing OSC commands
  Things like setting color palette entries should work. (Add support for setting colors using "Operation System Command" sequence. #1493) - OSC 4 partially implemented in Support OSC 4 ; color ; color spec #3036, more to come...
• last but not least: image support / SIXEL - WIP in image support #2503

Turns out this is a pretty long wishlist, well still some time left until Xmas 2019, 2020, 2021 😸

[jerch]

Comments above were moved to #2656.

[jerch]

@Tyriar
Made some updates to the "wishlist" above (see the italic comments on them).

[daonb]

I wanted to use mdp to display a deck and their sample display looks off (It looks good on iTerm). I believe I saw the same issue in nvim - a line printed at the start of a line where there should be a margin.

[jerch]

@daonb I cannot repro the issue in your screenshot with Ubuntu 16 & 18 (tested with older deb package and mdp master). Which versions are you on (OS, mdp, ncurses, terminfo, xterm.js)?

To get a hold of the failing sequence it would be good if you can post a dump of the chunks being sent to the terminal containing the failing part. Not sure if DECLRMM/DECSLRM is behind this, I'd expect the lines above also being misaligned, if they were used for left indentation. But these look fine to me.

Edit: Found the culprit in your terminal integation - here you tell xterm.js to treat all LF as CRLF. For the presentation above mdp sends this:

...    ---  CSI K  LF  BS  BS  BS  *****   ...

meaning:

• PRINT ---
• EL 0 - delete rest of active line to the right
• LF - move cursor one line down (preserving column position)
• BS 3x - step 3 cols back
• PRINT **********

With your {convertEol: true} you inserted a CR before LF, thus the cursor jumps to the first col. In general convertEol should not be used in conjunction with real PTY data.

[daonb]

@jerch you're my hero, thanks!

[jerch]

Closing, as most things are dealt with or better tracked separately.