Description
We would like to revert #127 to give us more control over copy and paste. This way we can have a unified "bring" / "move" / "carve" / "copy" / "paste" implementation. We can also fix bug with undo stops on paste. Related to #28
We should figure out how ot use the proposed paste api once it's available:
- https://github.com/microsoft/vscode-extension-samples/tree/main/document-paste
- https://github.com/microsoft/vscode/blob/main/src/vscode-dts/vscode.proposed.documentPaste.d.ts
Unfortunately as of 2023-06-12 the above API still doesn't seem to be available, so I'm not super hopeful 😕
I did a bit of digging, and it seems that VSCode adds some metadata to the clipboard entry. Note that the object includes list of strings, one per selection when copied from a multi-cursor selection

Unfortunately, we can't do that, because we are too sandboxed to be able to modify / access clipboard metadata. They do have an in-memory metadata store as well which they fall back to when for some reason the clipboard metadata can't be found. I think the best we could do is to implement a similar in-memory store, but the annoyance is that then if the user tries to do a Cursorless copy followed by a VSCode paste, or vice-versa, the metadata won't be found. As mentioned below, we could try to work around that by contributing our own ctrl/cmd+c/x/v keyboard bindings with a when clause that the editor is focused, but that seems a bit dicey / sketchy, and we'd def want to figure out a way to also trigger the built-in copy so that their fancy metadata isn't lost
Old idea (some stuff def still relevant):
- Revert to our own implementation of copy/cut/paste
- Try to leverage as much from bring/move as we can
- Use the same implementation that vscode does with an internal clipboard per cursor copied
- Support clipboard history.
- Contribute our own ctrl/cmd+c/x/v keyboard bindings with a when clause that the editor is focused
- Switch back to using mock for clipboard-based tests
Originally posted by @AndreasArvidsson in #128 (comment)