Feature request: prepare paste request.

[vasiltabakov]

For languages having types it would be very useful to get a list of all "symbols" and their respective reference types for a given range.

My use case comes from a Java project where I'm pasting a snippet from one file to another within the same project. When copying the code the editor could make a request to the LS and receive the types. Then upon pasting in a new document the LS could automatically import those types. That is in a Java project add import statements based on any the pasted code.

An even wilder suggestion is to implement a paste request indicating a source and target file and source range for files within the same project.

This kind of types request could be useful in many other situations.

[dbaeumer]

Actually the whole beauty of the LSP is that it doesn't talk about symbols. The protocol most talks about editor concepts like ranges, text and edits. So to support this in the spirit of the LSP we would need a request that computes the edits for additional import statements for a given piece of text pasted into a document a a certain position.

I have adjust to the title accordingly.

I am absolutely open for such a new request. Good opportunity for a request proposal.

[vasiltabakov]

Interesting, your way of describing what the LSP is all about. In fact we do use it in our IDE, this paste thing is a very IDE-y feature indeed.

[dbaeumer]

For the spirit of LSP you might want to have a look at https://microsoft.github.io/language-server-protocol/overview

[333fred]

@dbaeumer, I could see 2 possible request-styles going forward, I'm curious which you would be more open to:

1. Adding a new field to TextDocumentContentChangeEvent, something like wasPaste. The server could then send a workspace/applyEdit request for anything it wanted to do, such as formatting/importing new types/etc.
2. Add a new onPasteFormatting endpoint, in the same vein as onTypeFormatting. This would allow vscode and similar clients to provide a global option for the feature, much like on type formatting today, but is potentially less extensible?

I'm open to making either proposal, just want to get direction before fleshing it out.

[dbaeumer]

We discussed this lately and it should definitely go into the second direction. One other alternative is to have a context on range formatting which ask for the computation of additional edits to fix the imports. The downside of this is that we first paste and then format. The upside is that the server see the whole document and can better detect scopes. In addition it is multi cursor agnostic.

[dbaeumer]

Please be aware that a spec proposal must always go in hand with one implementation for a used client (e.g. VS Code, Eclipse, VS, ...)

[333fred]

Please be aware that a spec proposal must always go in hand with one implementation for a used client (e.g. VS Code, Eclipse, VS, ...)

Understood. My hope is that I can copy/paste much of the onTypeFormatting handler :).

[333fred]

@dbaeumer is the documentation in the how to contribute section up to date? https://github.com/microsoft/language-server-protocol/blob/master/contributing.md#how-to-create-a-protocol-extension mentions creating a the markdown and proposed.ts files directly in here, but I don't see anything similar in the structure, and it looks like most of the rest of the protocol definitions are under src/common?

[333fred]

Ah, no, I missed the steps later on in the doc. Consider this some gentle feedback that the way the docs are currently structures is a bit confusing :).