[WIP/RFC] Allow code actions containing an edit and a command #1760
Conversation
Note: Commands yielding multiple `applyEdit`s are still not supported.
honestly, I don't love it. I would prefer to send the "next list" on the response as opaque data and have YCM send it back to us if necessary. All In all, I'm not convinced that we need to have this complexity, given that there are still only "suggestions" that anyone will ever actually do this in a server. I would be tempted to wait until something actually uses it and see how it breaks in practice.. WDYT? |
There was a problem hiding this comment.
I would prefer to send the "next list" on the response as opaque data and have YCM send it back to us if necessary.
Let me see if I got your idea right.
Since this pull request only implements the case where we get an edit and a command (i.e. still no support for multiple applyEdits from a single command), we actually know the whole chain of fixits that we want to apply.
Therefore we can do away with the keep_going thing.
On one hand, that does seem more robust.
On the other, isn't that the opposite of what we are doing with completionItem/resolve, where YCM only gets "some number" and not the whole LSP completion item?
I would be tempted to wait until something actually uses it and see how it breaks in practice..
Dart language server already does this.
Reviewable status: 0 of 2 LGTMs obtained
Fixes #1692
WIP, because still no response to microsoft/language-server-protocol#2015
But also tests.
Previously, we could not handle two cases:
This pull request currently aims at the former. Manually tested with the Dart server and everything worked fine.
Design
LSP
Assuming we get a code action with an edit and a command, the client should do the following:
didChangenotification.Step 3 is still pretty much dark magic.
ycmd
Current implementation, when faced with "mixed" code actions does:
keep_goingtoTrue.keep_goingset, after applying, it should ask ycmd for the next FixIt in the chain.4.1. I couldn't figure out a better way than to introduce a new route -
/next_fixit/next_fixitrequest, ycmd will execute the previously stored command (step 2).Obviously,
/next_fixitandkeep_goingare prone to bikeshedding.I'm more concerned whether the whole idea about storing the command for later is a good approach.
It works... but only because
:YcmCompleter FixItis synchronous. If it weren't, there'd be room for error.This change is