Add support for setting colors using "Operation System Command" sequence.

[inoyatov]

In traditional terminals which support 256 color, (Gnome terminal, xterm, iTerm and etc.) colors can be set using Operation System Command sequence. In example: printf "\033]4;18;rgb:ff/00/00\033\\". Where \033 escape character and 4 means color set command, followed by color number 18 and color in RGB with closing `\033\' escape sequence. However, terminals which built using xterm.js (VC's internal terminal or Hyper terminal) dose not reflect system color change commands.

Details

• Browser and browser version: I tested it under VSCode IDE and Hyper.is terminal which uses internal xterm.js
• OS version: Ubuntu 16.04 LTS
• xterm.js version: Depends on VSCode IDE and Hyper.is

Steps to reproduce

1. Input following printf "\033]4;18;rgb:ff/00/00\033\\" in Gnome terminal and Hyper or VC's terminal for comparison.
2. And then input following printf "\033[38;5;18mWhat color is it?\033[0m\n". It shows "What color is it?" in RED color on the gnome terminal however on Hyper terminal it shows blue (Images attached). Changes by previous command was not reflected to xterm.js.

So, it would be nice if it will be added to xterm.js since there is many color themes which require custom colors.
Gnome output:

Hyper output:

[ghost]

This would have to be supported by node-pty? If the command is in a script that is ran by the server, $ change-colors.sh, how would xterm.js know that "printf" had been used?

[jerch]

This will be possible by hooking a handler in here https://github.com/xtermjs/xterm.js/blob/master/src/InputHandler.ts#L211

@inoyatov Do you some typical examples for this OSC command? I find the description in the xterm docs kinda hard to grasp.

@pro-src node-pty will simply forward to xterm.js, it does not matter if the bytes were created by printf or any other means.

[inoyatov]

@jerch i am using it in order to fix colors for gruvbox theme from here. Example shell script is located here

[Tyriar]

Is this defined in http://invisible-island.net/xterm/ctlseqs/ctlseqs.html? That's typically the spec we work from.

[inoyatov]

@Tyriar it is defined under Operation System Commands in source you specified.

[jerch]

@Tyriar If I get it right this seems to change a color in the palette permanently?

[inoyatov]

@jerch not permanently it will last until terminal session ends. Which means if you reload xterm colors will reset to original.

[Tyriar]

Yeah, we will want to override the terminal's ColorManager.colors.ansi[x] and redraw when this happens.

[egmontkob]

Some notes:

• In addition to rgb:ff/00/00, the more standard format #ff0000 should also work.

• The feature comes hand in hand with OSC 5 for bold etc. colors, OSC 10 & 11 for the default foreground and background, and a few other special ones up to 19 at this moment. VTE implements most, but not all of these.

• They all have a 100+ counterpart for resetting. 104 with an additional parameter resets that particular entry; 104 without an additional parameter resets all the 256 entries.

• There's also an OSC 106 (formerly known as OSC 6 conflicting with an existing functionality in macOS's Terminal.app and VTE) which is quite a mystery to me, see VTE 722751 comment 18.

• At VTE 705985, followup fix at 793152 we figured out that the proper approach is that each palette color has two slots: one for the value set via API (e.g. the Preferences dialog) (I guess it's ColorManager.colors here??), and one for the value set via escape sequence (if any). The escape sequence one takes precedence whenever set. If unset (e.g. initially, or after OSC 104, 110 etc.) then the API color is drawn. The former approach of both sources fiddling with the same internal variable had problems, e.g. the API wasn't idempotent, so re-applying the very current settings cancelled the effect of escape sequences.

• It's inconsistent which of these colors are reset on a standard reset operation (OSC 10-19 aren't but OSC 4s are, or the other way around, can't recall). VTE follows xterm's inconsistency, although I'd argue this is a bug (or misdesign) in xterm (and hence in turn in vte).

• The value of ? queries the actual resolved value (the one currently seen on UI, regardless of whether it's from API or ESC) and places in the keyboard buffer. Useful for fullscreen apps to figure out whether they run on dark-on-light or light-on-dark color scheme, as a better replacement for the braindamaged COLORFGBG (see also VTE 733423).

• Watch out for some confusion between 5;0 and 4;256 etc. when querying the color, see VTE 722751 (note that we deliberately slightly deviate from xterm here).

[inoyatov]

Dose anyone knew how to make "Device Control String" (DCS) request in terminal? I read this but cannot figure out and google also not helpfull:

DCS + q Pt ST
          Request Termcap/Terminfo String (xterm).  The string following
          the "q" is a list of names encoded in hexadecimal (2 digits
          per character) separated by ; which correspond to termcap or
          terminfo key names.
          Two special features are also recognized, which are not key
          names:
          o   Co for termcap colors (or colors for terminfo colors), and
          o   TN for termcap name (or name for terminfo name).
          xterm responds with
          DCS 1 + r Pt ST for valid requests, adding to Pt an = , and
          the value of the corresponding string that xterm would send,
          or
          DCS 0 + r Pt ST for invalid requests.
          The strings are encoded in hexadecimal (2 digits per charac-
          ter).

If I understood correctly, it allows request termcap color request. So, we can make request for each color. Please, help me to understand how this works. I will try to contribute as well. (Can somebody provide for dummies reference to read in order to understand 😄)

[jerch]

@inoyatov For DCS examples you can have a look at InputHandler.ts, there are a few DCS commands implemented. Request Termcap/Terminfo though is a tricky one since you will have to provide a reliable way to read the terminfo database locally (easy one), browser based (tough one) for POSIX (easy one) and windows (is this even possible?)

[maxekman]

Any update on this? Would be great to have to make a base16-shell config work in VSCode. They use that escape sequence to reset the ANSI colors and a few more.

https://github.com/chriskempson/base16-shell

[jerch]

@maxekman Nope not yet. We recently changed the way attributes are stored internally and are still in the middle of of repo/codebase refactoring, thus feature enhancements like this have to wait until we are settled with the new and easier to use lib infrastructure.
I think we have all the bits needed to provide this feature in the future (imho only the ColorManager needs some shims where such an OSC handler can operate on).

[maxekman]

Sound good, thanks for the update!

[Tyriar]

Later on I expect ColorManager will become IColorService and we could have a component that depends on ICoreService and IColorService to hook up the OSC handler and update the colors. Probably a good idea to wait as @jerch suggests.

[slawekzachcial]

For information, I've been working on #3163 that, once finished and if merged, would provide support to set colors using OSC 4 sequences.

[Tyriar]

This was done in #3524