[konsole] [Bug 233991] color remap xterm ANSI sequences not supported

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=233991

Egmont Koblinger <egmont at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail.com

--- Comment #7 from Egmont Koblinger <egmont at 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 the assignee for the bug.