xterm.js
xterm.js copied to clipboard
xtermjs
indicate OSC52 support from clipboard addon in DA
From the clipboard addon we should indicate OCS52 support by placing "52" in the DA report, see https://github.com/contour-terminal/contour/issues/1761.
To get DA feature reporting properly solved from independent addons, we prolly should come up with a feature announcing system, that allows addons to add own symbols to DA without messing with other already announced symbols. (Also affects the image addon, which currently overwrites the DA report in a non-portable hardcoded fashion.)
From my reading of the source, xterm.js does not currently support an empty Pc parameter, which seems to be important for the proposal. Did I miss something?
Also, it might be useful to be able to read (get) the current selection, with Pc='p'. Is this worth adding? Perhaps controlled by some setting.
@PerBothner I have not checked yet (and did not write the code). So there is a chance, that we are missing a piece, yes.
About Pc='p': What you describe, sounds like a useful addition. I have no good understanding of OSC52 besides my limited testing when the addon was created, so I am not quite sure about limitations on 'p'. Furthermore I have no idea what those numbered cut buffers are meant for. The xterm docs are not very helpful either.
so I am not quite sure about limitations on 'p'.
In principle like the limitations on 'c' in that it might not work, depending on configuration, security policy, etc. Getting the selection seems easy to implement using window.getSelection(). Setting the selection is a bit harder; I would create some non-visible text and call selection.addRange.
Furthermore I have no idea what those numbered cut buffers are meant for. The xterm docs are not very helpful either.
From what I can read, "cut buffers" were a seldom-used long-obsolete X11 feature that can be safely ignored.
In case this is relevant to your API design, it's worth noting that Tabby has its own OSC 52 implementation (see here), so I'm guessing they might also need a way to hook into the DA report if they wanted to indicate support for the clipboard extension. I originally assumed they inherited their clipboard functionality from xtermjs, which is why I thought you already handled an empty Pc value.
@j4james Yes thats a problem with our library-like approach, in theory any integrator could overload whatever he wants coming up with a very own impl for detail xy. Not only DA would be affected by that, but any collecting/aggregating sequence across TE caps (eg. also DECRQM would be affected by that if someone decides to mess with DEC private caps).
My current idea to solve that for DA would be to introduce an internal symbol array, to which an integrator/addon can add/remove symbols by API methods. I see no chance to enforce its proper usage other than stating in the API about its importance to avoid poor user experience.