Support XTPUSHSGR / XTPOPSGR

The XTPUSHSGR / XTPOPSGR control sequences (from xterm are really handy for composition of text that uses SGR sequences to colorize it.

The way it works is that XTPUSHSGR saves the current text attributes (fg color, bg color, underline, etc.) to an internal stack. Then later, an XTPOPSGR restores them–pops the attributes off the internal stack and sets the current text attributes back.

This capability allows you to use SGR sequences (which change text attributes like color) in a much more modular manner, because you are not required to have global awareness of the current text attributes. I.e. I can do something like:

printf( "The <xtpushsgr><fg blue><bg white>xterm.js<xtpopsgr> project is really cool." )

The phrase “xterm.js” will appear as blue on a white background… and the text after will be the same color as the text before. It’s the semantic equivalent of an “end tag”, and opens up all sorts of new possibilities for how text attributes are handled by programs. I’d love to see these sequences supported in xterm.js.

The xterm implementation allows supplying parameters to the sequence, to specify that only certain portions of the current text attributes should be saved (like “just save the underline state only”). But even only supporting a no-parameters form of the sequence would support the most common and useful (IMO) scenarios.

[jerch]

Hmm should not be hard to support those, still the concerns in the vte issue make them looking weakly specced. Is the attribs stack terminal global or bound to a buffer? Will have to look at xterm source…

Further note that, as handy as this might seem - it looses ground as soon as multiple producers use this interleaved, they will screw up the stack.

Edit: Why is the latter a concern? Isnt terminal state always global? Yes, but here the stack behavior might suggest to app devs to get a reliable way to refer to some older attrib values, which is not true for the reliability part. This is misleading at best, and produces wrong formatting at worst.

I think these sequences are interesting for tools that repeat several attribs often - like loggers or debuggers with certain output formatting. But those often operate as “collectors” - they might grab output from other commands to put it into a joint output. Now they cannot assume anymore to still get their wanted attribs with XTPOPSGR - a sub command might have “screwed up” the stack - and they again have to style explicitly (and to do that to memorize those attribs themselves). So nothing was won in the end.

I somewhat question the usefulness of those sequences. 😸

Edit2 (slightly offtopic): Recently I have the impression, that ppl want to see more and more stuff in terminals which allows a tighter coupling of app side and terminal side (this partly reminds me of the OSC 7 discussion in terminal-wg). This is not a bad thing per se, but simply not possible from within the current terminal interface - it cannot be achieved in clean way with some new sequences, it would need changes on much more basic interfaces (process and pty interface, which is not an easy task at all). I think we should restrain from adding stuff that looks promising in a certain way but will fail badly as soon as a more general use case gets applied. A sequence, that has several “works only if … and if …, never when …” restrictions is a bad one.

[egmontkob]

See also https://gitlab.gnome.org/GNOME/vte/issues/23.