Our use of the syntect plugin for syntax highlighting predates the existence of language identifiers in core. The syntect plugin current determines the syntax to use based on the path of the file, and updates it when the file has changed.
This is now redundant. Instead, the language identifier that is assigned in core (which may be guesed from the filename or the file's first line, or may be overridden by a user) should be the sole/canonical source of truth.
This means that:
LanguageId should be included in the set of info we send the plugin.LanguageId changes in core, we should update the plugin (and the client) similarly to how we do currently when a config changes. This _probably_ means adding a new core->plugin RPC; I could one day imagining combining these into a per-buffer 'metadata' RPC, but for now separate is fine.LanguageId on its own; it should use what is provided by the core.There are still some kind of weird things related to languages and configs. For instance, there should be a config setting that allows the user to specify which language to assign to files, based on their extension; and so this config, when changed, could potentially change the language of an open file, which would cause it to update its config.
It also isn't clear how, long-term, we're going to manage plugin lifecycle, but we may end up doing something like #374, which might require changing how we tell plugins about language changes, but I think this change is reasonable for now.
The checklist you've outlined looks good! I'll be taking this on as discussed on IRC.
Most helpful comment
The checklist you've outlined looks good! I'll be taking this on as discussed on IRC.