Support the ability to copy to clipboard in extensions

[cfjedimaster]

Support writing (and maybe reading) the system clipboard.

Why I need it: I want to write an extension that will take the contents of the current editor, modify it (by escaping < and >) and then copy that modified text to the clipboard.

[brenthuisman]

Perhaps tangentially related: currently, on Linux, selecting text doesn't copy to the X clipboard. Nor does middle-clicking paste. Would be nice to have.

[mackenza]

I am confused... copy in VSC, paste in xterm seems to work. Am I missing something here?

[cfjedimaster]

Ouch - I'm sorry. I meant to say "for Extensions" - going to edit now.

On Fri, Nov 20, 2015 at 6:35 PM, Andrew MacKenzie notifications@github.com wrote:

I am confused... copy in VSC, paste in xterm seems to work. Am I missing something here?

— Reply to this email directly or view it on GitHub https://github.com/Microsoft/vscode/issues/217#issuecomment-158567014.

Raymond Camden, Developer Advocate for MobileFirst at IBM

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[jrieken]

@cfjedimaster You should use a node module for this, like https://github.com/xavi-/node-copy-paste

[cfjedimaster]

Respectfully I disagree. I think the Editor can do more to enable extension developers to be productive. Accessing the clipboard is - imo - not something I should have to go to Node for. It really should be baked in.

[jrieken]

I agree to the point being able to use the simple copy&paste and those should be accessible via the respective command. Tho being able to modify the clipboard contents is different story and I think it's fair to draw the line there

[siegebell]

@jrieken It's fairly common for editors to provide advanced clipboard features beyond what the system provides, and it makes sense for the feature to exist as an extension, e.g. vscode-multiclip. I'm writing an extension that needs to be able to copy arbitrary text into the clipboard (not just the editor selection), and it would be great if it played nicely with vscode-multiclip or any other extension that provides advanced clipboard features. Requiring that my, and all others' extensions, know about such clipboard-extensions in order to access their exported API (if one is even provided) is unreasonable.

Edit: VSCodeVim is another example where an extension extends the clipboard functionality.

[vvuk]

Same with emacs bindings -- e.g. in emacs you can keep typing C-k to repeatedly delete lines, building them all up to paste as a single thing. This doesn't seem possible to implement in VSCode right now, without ignoring the actual system clipboard entirely (which is what the current emacs keybindings do).

Is there any reason why the line is drawn at modifying clipboard contents? Extensions can execute arbitrary code, so it's not security...

[pfmoore]

The recommendation to use https://github.com/xavi-/node-copy-paste isn't ideal - on my system that doesn't work. I've no idea why, and can't suggest an obvious way to debug it, but it breaks vscodevim for me. As a user of VS Code, and not an node programmer, I can't even really offer a test case they can work with, so I ended up raising a big report on vscodevim, which they may be unable to address as it's a problem in a 3rd party module, and I'm left unable to use vscodevim.

IMO, access to the same clipboard data that VSCode uses is a pretty reasonable thing to expect from the extension API.

[johnfn]

This is a huge frustration for VSCodeVim. node-copy-paste isn't a solution; it has a number of issues. So do all the other clipboard libraries.

https://github.com/VSCodeVim/Vim/pull/1487#issuecomment-292821191

Please consider reopening this so we don't have to redebug the wheel.

[wraith13]

node-copy-paste do not work correctly with non-ASCII characters. see #16261

[octref]

@jrieken Can we revisit this?

All I wanted to do is to put a image into the clipboard. I spent 2 hours studying all the options and none of them work.

https://github.com/xavi-/node-copy-paste has been abandoned for a year and half and is buggy for many people. https://github.com/sindresorhus/clipboardy exists but it's only for text. In webview -- Chromium has a 6-year-bug for programatically put image into clipboard.

Currently the only sane way to do this cross-platform is clipboard.writeImage in electron.

[jrieken]

We have come to understood the short comings of existing node modules and we will re-consider (and likely implement) this.

This is the underlying electron API but we are likely keeping it simple and only support plain text (no rtf, images, etc). Objections? Special requests?

[slang25]

Selfishly, I want image support and html/rtf, so that extensions like polacode can put an image on the clipboard.

My scenario is I want to be able to quickly paste code samples into slides and blog posts, I had to write my own tool to work around this: https://github.com/slang25/html-copy-vscode.

[MattIrv]

For the vscode-mssql extension it would be super helpful to expose the entire Electron clipboard API instead of partially exposing it or reimplementing it. This will let us give our users the ability to copy/paste sql query results with or without special formatting, and in the future if the image clipboard APIs etc are exposed then it would enable things like “copy as image”

[jrieken]

Hm, rtf and html might be quite easy but images are harder without leaking the electron image type into the API...

[jrieken]

@slang25 @mattlrv how would you provide an image? in what format would you have them and how would you expect use to accept it? data uri? file uri? byte array?

[octref]

@jrieken For Polacode it's byte array.

[jrieken]

@octref what format, bitmap?

[jrieken]

Plan is to design this to be like the async clipboard API: https://www.w3.org/TR/clipboard-apis/#async-clipboard-api, https://developer.mozilla.org/en-US/docs/Web/API/Clipboard. Something like this

readText():Promise<string>;
writeText():Promise<string>;
read():Promise<Data>;
write(data: Data):Promise<void>;

The more generic read/write apis might become a challenge because Electron doesn't provide a good foundation for this (and because it would require chrome 66 to get this form the browser). So, this might be restricted to just a few types in the beginning.

[DanTup]

@jrieken Is it likely this would enable https://github.com/Microsoft/vscode/issues/30066? It'd be great if copy/pasting code could automatically bring required imports/aliases/etc.

[jrieken]

@DanTup #30066 isn't related to this

[jrieken]

This is done as proposed API. The finalisation will happen next milestone.

[jrieken]

To verify, write an extension that uses this API proposal: https://github.com/Microsoft/vscode/blob/25589f6cc4aa3450450fa0f49979fcf7835f52d4/src/vs/vscode.proposed.d.ts#L42-L50

[octref]

For verifier: I made a sample to illustrate how to use proposed api. Maybe you can use this as a starting point for testing the clipboard API:

https://github.com/Microsoft/vscode-extension-samples/tree/ext-docs/proposed-api-sample https://vscode-ext-docs.azurewebsites.net/api/advanced-topics/using-proposed-api

[fuzzzerd]

Will extensions ever have the ability to read and write custom clipboard formats? Text is a great start, but I have a situation where a tool is putting xml data on the clipboard with a custom format. I'd like to be able to handle this in an extension and show the xml in vscode. Since its a custom format, there is no data in the 'text' buffer of the clipboard and pasting into notepad (or vscode) for example yields nothing.

I have a simple UWP app that achieves what I want; but I'd love to scrap that standalone and run it as a vs code plugin.

[jrieken]

@fuzzzerd https://github.com/Microsoft/vscode/issues/217#issuecomment-427782794

[fuzzzerd]

@jrieken I saw that. I could not find readData/writeData in vscode.proposed.d.ts though and in vscode.d.ts I only see the readText/writeText methods.

So I was wondering if comment 217 was still the long term plan or if it was only for text data.

In any event, is this the right issue to watch for clipboard related api changes going forward?