Switch to using setTextDocumentLanguage instead of adding to files.associations

[sean-mcmanus]

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 #722 .

[sean-mcmanus]

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

[bobbrow]

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

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

[sean-mcmanus]

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]

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

@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: microsoft/vscode#130642

[ahojnnes]

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]

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]

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]

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

[sean-mcmanus]

@ngunderson No update.

[amurzeau]

What about persisting this information in workspaceStorage for example ?

[sean-mcmanus]

But how would the user see/modify the value in the workspaceStorage? I mention this in my comment #4077 (comment)

[geertj]

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

[sean-mcmanus]

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

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]

This kind of all-consuming glob pattern helped me:

"files.associations": {
	"**/Microsoft Visual Studio/**/MSVC/**/include/**": "cpp"
}

[sean-mcmanus]

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

[thernstig]

Found this issue here. What is strange it even adds other file extension associations as seen, see the "uv.lock": "toml" part:

I have that config set in my application settings JSON file:

  "files.associations": { // remove later when included in TOML extension
    "uv.lock": "toml",
  },

I wonder if it is because of this is that this extension also includes that part?

The update of the .vscode/settings.json seems like a high prio bug as it wastes a lot of DX time for everyone.

But I am unsure why this cannot be solved like done in every other extension that has language support? Here is an example where I pushed a PR to add support for another case for TOML.

https://github.com/tamasfe/taplo/blob/db31b2b1e321357b19d43d7b0e2980805c59309c/editors/vscode/package.json#L78-L93

For this repo, it would look like this for C files (same can be done for CPP files):

 "languages": [ 
   { 
     "id": "c", 
     "aliases": [ 
       "C" 
     ], 
     "extensions": [ 
       ".c",
       ".h"
     ]
   } 
 ], 

With those settings there should not be a need to update the .vscode/settings.json for each of those .h files.

I understood this issue as talking about problems with non-file extensions. But there should be no need to update the settings.json for the common, already known file extensions applicable for C/C++, should there? There is a possibility I might have misunderstood this entire thread.

I pushed this as an example:
main...thernstig:vscode-cpptools:main