Indicate support for OSC 52 in the devices attributes report

[j4james]

Description of the new feature

I've mentioned this as a possibility before, but I think it's time to consider it more seriously now. The idea is that we would add the extension parameter 52 to our devices attributes report, to indicate to applications that we support copying to the clipboard with OSC 52.

I've been discussing the idea with a number of other terminal devs recently, and five have already agreed with the proposal. I'm going to continue promoting the idea with other terminals and apps, but if Windows Terminal can be persuaded to sign up, I think that would already be enough of a consensus for everyone to start using it.

Proposed technical implementation details

We need to get PR #18949 merged first, so both OpenConsole and Windows Terminal have OSC 52 support, but then it's just a simple matter of adding 52 to the string here:

terminal/src/terminal/adapter/adaptDispatch.cpp

Line 1487 in 155d8a9

_ReturnCsiResponse(L"?61;4;6;7;14;21;22;23;24;28;32;42c");

[DHowett]

Absolutely. I'm down for that.

[lhecker]

I'd be absolutely alright with adding support for this, but I would not say that I'm in favor of it. The reason for this is:

• Not being able to differentiate between whether 52 is missing because OSC 52 support is disabled or because the terminal is unaware about this addition. Not a big issue per-se, but...
• If we do add this to all relevant terminals and client apps come to rely on it, there's a high chance that all terminals that signal this also support OSC 52 anyway. Are there popular terminals besides VTE that don't support OSC 52 yet?
• Not being able to differentiate between reading/writing the clipboard (given that many support writing but not reading, similar to us).

Basically, I wonder: Will this actually allow us to do something long term that would otherwise not be possible?

[j4james]

Not being able to differentiate between whether 52 is missing because OSC 52 support is disabled or because the terminal is unaware about this addition.

Terminals will only include the 52 in their DA response if clipboard write access is actually enabled - that's in the spec already. Windows Terminal doesn't currently have an option for that (at least as far as I'm aware), so that's why I was just going to hardcode it.

Are there popular terminals besides VTE that don't support OSC 52 yet?

I don't know what you consider to be popular, but some of the terminals that didn't obviously appear to support it were hyper, mobaxterm, putty, rxvt, st, wayst (there'll also be loads of what I call "real" terminal emulators). Some might support OSC 52 through an extension or patch, and some might have a setting that needs to be enabled. But even just being able to tell whether clipboard access was enabled or not would already be a significant benefit I think.

Not being able to differentiate between reading/writing the clipboard

Reading is out of scope, because there isn't an easy solution for that. All I'm trying to address is the existing use case of applications that want to know if the terminal supports writing to the clipboard. They can live without reading, because the user can always paste the content back manually with Ctrl+Shift+V or whatever. And right now they're detecting clipboard support with XTVERSION queries or XTGETTCAP, both of which are horrible solutions.

[DHowett]

Windows Terminal doesn't currently have an option for that

Ah, I've bad news: #18449

[j4james]

Not a problem. I'm happy to add a check for that so we can report it correctly.

[lhecker]

After reflecting on it, particularly after what you said, I can see how it's useful now.
Is it realistic that we'll get the majority of terminals that support OSC 52 to adopt this change in the near term?

[j4james]

Is it realistic that we'll get the majority of terminals that support OSC 52 to adopt this change in the near term?

I very much doubt it. My goal was just to get something that surpasses XTGETTCAP, so apps that currently rely on that can be given a better option. And hopefully then they'll stop nagging us to support that (or XTVERSION for that matter).

If you're asking because you want to know whether it's worthwhile using this to detect clipboard support for msedit, that depends on whether you think there is a negative impact to using OSC 52 by default. And I expect that's something your users will eventually tell you if it does bother them.