Can we store files.associations elsewhere?

[bbalp]

Here is why. The default gitignore file VSCode is giving here lets us track the changes from settings.json. But the more I am working on my projects, the more file associations are randomly (I don't decide when) generated. It feels for me that file.associations should be stored in a place not tracked (ignored) by the VCS as it is an automatically generated content.

I would be pleased to have your opinion on that.

[sean-mcmanus]

Our tool automatically adds a c/cpp to file.associations whenever the a C/C++ file with an extensionless or non-standard file extension is navigated to via a source file -- this enables the header file to be treated as C/C++ for colorization and other features (otherwise, it opens as a text file). The only mechanism VS Code provides for enabling this scenario is updating the files.associations setting, which is stored in the settings.json, and there's no mechanism for storing other settings elsewhere. If you have a proposed alternative design, it would probably have to be implemented in VS Code itself (https://github.com/Microsoft/vscode/issues ). One potential solution is for the openTextDocument called internally by VS on a Go To Definition to automatically supply the languageID of the source file. We could also add a setting to turn off this behavior or you could modify the /out/src/C_Cpp.js yourself to replace code con.update("associations", assoc); with ; (and/or add a script to do the replacement for when the file is overwritten by an update).

[bbalp]

Thank you for this clear and precise answer. I keep this issue open and will explain the situation in an issue on the vscode project to have their opinion, as you suggested.

[rkeithhill]

I find this annoying as well. More and more in VSCode I work in multi-language workspaces. I have one that is primary a Node project but uses node-gyp to compile some C++ code into a library that can be called from Node.

This extension is frequently change the workspace's settings.json file in a way that makes no sense to me. That is, I look at the modified file and can't really tell which extension change the file (other than the "cpp" hint) and I don't know why. Perhaps at the very least, the extension should add a comment explaining that it modified the file and why.

[sean-mcmanus]

@rkeithhill What exactly is changing in the workspace's settings.json? I assume you mean the files.associations. That should only be changed when a Go To Definition results in an extensionless or non-standard extension result target, which we "need" to add the files.associations for, otherwise the file would appear as plain text (causing our extension not to work on any of the C++ library files like iostream). I don't know what you mean by having the extension add a comment explaining the modification. Where would that comment go? Did you want a setting to disable this behavior or another solution?

Also, we changed our extension so that it should only activate after a C++ file is opened, so we shouldn't be making this change when non-C++ processing is being done, even if there happens to be some C++ in the workspace somewhere.

[rkeithhill]

This is the change that was made along with a comment suggestion:

  "files.associations": {
    // Added by Microsoft C++ extension in order to ...
    "ostream": "cpp"
  }

BTW I'm doing some editing on the .cpp/.h files. Cleaning up formatting, etc.

Yes, a setting to disable this would be nice.

[sean-mcmanus]

VS Code doesn't provide an API to add comments to settings files (and our json parsing API doesn't allow adding comments, because it's not official json...they call it "jsonc".). We can add the disable setting, but I'm not sure when it will be implemented yet.

[BillyONeal]

It would be nice if the extension would not attempt to change this setting if the file was already recognized as C++ before modifying. For example, we have a checked in settings.json that does:

{
    "files.associations": {
        "**/stdhpp/**": "cpp" // <-- all the nonstandard file names got picked up here
    },
    "files.exclude": {
        "binaries": true,
        "Intermediate": true,
        ".shadowbinaries": true,
        "out": true
    }
}

but the C++ extension keeps editing this file :/

[sean-mcmanus]

@BillyONeal We might be able to add a filter for existing glob patterns (our current filter just handles the file, **/file, *.ext, and **/*.ext cases).