Add preparePaste method to check if copied text should potentially have smart paste enabled or not

[mjbvz]

🔍 Search Terms

• copy paste
• smart paste
• paste with symbols

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Add a new preparePasteEdits api that lets editors quickly check if copied code may have a paste edit or not. preparePasteEdits would be called on copy, while today getPasteEdits is called on paste

This would align with the VS Code paste API proposal: https://github.com/microsoft/vscode/blob/cbcf121deb9f7195e7dc1d63b298b98b254bba5a/src/vscode-dts/vscode.proposed.documentPaste.d.ts#L85

📃 Motivating Example

On paste, VS Code shows UI that lets users select how the content should be pasted. For TS, we now show a paste with imports:

In order to keep the editor response, we need to show this paste UI quickly after paste. However the TS paste edit may take some time. To mitigate this, we've:

• On the VS Code side, restricted the cases when we try getting TS's paste with imports (only if pasting between VS Code files). This uses a prepare API that lets a provider add metadata on copy that controls if a paste edit may be available or not

• Let paste providers deprioritize their edits so that show up later in the list (and don't have to be fully resolved right away)

• Added API that lets paste edit providers deferring computing the workspace edit for a paste until we need to apply it (see resolveDocumentPasteEdit)

However the UX for TS pasting is still too slow to enable by default. A big cause of this is that paste with imports gets triggered even when pasting source that does not have any importable symbols, such as text from a comment or string. We should be able to determine this when copying and avoid showing paste with import at all in these cases

Here's what I think the vscode <-> TS flow should look like:

• On copy, VS Code calls preparePasteEdits for the copied text. This signals if there may be a paste edit or not. This check should happen fairly quickly

• If preparePasteEdits returns false, VS Code does not try asking TS for paste edits when the clipboard content is pasted

• If preparePasteEdits returns true, then on paste VS Code will call getPasteEdits to get the actual edit

[mjbvz]

I'm not sure it's needed, but we could also add a resolvePasteEdit call that let us delay computing the workspace edit. This would align with how the VS Code copy paste api is designed

As a quick overview of how the VS Code paste api works:

• prepareDocumentPaste — Called on copy. Can store metadata in the clipboard

• provideDocumentPasteEdits — Called on paste. This returns an array of paste edits. These paste edits are shown in the the UI. This call will block pasting if it is long running

• resolveDocumentPasteEdit — Called when a specific paste edit needs to be applied (such as getting selected from the paste edit list). This lets a provider fill in workspace edit that applies the paste if computing the workspace edit is slow

The main use case for the resolve step is for when you know a paste edit exists but determining how to apply it takes time. A good example is if we need to go out to a llm to get the edit. I'm not sure if this is a perf issue for TS too