Closed
Description
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.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
sean-mcmanus commentedon May 12, 2017
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 commentedon May 12, 2017
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 commentedon Dec 19, 2017
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 commentedon Dec 19, 2017
@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 commentedon Dec 19, 2017
This is the change that was made along with a comment suggestion:
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 commentedon Dec 19, 2017
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 commentedon Dec 20, 2017
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:
but the C++ extension keeps editing this file :/
sean-mcmanus commentedon Dec 20, 2017
@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).3 remaining items
BillyONeal commentedon Jan 9, 2018
@sean-mcmanus Should this be showing up in the insider's build yet? I'm still seeing things get clobbered :(
sean-mcmanus commentedon Jan 9, 2018
@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 commentedon Jan 9, 2018
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 commentedon Jan 9, 2018
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 commentedon Jan 9, 2018
Today, I learned :). Thanks!
sean-mcmanus commentedon Jan 9, 2018
@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 commentedon Jan 9, 2018
Looking good so far :thumbup2:
sean-mcmanus commentedon Jan 17, 2018
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 commentedon Apr 5, 2019
Current way of removing file associations is to add the following to
.vscode/settings.json
:akbyrd commentedon Aug 12, 2019
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?