For copy paste, I added logic to prefer using the text content if there's both `image/*` and `text/*` content in the clipboard
This however I also incorrectly applied this logic when dropping. In those cases, we instead want to prefer the image data (at least we do in the case of dragging and dropping from VS Code's explorer)
* move creation of session into the session service, keep sessions ref-counted
* wip
* inline chat improvements
* turn the asyn-do-while loop into a state machine so that it can be paused/resumed
* externalize more state into Session and response types
* fix a few issues in the strategies and widgets
At present, copy providers on the ext host side return the full data transfer object passed to them (which includes any additions they make). We then use this to construct a new data transfer that is passed on to paste providers
There are a few bugs with this approach:
- If there are multiple copy providers, they can incorrectly end up overwriting each other. For example if the initial data transfer contains `text/plain` and there are two providers, the first of which tries writing a new `text/plain`, the second provider will overwrite this with the initial `text/plain` value
- If the original data transfer contains multiple entries for a mime, these always end up being overwritten with a single value
- We shouldn't waste type transferring value back to the main thread if the main thread already has them
This PR tries to fix this by skipping ext host to main thread transfer of non-modified data transfer items. As part of this work, I reworked a few internal structures and introduced a new `IReadonlyVSDataTransfer` interface to make it more clear when a internal data transfer is or is not expected to be modified
Fixes#173291
It's possible for the ext host to try performing an action on a webview that has been disposed but where the dispose message hasn't yet reached the ext host. We currently throw in these cases and there's nothing an extension could do to prevent this
With this change, I've removed the exception logic so these types of messages to the main thread will just noop. On the ext host side, we still throw an error if you try posting to a webview that the ext host knows for sure is disposed of. This is usually a real bug in extension code. Extensions can prevent it by checking if the webview they are holding has been disposed of before making a request to it
* cli: store cli in user data dir, separate per quality
Fixes#181017
On first run, the `~/.vscode-cli` will be migrated inside the user data dir of the currently running quality.
* use create_dir_all instead
* clippy fixes
