Extending the DA report with other features

[j4james]

@jerch and I have recently been discussing the possibility of extending the primary device attributes report to include another feature number that indicates whether a terminal supports the OSC 52 sequence for copying to the clipboard, and I wanted to see whether this is something you might be interested in.

We don't want to get into a discussion about inventing a whole new protocol for feature reporting, that will likely never be agreed upon. We just want something that's easy for terminals to implement, so it has a reasonable chance of being adopted.

So the question is, would you be open to adding another number in your DA report (possibly 52) to indicate that your terminal supports some form of OSC 52? We can get into the details of what exactly that means later - I just wanted to see if you're interested in the idea at all.

[christianparpart]

Sounds interesting. Thanks for letting us know. If you guys are going to implement it in xterm.js / Windows Terminal, then we're adopting the number you agreed upon. :)

And yeah, I agree on the feature detection topic, sadly.

[jerch]

@j4james "52" is fine by me, if it is not taken by something else. I don't have an extensive list of taken DA1 numbers (beside the old ones), maybe @textshell has gathered some useful information of DA1 numbers for his terminal emulator capability sheets?

[j4james]

AFAIK, the highest standard extension number is 46. And the proprietary ones that I'm aware of are 100, 314, 444, 1337, 8100. If we think it's safer we could always go with something like 520, but I think 52 is probably fine.

The thing I want to look at now, is what level of "conformance" is expected for this feature. I'm assuming only copy is required, because a lot of terminals won't support paste, and I think copying is what apps care about the most.

I'm also assuming that we're not expecting terminals to support all the different cut buffers and clipboard types that xterm supports (I don't even know what 90% of them mean). I'm hoping there's a common type that almost everyone supports, and which meets the requirements of apps that are currently using this sequence. I'm going to do a little more research into that now.

[jerch]

I'm assuming only copy is required, because a lot of terminals won't support paste, and I think copying is what apps care about the most.

Oh is that so? Would it then make sense to separate copy & paste on the feature detection? Btw in browsers copy (write to clipboard) is kinda always allowed, paste (read clipboard data back) is strictly guarded though.

I'm also assuming that we're not expecting terminals to support all the different cut buffers and clipboard types that xterm supports (I don't even know what 90% of them mean).

As far as I understand 'primary' and 'secondary' are a feature of X11 (thus surfacing impl details of the outer env, which imho is a bad idea). Idk what the idea is behind select and cut-buffers 0-7 though.

(Sidenote: I haven't done the impl for xterm.js myself, but that is what I grasped from the PR reviews...)

[j4james]

Oh is that so? Would it then make sense to separate copy & paste on the feature detection?

Well that was one of the reasons I proposed that other solution (using the OSC 52 sequence itself to query the supported functionality). However, from the discussions I've seen elsewhere, I think apps are happy to let the user paste with the terminal's default paste functionality (typically with bracketed paste). What they most care about is a way to trigger a copy operation themselves. For example, an editor might let a user select the entire contents of a file, and copy that to the clipboard - that's only something that can be accomplished by the app itself.

Btw in browsers copy (write to clipboard) is kinda always allowed, paste (read clipboard data back) is strictly guarded though.

I believe that's the same thing for most terminals. Nobody (except VTE) thinks copying to the clipboard is that big a deal. But pasting would let apps spy on clipboard content and potentially steal passwords, so it'll either be behind an option that's off by default, possibly confirmed on demand, or simply not supported at all.

So that's why I would be happy to go with the simplest thing that everyone is likely to support, i.e. some form of copying to the clipboard, which can be pasted back with the terminal's built-in paste functionality.

[j4james]

I should mention that one of the other ideas I had considered was using mode queries, and then you could potentially have two of them - one for copying and one for paste. That would also give you more flexibility in reporting the state. For example, something like this:

• paste mode permanently disabled means it's not supported
• paste mode permanently enabled means it is supported
• paste mode disabled (but not permanently) requires permission from the user
• paste mode enabled means the user has temporarily granted permission

I'm not sure how well that lines up with how terminals actually handle permissions for this functionality, though, and it's obviously a lot more complicated. So that's why I kind of prefer a single DA extension with minimal functionality. It's such an easy thing for terminals to add, so has the best chance of adoption, and I think it's all anyone really cares about.

[jerch]

@j4james Yeah, I also would prefer the simplest possible idea here, as it increases the chance of adoption. I am not deep enough into copy&paste usage across console apps, so I dont know whether a copy vs. paste distinction is of any real value. But since you have more insights here and say that copy is mostly wanted - how about that:

We flag the feature as "clipboard-write (copy) is supported, clipboard-read (paste) might be unsupported or further guarded by the TE" and leave the details for "paste" to be tested by apps with your protocol idea? And if a TE wants to guard even clipboard-write by user permission, maybe let the DA state shift:

• initial state: clipboard-write supported but undecided, DA reports 52
• OSC52 write attempt --> TE requests permission from user
• user gives permission: DA still reports 52
• user rejects permission: no 52 in DA anymore

This DA report shifting introduces the need to get the report a second time after testing the action, but it would be basically the same for a mode state reporting sequence*.

This way even paranoid TEs like VTE could be handled by a single notion in DA.

---

[*] On a sidenote - in xterm.js we already have to shift DA report for things like sixel support, as users could have enabled/disabled the addon. For OSC52 it would be the same, as it is also an addon. But those addon on/off shifts are more static as it is highly unlikely, that a user would do that in the middle of a terminal session.

[j4james]

And if a TE wants to guard even clipboard-write by user permission, maybe let the DA state shift:

I don't think we need anything as complicated as that to start with, because I've yet to see a terminal that prompts the user for clipboard writes. There are a few that have an option to disable the functionality, but it's just on or off. So all we need to say is don't report the feature if the functionality is not actually enabled.

VTE simply doesn't support any clipboard operations at all, and likely never will. But if they (or someone else) does one day decide to add clipboard writes with a user confirmation prompt, we can decide how best to handle the issue then. Because I think that is something that really needs to be discussed with the applications that will be using that functionality.

So again, I'm in favour of keeping things simple and not overspecifying anything until we really need to.

[jerch]

I don't think we need anything as complicated as that to start with, because I've yet to see a terminal that prompts the user for clipboard writes. There are a few that have an option to disable the functionality, but it's just on or off.

VTE simply doesn't support any clipboard operations at all, and likely never will.

Oh well, then I misunderstood you from above. I was under the impression VTE already has clipboard-write permissions in place. Since this is not the case, I agree with this:

But if they (or someone else) does one day decide to add clipboard writes with a user confirmation prompt, we can decide how best to handle the issue then.

So yeah lets not over-complicate things and just go with the common denominator here - which seems to be clipboard support yes/no with at least clipboard-write.
I also suggest to leave the buffer details out of this, so a TE indicating OSC52 support has at least write-access to one "clipboard buffer" (would be "primary/clipboard selection and cut-buffer 0" on xterm). Anything beyond that prolly needs further testing by the app itself, e.g. with some protocol roundtrips or deducting it by other means.

[j4james]

I also suggest to leave the buffer details out of this, so a TE indicating OSC52 support has at least write-access to one "clipboard buffer"

Well I was hoping we'd be able to advise apps on exactly which buffer to use to get something that works across all terminals. If you need to know that on xterm you must copy to the primary buffer, and on alacritty you must copy to the clipboard buffer, then you're back to detecting individual terminals, and there's no point to this feature.

But I've only got half way through my list of terminals, and I've already found that there's no universal format that they all support. And this is with a test app going overboard to try and make things work: I've got random sleeps (that seems to help sometimes), and I'm spamming the clipboard with multiple writes (once is not always enough). On top of that all, xterm has a habit of core dumping randomly. I'm about ready to give up on this whole idea.

[jerch]

But I've only got half way through my list of terminals, and I've already found that there's no universal format that they all support. And this is with a test app going overboard to try and make things work: I've got random sleeps (that seems to help sometimes), and I'm spamming the clipboard with multiple writes (once is not always enough). On top of that all, xterm has a habit of core dumping randomly. I'm about ready to give up on this whole idea.

First thanks for your dedication to get this sorted out ❤.

What you write sounds horrible to almost not useable in a uniformed way. I would have assumed, that clibboard-writing with OSC52 without specifying any buffer details would always work magically, because the TE would simply use its defaults and figure out any convoluted buffer details on its own. Pretty much in a sense, that the app does not care about it at all, it should just work. And last but not least, if clipboard reading is supported and allowed, that the reading sequence w'o buffer notions is mapped to that same buffer, so a real data roundtrip would be possible. If thats not the case at all - hmm, idk what to write - doomed to fail?

[jerch]

@j4james Btw regarding xterm crashes: Ive seen this too in the past, when I tried to compile xterm with as much as possible switches to have the best functionality surface. I think some of the switches are not really compatible, sadly I dont remember anymore, which I left out to get it reliably working. I suggest playing around with the compile switches, or to start with typical compile settings from one of distros and to add switches from there if needed.

[textshell]

I'd don't have much data collected on DA1 responses in terminal guide (only the initial set i gathered initially).
The way terminal guides works it is hard to really have the semantics of this reports, as it is based on sources not documentation.

But another of my projects terminal zoo allows for reasonable easy running a query \033[c against all terminals listed there

Of course there will be terminals missing from that project (if you spot anything missing that works on linux and is open source, feel free to open an issue, or PR)

For the terminals that seem to match the expected format the following codes have been observed.
1, 2, 3, 4, 6, 7, 8, 9, 15, 16, 17, 18, 21, 22, 28, 29, 314

So at least in that sample 52 seems to be unused.

That said I'm not sure how much terminal feature "detection" fiddling with DA1 will break. That kind of code often is very ad-hoc and brittle.

But i really think we should get a more reasonable feature detection protocol moving again, sadly things happened and i dropped the ball on further work on that.

[j4james]

I've now tested 18 terminals that have some form of OSC 52 support. There are definitely others, but that seems like a representative sample to start with. And of that set, 17 of 18 supported copying to the clipboard buffer (i.e. the c option), and 15 of 18 supported the default buffer (i.e. the Pc parameter left empty).

And just to be clear, my idea of "working" is that an app can copy some content to the buffer with an OSC 52 sequence, and then have the user paste it back via the terminal's default paste menu or shortcut key (typically Ctrl+Shift+V or Ctrl+Shift+Ins). It's possible that other buffers might be accessible via a different key combination, but I didn't bother trying to figure that out.

I also did a bit of research into the apps using OSC 52, and which buffers they used when copying to the clipboard. Most that I found were targetting the clipboard buffer (i.e. c), with the next most common being the default buffer. Neovim and Emacs seems to have an option to choose between the clipboard buffer and the primary buffer, but I don't know what difference that makes.

So if we were going to mandate a conformance requirement for feature 52 (or whatever we decided to number it), I would say the bare minimum is that terminals should support copying to the clipboard buffer (i.e. c). But ideally we should try and persuade everyone to support the default buffer too, because it's likely not a big change. And it's worth mentioning that tmux is one of the apps that relies on the default buffer.

Terminals not supporting the default buffer include Contour, DomTerm, and Terminology, and I'm fairly sure we could at least persuade the first two to add that support. And the only terminal that didn't support the clipboard buffer was Xterm, and that doesn't concern me too much because I can't see Xterm be willing to add a custom DA1 extension anyway.

[j4james]

I'm not sure how much terminal feature "detection" fiddling with DA1 will break.

I don't see this being an issue. Modern terminals quite frequently change their DA1 report as they add new functionality - the most obvious example being the addition of Sixel support, which many terminals have added in recent years. If there are apps out there that try to detect terminals by matching hardcoded DA1 strings from 10 years ago, then they are already broken.

i really think we should get a more reasonable feature detection protocol moving again

If you want to discuss that, I'd suggest doing so in the terminal-wg forum or on the iTerm2 issue tracker (I think George may have already shipped a version of the terminal-wg protocol in iTerm2). Personally I think it's counterproductive, and I really don't want to get sidetracked by that (and I think @jerch is in agreement with me on that).