Better source of languageId

[Belar]

Summary

Add more reliable source of languageId, stricter by definition.

Motivation

languageId is being sourced from name property in grammar, which is dedicated to "a human readable name for the language". Unfortunately, it can lead to ids which are off/incorrect.

Everything started with report about missing validation highlights in Vue single file components, which (in addition to missing proper configuration - fixed) is caused by incorrect languageId passed in messages to language server.

Official name (based on grammar developed within Vue organization) for language of Vue files is "Vue Component" (correctly set in grammar provided by "language-vue", package for Atom), but the id of language is "vue" (that's what language server tests for in order to perform validation).

Language information would be more reliable if there was a stricter way to define id of a language - for example, "Vetur" (extension for VS Code) can define id explicitly in extension's settings. Sources: 1 2

Describe alternatives you've considered

For the case described above.

1. name change in "language-vue" package.

A. Language name could be change in "language-vue" package, but since it's not wrong, it feels like a workaround (instead of solving the real issue)

B. More "aggressive" version would be to extend scope of "atom-ide-vue" and include grammar, with compatible name. It would mix language and ide extensions, plus "language-vue" is perfectly fine package.

2. Remove languageId check from language server

Language server could lessen the validation restrictions, but what it does isn't wrong - it wouldn't be solving the real issue.

Additional context

Potential solutions

1. Add a new property in or around grammar, dedicated to languageId

"name": "Vue Component",
"scopeName": "text.html.vue",
"id": "vue"

Note sure if above is valid (from TextMate grammar perspective), but it shows the idea.

2. Change primary source for languageId to scopeName

getLanguageId() {
  const scopeName = this._editor.getGrammar().scopeName;
  const language = scopeName && scopeName.split('.').slice(-1)[0];

  return language || this._editor.getGrammar().name;
}

The second option is likely a very breaking change (e.g. for javascript and typescript packages), first is backwards compatible, but it adds to "complexity".
I could work on a PR, but it would be great to hear from someone with more insight into Atom's ecosystem, and know what would be acceptable solution.

[UziTech]

Development of atom-languageclient has officially moved to https://github.com/atom-ide-community/atom-languageclient 🎉

If this is still an issue please consider opening an issue on that repo.

[ayame113]

I happened to find this issue, I think it was resolved atom-community/atom-languageclient#179.