microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.51k stars 1.55k forks source link

Switch to using setTextDocumentLanguage instead of adding to files.associations #4077

Open sean-mcmanus opened 5 years ago

sean-mcmanus commented 5 years ago

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 .

sean-mcmanus commented 5 years ago

Actually, this is problematic, because setTextDocumentLanguage is not persistent like files.associations is...

bobbrow commented 4 years ago

@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.

bobbrow commented 4 years ago

The VS Code issue on this: microsoft/vscode#78968

sean-mcmanus commented 4 years ago

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).

ahojnnes commented 3 years ago

@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.

sean-mcmanus commented 3 years ago

@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

ahojnnes commented 3 years ago

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?

sean-mcmanus commented 3 years ago

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.

ahojnnes commented 3 years ago

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.

ngunderson commented 2 years ago

Any update on this issue? Running into the same file association issue described in #722.

sean-mcmanus commented 2 years ago

@ngunderson No update.

amurzeau commented 2 years ago

What about persisting this information in workspaceStorage for example ?

sean-mcmanus commented 2 years ago

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

geertj commented 1 year ago

Any update on this issue? It requires me to edit my .vscode/settings.json file before every commit.

sean-mcmanus commented 1 year ago

@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).

Divelix commented 8 months ago

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.

Challanger524 commented 6 months ago

This kind of all-consuming glob pattern helped me:

"files.associations": {
    "**/Microsoft Visual Studio/**/MSVC/**/include/**": "cpp"
}
sean-mcmanus commented 6 months ago

@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.