https://bugs.kde.org/show_bug.cgi?id=233991
Egmont Koblinger <egm...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egm...@gmail.com --- Comment #7 from Egmont Koblinger <egm...@gmail.com> --- OSC 4, 10 and 11 (and probably a few more in the 12-19 range for cursor and highlight fg/bg, see http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Operating-System-Commands) would be useful for xtermcontrol(1) to work, e.g. to be able to query the default fg/bg colors. See also bug 336849. Note that these should be implemented along with their 104, 110, 111 etc. counterparts that reset these colors. In VTE (gnome-terminal and friends) the implementation used to take escape sequences (OSC 4, 10...) and API (user changing the palette in the prefs dialog) equally. This led to confusions and unexpected behavior when e.g. opening and closing the prefs (without changing anything) would overwrite the effect of a previous OSC 4. So we ended up fixing this (in version 0.36) by introducing two levels. For each slot (256 for the palette of OSC 4, plus a few one-offs like default foreground and background) there's the value set via API (e.g. prefs dialog) which always contains a color, and there's the optional value set via OSC 4 (this can be undefined, and actually the OSC hundred's clear this). If the OSC slot is defined for a particular color entry then that one is used, otherwise we fallback to the API. In other words, escape sequences have precedence. -- You are receiving this mail because: You are watching all bug changes.