microsoft
Switch to using setTextDocumentLanguage instead of adding to files.associations
The Septemember 2018 release added vscode.languages.setTextDocumentLanguage, so our extension can try using that instead of adding files to files.associations.
The previous thread is https://github.com/microsoft/vscode-cpptools/issues/722 .
Actually, this is problematic, because setTextDocumentLanguage is not persistent like files.associations is...
@sean-mcmanus did you try this and verify that it does not persist? We may need to re-engage with the VS Code team on this and come up with a solution that works for us.
I think this needs to be spec'd out. The set document language doesn't persist. We could persist it in a "hidden" way, but then users wouldn't have any ability to set those settings. Maybe we could add a setting for users who strong don't want the files.associations in settings.json, and maybe we could change the "hidden" setting after the user manually changes the language via the status bar (not sure).
@sean-mcmanus @bobbrow I am wondering whether there is any progress on this issue? I am hitting exactly the same issue, where I don't want the C++ plugin to modify my settings, which can be achieved by "C_Cpp.autoAddFileAssociations": false, but then the opened STL headers through code navigation are opened as plain text. Thanks.
@ahojnnes We could dynamically setTextDocumentLanguage, but the problem that needs to be solved is how to decide when to call that -- did you have a proposed solution? I believe we would need language type auto-detection for extensionless files from VS Code: https://github.com/microsoft/vscode/issues/130642
Unless I am missing something, shouldn't the language always be C++ when following headers from existing C++ code? I guess one could end up in a external C file but then C++ should still be good enough?
Yeah, if we're opening a file from a header, then the setTextDocumentLanguage will work, but then after a Reload Window or any other case where the header happens to be open again, the language would be reset unless the association is saved somehow.
We could fix it to call setTextDocumentLanguage on go to definition when the autoAddFileAssociaitons is set to false.
We could fix it to call setTextDocumentLanguage on go to definition when the autoAddFileAssociaitons is set to false.
I would say that this would already be an improvement over the current behavior.
Any update on this issue? Running into the same file association issue described in #722.
But how would the user see/modify the value in the workspaceStorage? I mention this in my comment https://github.com/microsoft/vscode-cpptools/issues/4077#issuecomment-598905870
Any update on this issue? It requires me to edit my .vscode/settings.json file before every commit.
@geertj No update. A potential workaround is to not commit .vscode/settings.json and instead commit a .code-workspace file with the shared settings for a prjoect. Then you can make a local copy of that file and open that workspace file so that files.associations don't get added to the checked in version. You could also potentially check in the files.associations with either settings (well, that may not work if the ordering is not stable, or there could be an issue with the list growing).
Why not to just make "C_Cpp.autoAddFileAssociations": false default behavior and generate those associations only if user manually create settings.json and set this value to true? I (and probably many other users) have never experienced any need for those autogenerated associations, meanwhile bad UX from irritating settings spamming is a thing I experience all the time from that extension.
This kind of all-consuming glob pattern helped me:
"files.associations": {
"**/Microsoft Visual Studio/**/MSVC/**/include/**": "cpp"
}
@Divelix The main reason is the system headers end up not being recognized as C++ files when they're opened, but maybe that could be fixed via using setTextDocumentLanguage for files located under a system include header path.