Change:
assert.strictEqual(v.isOK(StandardTokenType.String), false); assert.strictEqual(v.isOK(StandardTokenType.RegEx), false); }); <ins> test('language configurations priorities', () => { const id = new LanguageIdentifier('testLang1', 15); const d1 = LanguageConfigurationRegistry.register(id, { comments: { lineComment: '1' } }, 100); const d2 = LanguageConfigurationRegistry.register(id, { comments: { lineComment: '2' } }, 10); assert.strictEqual(LanguageConfigurationRegistry.getComments(id.id)?.lineCommentToken, '1'); d1.dispose(); d2.dispose(); }); </ins> });

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --We have started to get reports from users that Toggle Line Comments does the wrong thing: I think this stems from the default Clojure extension which sets to be a single . Calva changes this here: This has been working for years, and still does for many people, but some days ago it stopped working for some. I also notice that the default extension has moved to its own repository, where there is now a PR to fix the line comment configuration: However, I think it is wrong that the default extension sometimes overrides an installed extension here. Then that API can't be trusted at all. I worry about what more configuration is now sometimes being overridden. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.52.1 OS Version: N/A Steps to Reproduce: Calva a file the command Toggle Line Comment on an uncommented line Expected: It gets commented with Actual: It gets commented with Please let me know how I can assist in fixing this issue. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Not applicable
I am surprised that this ever worked reliably, it must have been some amazing timing luck. defines a language configuration at . Language configuration file handling is implemented by waiting for the language to be first used (like embedded in another language like a markdown fence or a file using the language is opened) and then reading async the language configuration file and applying it. This is done . Whenever the language configuration file finishes reading, it will go and configure the in pretty much the exact same way an extension calling configures it . So deep down there is no difference between those two calls and basically those two calls are racing themselves and it is lucky that until now the call reading the descriptive file was always faster than the imperative call from your extension. If you want to be sure to overwrite the builtin language configuration, you can define your own language configuration file using: But I also see how you would expect that the imperative call would "win" over the descriptive way, so maybe we can do something on our side to give a higher priority to the imperative call way of configuring languages.
Thanks !

This is great information. Calva has been relying on this luck for a very long time. And yes, I actually choose to do it the imperative way very consciously, assuming it was the way to be sure I could override the defaults.