Clipboard operations

[Stefan Küng]

The clipboard operations (e.g. SCI_COPY, SCI_CUT) all copy only plain text to the clipboard. The clipboard is opened, emptied, then text added and closed again. That's perfectly fine of course.

But I need to add additional info to the clipboard. For example I'm also adding the current lexer of the document to the clipboard. I'm doing this by first calling the Scintilla function (SCI_COPY/SCI_CUT/...), then opening the clipboard again (without emptying it!), setting my additional data and then close the clipboard. This works in most situations. But when dealing with remote desktops this often fails because the rdp tools watch the clipboard for changes and then copy the local clipboard to the remote one or vice versa. And since the clipboard monitoring API sends a notification for every CloseClipboard call, the text that got added by having Scintilla copy the text gets overwritten by me adding additional data.

I've tried to handle the clipboard on my own, but for multi-selections this let's say a bit difficult since it's not documented how those multi-selections are actually handled via the clipboard. And cutting those without the SCI_CUT command is also difficult and not very performant. And of course there's always the risk of what happens if Scintilla someday changes the clipboard format for those, then pasting would not work the same anymore.

I hope this description of my problem is clear enough, otherwise please ask!

So, to really fix this problem I'd like to ask for some additional features in Scintilla:

1. implement a callback/notification (e.g. with an SCN_ notification) that's sent right after Scintilla has added its own stuff to the clipboard, but before the clipboard is closed. That callback would have to pass the handle to the open clipboard so clients can add their own stuff to it. When the callback returns Scintilla would close the clipboard and be done with it.

   this would be the most flexible fix, because clients could add whatever they want to the clipboard themselves. However I'm not sure if you're comfortable passing handles with a notification.

2. Scintilla could add the lexer data itself to the clipboard: register a custom clipboard format, add the lexer as a string with that custom format. Clients then can use that data if needed.

   this is less flexible than 1) since only the lexer data is added. So clients that want to add e.g. rich-text/html formats for the selection (using the lexers colors) would still have the same problem as I described above. But for me this would already be a big help.

3. implement new clipboard commands that don't put anything on the clipboard but otherwise work the same (i.e., for SCI_CUT the text would still be removed from the doc). Those new commands would instead return the text that's otherwise put on the clipboard as a string or byte array.

   this way clients could handle the clipboard completely on their own.

4. at least a new command that does an SCI_CUT but without copying the data to the clipboard

So, what do you think? Is there a chance that one of these suggestions could get implemented in Scintilla?

Stefan

[Neil Hodgson]

Stefan Küng:

> The clipboard operations (e.g. SCI_COPY, SCI_CUT) all copy only plain text to the clipboard.

They may also push tags (like MSDEVColumnSelect on Win32) to indicate columnar or line mode selection which differ between platforms.

> The clipboard is opened, emptied, then text added and closed again.

Only on Win32. Other platforms have no equivalent of open and close.

> But I need to add additional info to the clipboard. For example I'm also adding the current lexer …

Platform differences will get in the way of many potential improvements here. The hardest issue is that clipboard actions on X and Wayland are asynchronous and mostly synchronous on Win32 and macOS. Qt mostly covers over the asynchronicity and GTK mostly exposes it although there are some ‘apparently synchronous’ calls (they block, running an event loop until complete).

> 1. implement a callback/notification (e.g. with an SCN_ notification) that's sent right after Scintilla has added its own stuff to the clipboard, but before the clipboard is closed. That callback would have to pass the handle to the open clipboard so clients can add their own stuff to it. When the callback returns Scintilla would close the clipboard and be done with it.

This is most complex on GTK where the copy just provides callbacks which may be called by the platform at an arbitrary later time. The lifetimes of Scintilla’s calls (and data referenced for those calls) and the container's may need further synchronization. Another issue is that there may be multiple actions: on macOS and GTK, providing the set of available formats is separate to providing the data. Both may need to be augmented by the container and the augmentation may depend on context like rectangular/multiple selection.

> 2. Scintilla could add the lexer data itself to the clipboard: register a custom clipboard format, add the lexer as a string with that custom format. Clients then can use that data if needed.
> this is less flexible than 1) since only the lexer data is added. So clients that want to add e.g. rich-text/html formats for the selection (using the lexers colors) would still have the same problem as I described above. But for me this would already be a big help.

This is too narrow. While there could be some sort of key / value blob exchanged between Scintilla instances, you really want to support the clipboard formats that other applications already accept.

If you want to copy rich text (or, even worse, images) then there are increases in resource use that start to move towards using the asynch calls on Win32 and macOS where you promise to provide different formats but only realize them on demand.

> 3. implement new clipboard commands that don't put anything on the clipboard but otherwise work the same (i.e., for SCI_CUT the text would still be removed from the doc). Those new commands would instead return the text that's otherwise put on the clipboard as a string or byte array.

The removal part of SCI_CUT is

if (! SCI_GETSELECTIONEMPTY)
SCI_CLEAR

Its the work done by SCI_COPY that is harder to emulate.

A call to return the selection text (perhaps translated to UTF-8) may be useful but it wouldn’t place the extra column/line tags.

> So, what do you think? Is there a chance that one of these suggestions could get implemented in Scintilla?

Its likely that something can be added but platform differences constrain what can be achieved and make implementation more complex.

Neil

[Neil Hodgson]

Stefan Küng:

> So, to really fix this problem I'd like to ask for some additional features in Scintilla:
>

> 1. implement a callback/notification …

A minimum solution to your issue would be a Win32-specific SCI_COPY_BUT_DONT_OPEN_CLIPBOARD that relied on the clipboard already being opened by the application. It shouldn’t empty the clipboard to provide flexibility in call order.

It would be based on ScintillaWin::CopyToClipboard (and CopySelectionRange…) but omit the first 4 lines (OpenClipboard, EmptyClipboard) and last line (CloseClipboard). That way the rectangular and line tags would also be set.

The application can then produce a SCI_CUT analogue by calling this then SCI_CLEAR if there is a non-empty selection.

It should have a short but still meaningful name. SCI_COPYTOCLIP?

Neil

[seasoned_geek]

SCI_APPENDTOCLIPBOARD

I will be implementing a CopperSpice specific version of that in my examples for EDT.

That is what the 9 key does. Appends current selection to the paste buffer.

[GOLD]-ENTER swaps the current selection with the paste buffer. What was selected is now in the paste buffer and and what was in the paste buffer is now the selected text . . . or not selected.