Need an opinion on possible solutions when dealing with files not informing their content type in C++

[bbalp]

• VSCode Version: Code 1.12.2
• OS Version: Debian Jessie
• Extensions:

Extension	Author	Version
cpptools	ms-vscode	0.11.2

---

Steps to Reproduce:

Working on C++ projects, new entries are generated in files.associations just because I navigated to a file that do not inform vscode about its content type (no extension, etc.). But, settings.json is a file meant to be tracked by the VCS. I am currently being forced to .gitignore this file to not be bothered by new entries appearing regularly.

Example of file: iostream

---

Of course, I asked about this situation on vscode-cpptools first (microsoft/vscode-cpptools#722) where I got the following answer:

"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)." @sean-mcmanus microsoft/vscode-cpptools#722

Thank you @sean-mcmanus

---

It feels like a solution to this problem could involve a vscode enhancement / feature. We would be pleased to have your opinion on that. :)

[sandy081]

This is a perfect case for Non-shareable workspace settings.

[jhasse]

This is a perfect case for Non-shareable workspace settings.

Does an issue for this exist? Something like a .vscode/local_settings.json file.

[sean-mcmanus]

@jhasse I think this is the issue.

[amarince]

I would add that the current behavior is not "natural" as if I add a wildcard entry like "*.c": "c" I would expect no other entry will be automatically added to the list that results in an "example.c": "cpp" entry (Which is the actual default). Is that assumption correct? I even tried "**/*.c": "c" with same effect.

[sean-mcmanus]

@AntonyMCs The issue you describe is a short coming of our extension's implementation, which doesn't check for pre-existing patterns when it adds new file associations. You can file an issue at https://github.com/Microsoft/vscode-cpptools/issues/ , but doing something more complicated is not currently high on our priority, although you might be able to view/modify our javascript yourself. Let me know if you have a repro for .c files incorrectly being associated with "cpp". "*.c": "c" is already the default we use (unless there's a bug).

[amarince]

@sean-mcmanus Actually there where c files added as c because I added both .c and .h without realizing that c files are already defaulted to "c". So, the wierd case, is because I assigne h files to "cpp", I like to have a different icon for c and h files, and regarding language there is no difference.

The result I get is:

"files.associations": {
                ...,
                "*.dependencies": "cmake",
                "**/*.h": "cpp",
                "mock.h": "c",
                "bio.h": "c",
                "comp.h": "c",
                "conf.h": "c",
                ...

So aside a possible "fix" on the way the extension behaves to prevent adding entries when there is a rule already covering them, Is there a way to set the icon for a given extension without the trick I'm trying?

[sean-mcmanus]

If the .h file is not actually a c file, that could cause problems with our language server (i.e. you could get IntelliSense errors and things like __cplusplus will be defined). I agree that .h files should have a different icon from .c/cpp files (like what VS 2017 does). I'll file a feature request on VS Code to somehow enable that. Using "**/*.h": "cpp" to get a different icon for .h files is not recommended; however, you can modify your out/src/LanguageServer/C_Cpp.js in the addFileAssociations function by adding after line if (!(file in assoc)) { lines if (file.endsWith(".h") && "**/*.h" in assoc) continue;
We might add more generic code like that in our next update.

[sean-mcmanus]

The Septemember 2018 release added setTextDocumentLanguage, so our extension can try using that instead of adding files to files.associations.

[sandy081]

/duplicate of #40233

Marking this as dup of #40233.

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!