Add support for querying DECAC with DECRQSS

[j4james]

Description of the new feature/enhancement

This is a follow-up to PR #13058. Ideally we should be able to query the state of the DECAC color assignments using a DECRQSS query, so if an application changes those values, it can also restore them to what they were initially.

Proposed technical implementation details (optional)

The problem here is that DECAC works differently from most other DECRQSS queries. Typically there is only one potential response for a query, but in the case of DECAC we need to know whether to return the Normal Text colors, or the Window Frame colors.

This is what the VT525 manual has to say on the subject:

DECAC can be reported using DECRQSS and DECRPSS. Use Ps1 in DECRQSS to select the item to be reported.

But it's not clear to me what that means. Is the Ps1 meant to be included as a parameter value following the DCS introducer, or within the actual body of the string data? For example, if you're querying the window frame (color item 2), do you use this:

\eP2$q,|\e\\

or this:

\eP$q2,|\e\\

Of the modern terminal emulators I've tested, only three support DECAC in any capacity, and only two of those respond to a DECRQSS query for DECAC, but not in the same way. If I was forced to make a choice, I'd likely go with the second option, but I'm hoping we can get confirmation of the correct behavior from someone with a VT525.

[j4james]

/cc @jerch If you get back to doing some testing on your VT525, this is one the escape sequences that I'd love to get more info on. And I'd be happy to put together some test scripts if that would help.

[jerch]

/cc @jerch If you get back to doing some testing on your VT525, this is one the escape sequences that I'd love to get more info on. And I'd be happy to put together some test scripts if that would help.

Yes, if you have ready-to-go test scripts, that would certainly speed up the process, as I could simply run it and return you the output (without actually going into sequence semantics on my own, which is more time consuming).

[j4james]

Thanks @jerch - that would be much appreciated. I've created a test script here:
https://gist.github.com/j4james/eca9bd29189f2abe851f206f1cbda0cd

When it runs, it'll log the responses to a file name decac.log, so it should hopefully be easy to report back. But note that it just appends to the end of the file each time, so you may need to delete it between runs if you rerun the test.

If possible, it would be good if you could assign the default text colors for the terminal to blue on white (more specifically index values 4 on 7) before running the test. You should be able to do this from the Setup menu: select Color, then Assign colors..., then configure the values for the Normal text option. This is not essential though - I'm just curious to see if that has any effect on the default parameters.

[j4james]

@al20878 I've just remembered this is another test I was hoping to get someone to run on a VT525, so while I'm bombarding you with requests, I'd be grateful if you could add this to the list. The comment above has some notes on how the test should ideally be run (see #13091 (comment)).

[al20878]

@j4james Downloaded the script, read the instructions, will try to follow them, and report back the results. Stay tuned ;-)

[al20878]

So I set the color as 4 on 7 and ran the script. Screen shot:

Log:

decac.log

[j4james]

@al20878 Thank you again. I think this has given me all the info I need.

And I'm grateful for the screenshot, because that's made me realise that our DECAC implementation is not quite correct. I had thought the color changes would apply to existing text on the screen, but it only seems to effect new output. Will need to rethink our architecture somewhat.