Language changes due to renames are not sufficiently recognized

[DennisKehrig]

For instance, when changing a file's extension from "txt" to "js", JSLint doesn't open. Only the editor mode is updated, but this is also only true for the current full editor.

Note that #2844 will introduce a "languageChanged" event that editors listen to in order to update their mode. JSLint and other tools could listen to the same event.

[DennisKehrig]

This is per @peterflynn's suggestion

[njx]

Marking move to backlog, to consider along with other rename issues (since rename isn't an "official" feature yet). Note that we will probably also want some other, more general event when a document is renamed, but it does make sense to specifically have a languageChanged event as well, since we've talked about allowing users to manually set the language of a document (e.g. if it doesn't have a file extension that we know about).

[pthiess]

Trello lists this story.

[DennisKehrig]

@njx FileUtils.updateFileEntryPath now also triggers a rename event on NativeFileSystem.Entry

[DennisKehrig]

Said event was removed in #2961

[njx]

Looks like this should be straightforward to fix now that we have the languageChanged event. We should also scrub everything in the app that gets the mode and make sure all those places properly update.

Marking medium priority to me.

[marcelgerber]

Seems this has been forgotten, but it's still a bug.

[pthiess]

@peterflynn Hi Peter, please take a look at this and the pull request referenced above.
Thanks a ton.

[peterflynn]

I did the scrub NJ had suggested. Looks like there are at least a few items here:

• Linting results need to update
• In JavaScriptCodeHints, handleActiveEditorChange() needs to get rerun to install/remove listeners when a file changes to/from the JS language
• Other aspects of JavaScriptCodeHints may need updating too (e.g. triggering a file to get read in by ScopeManager or ejected if it has previously been read in)
• What does changing language mean for the state of a live development session? We might need to trigger a navigation if the current document is changed to HTML from something else. If the current document was HTML and is changed to something else, it's less clear what we would do -- would we close the live development session, or continue showing the now non-HTML file, or automatically navigate to a different file..?
• The currently applicable custom view provider might need to change (though this couldn't be triggered by Switch language / syntax mode of current document #6409, which is only accessible in text viewers)

This is ignoring API usages by features that are highly transient (code hints, quick open) or that show a persistent results view but the results are static (HTML->CSS inline editor results list, JS inline editor results, CSS inline quick docs).

[njx]

To @peterflynn. I didn't add a feature category - none of the existing ones seemed appropriate and I wasn't sure if we want one specifically for the language management stuff, since there probably aren't a huge number of issues there.

[busykai]

@njx, @peterflynn I think this issue should be fixed as we merged #6409. All the language-related subsystem now should be reacting to the language changes (due to rename or forced).

[peterflynn]

@busykai It definitely fixes the most important issues here... looking at the checklist above, there are still a bunch of much smaller edge cases that I don't think we addressed yet. They also seem not worth spending time on in the near term, unless we get feedback from users to the contrary :-) So I'd be in favor of keeping this open but at a lower priority.

(I'll change priority from medium->low now).