Rename provider should support to 'resolve' rename location (to expand, invalidate, etc)

• VSCode Version: 1.2.0
• OS Version: Windows 10

I’m having trouble with getting VS Code to do a rename operation correctly. When I put the caret on the word I want to rename and I hit F2, I see this:

However, if I do the same operation (F2) on a simple string, I get just the contents I expect:

[aeschli]

It look like rename is using the css word rule to determine the word at the location. This doesn't work well with structured content inside string on which this rename wants to work.
Maybe the rename support should be able to tell what range is modified?

It makes sense to me that if there is a selection, the rename operation should apply to the entire selection. If there isn't a selection, then the rename should apply to the word that the caret is currently inside of.
An even better option (in my opinion) would be to add a new provided named RenameRangeProvider that could be registered to tell VS Code what range to rename given the current selection.

[jrieken]

@daschult I what language do you see this? As in many other places we rely on the word definition each language can contribute. Under the hood rename is a positional operation and doesn't mind what the current word is - it's only to populate the UI

This happens in a JSON file.

[jrieken]

Closing as we only have the word definition so expand the a selection into something more meaningful. This doesn't affect how the rename feature works.

[aeschli]

@jrieken I think we should reconsider. Marking this 'as designed' means we don't support rename for embedded languages.
The initial word is important for the user to understand what is renamed. In this example showing the wrong word will completely confuse the user and the user will never use the refactoring. The word rule of the host language can not be used here. What if the rename provider can override the word rule? Maybe provide range for a offset. Normally there's just one rename provider for a position. Not sure if we support multiple rename providers for the same positions, I guess we would need to pick one (or what happens if there are two and both make changes to the same documents and even locations?)

[jrieken]

we don't support rename for embedded languages.

Why? The editor always uses the word rule of the corresponding mode, so I don't see why we would not support that? Actually, we did support it already with the 'old world'

[jrieken]

reopen since @aeschli is very passionate about this

[aeschli]

Also the old world would not support that scenario. The JSON mode can not (and should not) know what's the language inside the string literal. Maybe one day we will have a mechanism where we we can express embedded languages ranges.
But in this case, we don't need the full embedded language story. The current providers do to a great job of letting the Azure extension add all the supports they need. If they could also tell us what they intend to rename, then we can properly initialize the rename box.