How to respond to rename request if user cancelled (via a showMessageRequest)?

[DanTup]

I have this scenario:

• User invokes rename
• The location is valid, so prepareRename returns normally
• User enters a name that is already in use (or some other name that would result in invalid code)
• Server sends a showMessageRequest informing the user this will produce an error, with options to "Rename anyway" or "Cancel rename"
• User clicks "Cancel rename"

In this case, if I respond to the original rename request with RequestCancelled, VS Code will show an information notification saying it was cancelled. If I return null, it will show an information notification showing "No result":

So my next thought is to return a WorkspaceEdit that has no changes in it. However, it feels awkward and it's not clear whether this is the correct route.

The spec isn't really clear what a null response means here (nor is it generally clear when clients should/should not show notifications for some responses). This is just one example, but I can imagine many other types of requests could be cancelled by the user via a showMessageRequest, so I think it should be clear how servers should response to requests cancelled in this way (that the client doesn't know were cancelled, because it was server-logic) and how clients should handle that.

[dbaeumer]

I think the right approach is to use RequestCancelled (or if we think it is necessary a new RequestUserCancelled) in the response. IMO it is up to the client library to wire this up to the right cancel semantic in the editor.

So the question for me is how this is best signaled in VS Code itself. @jrieken currently I will convert this into an Error with the name set to Canceled as we do for semantic highlighting. What is your proposal to handle this. Should I convert it to an empty workspace edit?

[jrieken]

I think the problem begins with showing a "custom" message with options. You leaving the flow of rename. This is also a problem for scenarios like LiveShare. The cancel-error thing might work for VS Code, worth trying.

[DanTup]

I think the problem begins with showing a "custom" message with options

Are there any alternatives for this? I had this functionality in the non-LSP implementation and it was noticed as missing from LSP, so I added this. It doesn't seem like a weird case to want to prompt the user if the rename might introduce errors (though this request was more general - there could be many reasons why a server wants to cancel a request and may wish to communicate this to the user itself instead of making it seem like something has gone wrong at the protocol level).

In this case, returning an empty WorkspaceEdit works fine (it's what I've done with for now), though it's just not clear if it's the "best" way.

This is also a problem for scenarios like LiveShare

Can you elaborate? As far as the client knows, there was a rename request and it either returns a rename edit or it returns an empty edit. I wouldn't expect that there was a user prompt somewhere in the middle that influenced that decision to change how the rename would work? It's not much different to a ContentModified response - which I think is already silently dropped by the client.

[DanTup]

Another feature request came up that makes it attractive to prompt the user mid-rename, but it's not clear from the above if it's a bad idea):

Dart-Code/Dart-Code#3354

In this case we don't need to be able to cancel, but we might want to prompt the user (in this case, asking if they want to rename the file when they rename the class inside it).