Specification to open a second completion after apply a completion item

[angelozerr]

One feature that I love when I write code is the completion apply which opens a second completion popup which suggests the values that you can insert after completion apply.

Here a Java demo which defines 2 int variables (i and j). When substring method completion is applied, it suggest completion popup for the substring parameters which are int.

There are other usecases like HTML/XML (when completion for attribute is applied, it suggest values for attribute values, etc).

It should be cool if LSP could specify a new protocol to manage that (by extending completionItem/resolve?)

[mickaelistria]

I think this can be covered by using placeholder and choices which are already specified for completion.
But these placeholders don't get rich information like what completion gives. So there is indeed room for improvements.
Maybe the Completion response could add a new type of placeholders that could be "completablePlaceholders" with one default value for insertion, tab stops and so on, and just giving the hint that on edition of this placeholder, a new completion request should be sent?

[mickaelistria]

Actually, as I'm thinking about it, I don't think we need the protocol to state something about it: if there is a placeholder, it's most likely that user will probably want to edit it, and if user wants to edit it, why wouldn't the client ask for another completion?
FWIW, automatically asking for completion on placeholders would be a welcome addition to LSP4E for instance.

[DanTup]

There is a command on CompletionItem which we use in the (not currently LSP) Dart plugin to do just this:

https://github.com/Dart-Code/Dart-Code/blob/7df6509870d51cc99a90cf220715f4f97c681bbf/src/providers/dart_completion_item_provider.ts#L197-202

However, it's not clear how this could work with LSP since that command is VS Code-specific. I guess if you're implementing both the LSP server and the plugin the wraps it for an editor, you could send a custom command and then map it on to the appropriate thing for each editor, but it's messy.

[angelozerr]

Thomas Mäder (@tsmaeder) told me that it exists a specification for snippet choice https://github.com/Microsoft/language-server-protocol/blob/master/snippetSyntax.md#choice

Mickael Istria (@mickaelistria) I'm not sure that LSP4e implement that ?

I think it's a good idea for values which not require complex computing. For other case like Java completion apply, I think it should be better to call a command. We could have a syntax snippet like this:

${1(myCompletionCommand)}

[DanTup]

I think it should be better to call a command. We could have a syntax snippet like this:

There's already a command property on CompletionItem (see my previous comment above) - isn't this the same as what you're requesting?

[mickaelistria]

Eclipse LSP4E implements snippet choice IIRC. But anyway, I still stand with my former command #565 (comment) : there is nothing preventing the client from invoking content assist at the location of placeholders and I don't think we need addition in LSP spec to do that.

[angelozerr]

Eclipse LSP4E implements snippet choice IIRC.

That's strange, I have tested with lsp4xml, but it doesn't work? Where is the supposed code which manages the open of the second completion popup with choice values?

[mickaelistria]

I have tested with lsp4xml, but it doesn't work?

Sorry you're right. Eclipse LSP4E has support for linked regions but not yet for snippet proposals. Feel free to open a new bug to LSP4E for that (and even for re-triggering completion when on another region and no snippet proposal is found); but still I don't think the spec needs anything more.

[dbaeumer]

Looks like this doesn't need any addition in the spec. Any objection to close the issue?

[DanTup]

Dirk Bäumer (@dbaeumer) Actually, I think my comment above may be incorrect. Thinking again, it's not clear whether the command on a completionItem is a command that the LSP client sends back to the server (via executeCommand) or a command for the client to execute (eg. like calling editor.action.triggerSuggest).

I assumed you could put editor.action.triggerSuggest in it (since that's what I do in the equiv field in the VS Code API), however now I'm thinking this is unlikely, since an LSP server probably shouldn't be relying on internal command identifiers that may of may not be available on the client.

Can you clarify which it is - is CompletionItem.command the ID of a command the LSP server handles (via executeCommand) - in which case I think this requres is not currently possible - or executed by the client (in which case, should LSP define well-known commands that the server can call on the client)?

[DanTup]

Actually, the spec does say this!

The protocol currently doesn’t specify a set of well-known commands. So executing a command requires some tool extension code

And the thing that decides which commands should be sent to the server versus executing in the client plugin is ExecuteCommandOptions.

TL;DR - putting editor.action.triggerSuggest in the command on a CompletionItem probably works, but since it might not be consistent across editors, may be better as a custom command.