Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Derive Document language name from languages.toml name key #3338

Merged

Conversation

the-mikedavis
Copy link
Member

This changes switches from deriving the language name from the
languages.toml scope key to name (language_id in the
LanguageConfiguration type). For the most part it works to derive
the language name from scope by chopping off source. or rsplit_once
on . but for some languages we have now like html (text.html.basic),
it doesn't. This should be a more accurate fallback for the language_id
method which is used in LSP and currently uses the rsplit_once
strategy.

Here we expose the language's name as language_name on Document and
replace ad-hoc calculations of the language name with the new method.

This is most impactful for the file-type statusline element which is
currently using language_id.

It should also improve highlighting in popups for languages like html, erb, ejs, maybe solidity. For most languages there should be no functional changes from this PR.

Supersedes #2998
Should make #3273 more accurate

This changes switches from deriving the language name from the
`languages.toml` `scope` key to `name` (`language_id` in the
`LanguageConfiguration` type). For the most part it works to derive the
language name from scope by chopping off `source.` or `rsplit_once` on
`.` but for some languages we have now like html (`text.html.basic`),
it doesn't. This also should be a more accurate fallback for the
`language_id` method which is used in LSP and currently uses the
`rsplit_once` strategy.

Here we expose the language's name as `language_name` on `Document` and
replace ad-hoc calculations of the language name with the new method.

This is most impactful for the `file-type` statusline element which is
using `language_id`.
The `file-type` indicator element in the statusline was using
`Document::language_id` which is meant to be used to for telling
Language Servers what language we're using. That works for languages
with `language-server` configurations in `languages.toml` but shows
text otherwise. The new `Document::language_name` method from the
parent commit is a more accurate way to determine the language.
@the-mikedavis the-mikedavis force-pushed the md-refactor-language-id-and-name branch from 726bbef to 1c2473f Compare August 5, 2022 15:27
@archseer archseer added this to the 22.08 milestone Aug 19, 2022
@archseer archseer merged commit 5f043dd into helix-editor:master Aug 30, 2022
@the-mikedavis the-mikedavis deleted the md-refactor-language-id-and-name branch August 30, 2022 02:01
thomasskk pushed a commit to thomasskk/helix that referenced this pull request Sep 9, 2022
…tor#3338)

* Derive Document language name from `languages.toml` `name` key

This changes switches from deriving the language name from the
`languages.toml` `scope` key to `name` (`language_id` in the
`LanguageConfiguration` type). For the most part it works to derive the
language name from scope by chopping off `source.` or `rsplit_once` on
`.` but for some languages we have now like html (`text.html.basic`),
it doesn't. This also should be a more accurate fallback for the
`language_id` method which is used in LSP and currently uses the
`rsplit_once` strategy.

Here we expose the language's name as `language_name` on `Document` and
replace ad-hoc calculations of the language name with the new method.

This is most impactful for the `file-type` statusline element which is
using `language_id`.

* Use `Document::language_name` for the `file-type` statusline element

The `file-type` indicator element in the statusline was using
`Document::language_id` which is meant to be used to for telling
Language Servers what language we're using. That works for languages
with `language-server` configurations in `languages.toml` but shows
text otherwise. The new `Document::language_name` method from the
parent commit is a more accurate way to determine the language.
jdrst pushed a commit to jdrst/helix that referenced this pull request Sep 13, 2022
…tor#3338)

* Derive Document language name from `languages.toml` `name` key

This changes switches from deriving the language name from the
`languages.toml` `scope` key to `name` (`language_id` in the
`LanguageConfiguration` type). For the most part it works to derive the
language name from scope by chopping off `source.` or `rsplit_once` on
`.` but for some languages we have now like html (`text.html.basic`),
it doesn't. This also should be a more accurate fallback for the
`language_id` method which is used in LSP and currently uses the
`rsplit_once` strategy.

Here we expose the language's name as `language_name` on `Document` and
replace ad-hoc calculations of the language name with the new method.

This is most impactful for the `file-type` statusline element which is
using `language_id`.

* Use `Document::language_name` for the `file-type` statusline element

The `file-type` indicator element in the statusline was using
`Document::language_id` which is meant to be used to for telling
Language Servers what language we're using. That works for languages
with `language-server` configurations in `languages.toml` but shows
text otherwise. The new `Document::language_name` method from the
parent commit is a more accurate way to determine the language.
herkhinah pushed a commit to herkhinah/helix that referenced this pull request Dec 11, 2022
…tor#3338)

* Derive Document language name from `languages.toml` `name` key

This changes switches from deriving the language name from the
`languages.toml` `scope` key to `name` (`language_id` in the
`LanguageConfiguration` type). For the most part it works to derive the
language name from scope by chopping off `source.` or `rsplit_once` on
`.` but for some languages we have now like html (`text.html.basic`),
it doesn't. This also should be a more accurate fallback for the
`language_id` method which is used in LSP and currently uses the
`rsplit_once` strategy.

Here we expose the language's name as `language_name` on `Document` and
replace ad-hoc calculations of the language name with the new method.

This is most impactful for the `file-type` statusline element which is
using `language_id`.

* Use `Document::language_name` for the `file-type` statusline element

The `file-type` indicator element in the statusline was using
`Document::language_id` which is meant to be used to for telling
Language Servers what language we're using. That works for languages
with `language-server` configurations in `languages.toml` but shows
text otherwise. The new `Document::language_name` method from the
parent commit is a more accurate way to determine the language.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants