getLanguageConfiguration() API method is missing

[minherz]

Currently the languages namespace has setLanguageConfiguration() method but does not have getLanguageConfiguration() method. This is a blocker for extensions that need to base the functionality on some properties of the document's language configuration. For example, depending on support of the one line comment vs. multi-line comment in the language syntax, the extension might follow different patterns.
Before introducing development in container it was possible to hack into the vscode directory and read the language configuration. This behavior does not work correctly with containers. If the extension is launched in the container it cannot read vscode on local machine and vice versa. It will come handy having this complimenting API as part of the official support.

[snnsnn]

@alexr00 This feature had received enough upvotes in #2871 but closed as duplicate in favor of this one and now waiting for upvotes all over again. It is so unfair. Please have the older issue open and close the newer one.

[ap-1]

cc: @jrieken

I don't know why the original issue was closed while this one was left open, but it seems to be a mistake? #2871, which this issue is a duplicate of, had already received sufficient upvotes

[zm-cttae]

I have this data available as a service in the vscode-textmate-languageservice library.
I will be packaging up an API for the 'hack' at the end of the month.

[tahabasri]

I'm currently relying on a tweaked version of [this answer] to retrieve all languages names/extensions (#17885 (comment))

const getLanguages = () => vscode.extensions.all
        .map(i => <any[]>(i.packageJSON as any)?.contributes?.languages)
        .filter(i => i)
        .reduce((a, b) => a.concat(b), [])
        .filter(i => 0 < (i.aliases?.length ?? 0))
        .map(i => { return {
            alias: i?.aliases?.[0],
            extension: i?.extensions?.[0]
            };
        });

[zm-cttae]

https://github.com/vsce-toolroom/vscode-textmate-languageservice/releases/tag/v2.0.0

• Add getTokenInformationAtPosition, getScopeInformationAtPosition, getScopeRangeAtPosition method to get token data.
• Add getLanguageConfiguration method for language configuration: vscode.LanguageConfiguration.
• Add getGrammarConfiguration method to get language grammar wiring: GrammarLanguageDefinition.
• Add getContributorExtension method to get extension source of language ID: vscode.Extension.

Please star the project on GitHub if you think there is further use you could make of it.

[lastobelus]

@zm-cttae If anycode doesn't include a language I'm interested in, is vscode-textmate-languageservice still my best bet for developing extensions if I need to treat code as code? How heavy is it? The current language I'm most interested in is Elixir, and the ElixirLS already adds a lot of fan noise to using vscode :)

[yCodeTech]

It seems that Microsoft doesn't actually care about it's users, because this issue was added to the backlog in #2871 which was very unfairly deemed as a duplicate of this one by @alexr00, despite the fact that issue precedes this one.

It's been 4 years since, what I would declare as the original issue in #2871, was added to the backlog. Please give your users and extension developers the respect they deserve and add getLanguageConfiguration(langId) to the API.

I would love to be able to get the language configuration in my extension to better help it's development.

[zm-cttae]

@lastobelus I wouldn't class it as heavy for sure - It's been rewritten to be (almost) as fast as possible. There's (maybe) a small bloat from the fact that it can generate language symbols through token scanning, but that won't be an obstacle at runtime.

Worth noting that it doesn't bypass the devcontainers issue.