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

[sean-mcmanus]

@rkeithhill Our next update will add a setting to disable automatically adding to files.assocations.

@BillyONeal We've also added support for glob patterns, so if we try to add a file like "string" that already matches a files.association glob pattern like "**/include/**": "cpp" then we won't add "string" to the files.association.

[BillyONeal]

@sean-mcmanus Thanks!

[BillyONeal]

@sean-mcmanus Should this be showing up in the insider's build yet? I'm still seeing things get clobbered :(

[sean-mcmanus]

@BillyONeal The VS Code marketplace doesn't currently support an insider channel. We're planning to release a preview .vsix for the January release with the fix tomorrow, with the official release next Tuesday.

[BillyONeal]

Ah, I should have said "preview" rather than "insider" -- I meant the version that the VS Code Insiders build installs, with this icon:

[sean-mcmanus]

C/C++ is always marked as Preview -- the only thing that does is make that "Preview" image appear. We just use it indicate that we're not really feature complete and don't have support for multiple languages/encodings etc. (the same as the 0 in our 0.14.6 version number). It doesn't enable any sort of preview channel fixes to get used. The marketplace would have to enable us to submit a preview and non-preview vsix to enable a difference (with preview versus non-preview Install buttons). See microsoft/vscode#15756 .

[BillyONeal]

Today, I learned :). Thanks!

[sean-mcmanus]

@BillyONeal @rkeithhill We have a pre-release with the fix if you want to try it out (https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.14.6-insiders) and let us know if there are any fixes we should make before our release next week.

[BillyONeal]

Looking good so far :thumbup2:

[sean-mcmanus]

We now skip automatically adding to files.associations if it matches an existing glob pattern or if C_Cpp.autoAddFileAssociations is false -- note the setting got renamed post-Insider (which used files.associations.autoAdd). https://github.com/Microsoft/vscode-cpptools/releases/latest .

I'm closing this issue -- let us know if there's still a problem in the scenario (I don't think we can do anything further without a VS Code change).

[herrberk]

Current way of removing file associations is to add the following to .vscode/settings.json:

{
    "C_Cpp.autoAddFileAssociations": false
}

[akbyrd]

This is solution is far from ideal since it disables the cpp extension when navigating to standard library headers. In my opinion, this effectively replaces a nuisance with a defect.

I think a request needs to be pushed to the main vscode repo to support a proper solution here. We have the ability to set the language on a new file that hasn't yet been saved to disk, so clearly there's and in-memory way to set the language mode for editors. It shouldn't be a large step to allow extensions to leverage that.

EDIT: Made an issue in the main repo: microsoft/vscode#78968

EDIT 2: A potential existing solution was given in the linked issue. Maybe this is already possible to fix robustly?