Language-server-protocol: Clarify usage of {{value}} and cursor position after completion

[mickaelistria]

In #81, I learned that {{}} can be used in a completion item to indicate where cursor should be placed. The protocol documentation doesn't mention that. Can it please be added? Also some related questions:

• Does this apply to any TextEdit or only completion ones?
• Is this something that is configured?
• Would it make sense to avoid this workaround and have the TextEdit also contain an (optional) recommendation of a cursor position?

[kaloyan-raev]

This is related to #75.

[dbaeumer]

This was without any intention and we need to carefully think about how we deal with cursor positions in the protocol itself. I tried to stay away from this so far by not exposing any properties to manipulate the cursor position.

[mickaelistria]

See this interesting comment https://github.com/eclipselabs/eclipse-language-service/issues/57#issuecomment-254629377 . A solution could be that placeHolderStart and placeHolderEnd should be part of the completionOptions returned with the capabilities.

[mickaelistria]

Close as dup of #82

[rictic]

@mickaelistria Did you intend to say that it's closed as a dupe of #75?

[dbaeumer]

It is #75.

And we made some progress on this for the upcoming 1.8 release and it got already merged into some of the LSP client and server libraries for node.

[mickaelistria]

What kind of progress were done? Anything that applies to the protocol already?

[dbaeumer]

Yes, but not speced yet. The 2.6.x version of the node libraries available do have preliminary support for it in the protocol.d.ts. Look at SnippetString.

[gorkem]

@dbaeumer I am looking at the CompletionItem changes on the 2.6.x node libraries for this one. CompletionItem.insertText is now defined as insertText?: string | SnippetString; Unfortunately these union types are hard to map on languages such as Java, @svenefftinge has been working on a solution but the options are ranging from bad to worse. Can we spec this differently than the current node library implementation so that it is easier for strongly typed folks?

[dbaeumer]

@gorkem for the upcoming 3.0 library I speced a TypedString which can either be a normal string or a snippet string. So for people that can't deal with OR types they can always sent a TypedString.

[dbaeumer]

Just for clarification. The final design uses a insertTextFormat kind but provides the same functionality as the TypeString (no or types)

[gorkem]

@akosyakov, @svenefftinge does the insertTextFormat solution work for you?

[akosyakov]

@gorkem yes, we've modeled it as a enum: https://github.com/eclipse/lsp4j/blob/master/org.eclipse.lsp4j/src/main/java/org/eclipse/lsp4j/InsertTextFormat.java