Feature Request: implement XTPUSHSGR / XTPOPSGR

[jazzdelightsme]

Summary of the new feature/enhancement

I would like to add at least partial support for the control sequences "XTPUSHSGR" and "XTPOPSGR" (as well as their aliases). Summarized from xterm's ctlseqs doc:

XTPUSHSGR

CSI # {
          Push video attributes onto stack (XTPUSHSGR), xterm.  [...]
          If no parameters are given, all of the video attributes are
          saved.  The stack is limited to 10 levels.

CSI # p
          Push video attributes onto stack (XTPUSHSGR), xterm.  This is
          an alias for CSI # { .

XTPOPSGR

CSI # }   Pop video attributes from stack (XTPOPSGR), xterm.  Popping
          restores the video-attributes which were saved using XTPUSHSGR
          to their previous state.

CSI # q   Pop video attributes from stack (XTPOPSGR), xterm.  This is an
          alias for CSI # } .

The problem this helps with is composability of content.

Suppose you have code that emits text that contains SGR control sequences to colorize it. You will find that your text is not easily composable--that is, you may have a format string like "The name is: %s, the position is: %s", and then you want to sprintf some inserts into that. Then that whole string you may want to insert into another, and so forth.

The problem is that to have SGR sequences in that one has to have sort of a global awareness of content and associated coloring for that to work out.

With SGR push/pop, though, you can do things like:

<fgBlack>   : CSI 3 0 m
<fgGreen>   : CSI 3 2 m
<fgYellow>  : CSI 3 3 m
<fgMagenta> : CSI 3 5 m
<fgWhite>   : CSI 3 7 m
<bgBlack>   : CSI 4 0 m
<bgYellow>  : CSI 4 3 m
<bgWhite>   : CSI 4 7 m
<pushSgr>   : CSI # {
<popSgr>    : CSI # }

name = "Dan <pushSgr><fgBlack><bgWhite>Thompson<popSgr>"
position = "<pushSgr><fgMagenta><bgYellow>Developer at Large<popSgr>"
line1 = "<pushSgr><bgBlack><fgWhite>The name is: %s, the position is: %s<popSgr>"

And then you can printf(line1, name, position), and have it all work out.

Without a push/pop mechanism, composing strings like that cannot be done that way at all, unless you do your own custom rendering pass to handle the pushes and pops.

Xterm supports saving/restoring of individual attributes, but this most essential "composability" scenario only requires saving and restoring them all together, and should be simplest to implement.

Proposed technical implementation details (optional)

The "business logic" of these commands is not too complicated... it's just a stack.

Pull Request

PR is here: #1978

[zadjii-msft]

Woah, I had no idea those existed. Did those get implemented recently?

[jazzdelightsme]

One open question: what to do if parameters are supplied to the XTPUSHSGR sequence? I summarized the command in the Issue; here is the full spec:

CSI # {
CSI Ps ; Ps # {
          Push video attributes onto stack (XTPUSHSGR), xterm.  The
          optional parameters correspond to the SGR encoding for video
          attributes, except for colors (which do not have a unique SGR
          code):
            Ps = 1  -> Bold.
            Ps = 2  -> Faint.
            Ps = 3  -> Italicized.
            Ps = 4  -> Underlined.
            Ps = 5  -> Blink.
            Ps = 7  -> Inverse.
            Ps = 8  -> Invisible.
            Ps = 9  -> Crossed-out characters.
            Ps = 1 0  -> Foreground color.
            Ps = 1 1  -> Background color.
            Ps = 2 1  -> Doubly-underlined.

          If no parameters are given, all of the video attributes are
          saved.  The stack is limited to 10 levels.

I don't think it is necessary to start out implementing support for the parameters, but if parameters are seen, what to do? Throw some sort of error? Or just ignore the entire sequence? I think the latter would be best. But note that to properly ignore it one would actually need to do an "empty" push, so that a subsequent XTPOPSGR sequence will have no effect (and not unbalance the stack).

[jazzdelightsme]

@zadjii-msft: yes; first introduced last August in patch #334, with aliases added more recently.

[miniksa]

This sounds great.

I agree with the interim compromise of doing the empty push and ignoring the excess parameters we can't handle at that moment.

I think it makes sense to get it going in phase 1 then add parameters in phase 2 to make implementation easier. I would just not like to see a long long time go by between the two phases.

I think it's better to not support this at all than leave it in a half-baked state for a long time.