Completion with text edits

[tomv564]

Sets up a post-completion hook so we can:

• Fix the completion using the item's textEdit (issue bug in auto completion when edit behind the completion position #536)
• Apply additionalTextEdits (issue additionalTextEdits support in auto completion #529)

completionItem/resolve is used to get the additionalTextEdits if the server indicates support.

Code is tested using examples given in issues, but more live testing with specific servers is needed!
Assumptions:

• If a command like 'commit_completion', 'insert_best_completion', 'auto_complete' runs, the next on_modified is the insertion of the completion.
• It is always safe to trim the difference between the start of the current word and the textEdit's start.
• All additionalTextEdits should be immediately applied after the completion is inserted.

To do:

• Get feedback from clangd , metals and others?
• Clean up code
• Look for holes / add tests
• UX considerations

[coveralls]

Coverage decreased (-0.7%) to 38.224% when pulling 85af377 on completion-with-text-edits into 00a6330 on master.

[ayoub-benali]

Thanks @tomv564 for taking a stab a this. I just made a test with Metals and both issues seems to be fixed 🎉

@olafurpg Do you have other use cases were this might still break ?

[olafurpg]

This looks great! Nice job 👏

The only example I can think of is when textEdit spans multiple lines. This is prohibited by the spec and VS Code filters out such completions. In Metals we can still sometimes returns those, for example

// before
val name = "John"
val message = """
Hello $nam<COMPLETE>
"""
// after
val name = "John"
val message = s"""
Hello $name
"""

[ayoub-benali]

@tomv564 Have you considered saving the additionalTextEdits contained in CompletionItem to apply them right after instead of doing a roundtrip via completionItem/resolve ?
LSP could be sending additionalTextEdits in the initial completion and not support completionItem/resolve

[tomv564]

Thanks for testing this so quickly, great to see your demo. Forgot to mention here, but @ayoub-benali your suggestions in #536 were key to getting this done!

In your example it's pretty clear that an import occurred, but imports added to the top won't be visible when you're two pages down. What do you think of showing a popup briefly (or less visibly, a message in the status bar)?

[ayoub-benali]

In your example it's pretty clear that an import occurred, but imports added to the top won't be visible when you're two pages down. What do you think of showing a popup briefly (or less visibly, a message in the status bar)?

I think a status bar message is fine because in my example an import was added but in general we don't know which kind of text edits are sent by the server

[ayoub-benali]

This looks great! Nice job

The only example I can think of is when textEdit spans multiple lines. This is prohibited by the spec and VS Code filters out such completions. In Metals we can still sometimes returns those, for example

// before
val name = "John"
val message = """
Hello $nam<COMPLETE>
"""
// after
val name = "John"
val message = s"""
Hello $name
"""

completion inside double quoted text isn't even triggered by sublime text see sublimehq/sublime_text#2793

Something has to be on sublime side before we can test this case

[tomv564]

@ayoub-benali LSP should already do what you suggested, the logic is roughly

if item.additionalTextEdits:
  apply_additional_edits(item.additionalTextEdits)
elif resolveProvider:
  resolve_completion_item(item)

[ayoub-benali]

Awesome !

[rwols]

Seems to be working fine for clangd.