Open DennisKehrig opened 11 years ago
This is per @peterflynn's suggestion
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).
@njx FileUtils.updateFileEntryPath
now also triggers a rename event on NativeFileSystem.Entry
Said event was removed in #2961
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.
Seems this has been forgotten, but it's still a bug.
@peterflynn Hi Peter, please take a look at this and the pull request referenced above. Thanks a ton.
I did the scrub NJ had suggested. Looks like there are at least a few items here:
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).
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.
@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).
@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).
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.