Skip to content

Can we store files.associations elsewhere? #722

Closed
@bbalp

Description

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

Activity

sean-mcmanus

sean-mcmanus commented on May 12, 2017

@sean-mcmanus
Contributor

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

bbalp commented on May 12, 2017

@bbalp
Author

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

rkeithhill commented on Dec 19, 2017

@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

sean-mcmanus commented on Dec 19, 2017

@sean-mcmanus
Contributor

@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

rkeithhill commented on Dec 19, 2017

@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

sean-mcmanus commented on Dec 19, 2017

@sean-mcmanus
Contributor

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

BillyONeal commented on Dec 20, 2017

@BillyONeal
Member

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

sean-mcmanus commented on Dec 20, 2017

@sean-mcmanus
Contributor

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

added this to the January 2018 milestone on Dec 22, 2017
added
fixedCheck the Milestone for the release in which the fix is or will be available.
and removed on Dec 22, 2017

3 remaining items

BillyONeal

BillyONeal commented on Jan 9, 2018

@BillyONeal
Member

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

sean-mcmanus

sean-mcmanus commented on Jan 9, 2018

@sean-mcmanus
Contributor

@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

BillyONeal commented on Jan 9, 2018

@BillyONeal
Member

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

capture

sean-mcmanus

sean-mcmanus commented on Jan 9, 2018

@sean-mcmanus
Contributor

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

BillyONeal commented on Jan 9, 2018

@BillyONeal
Member

Today, I learned :). Thanks!

sean-mcmanus

sean-mcmanus commented on Jan 9, 2018

@sean-mcmanus
Contributor

@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

BillyONeal commented on Jan 9, 2018

@BillyONeal
Member

Looking good so far :thumbup2:

sean-mcmanus

sean-mcmanus commented on Jan 17, 2018

@sean-mcmanus
Contributor

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

herrberk commented on Apr 5, 2019

@herrberk

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

{
    "C_Cpp.autoAddFileAssociations": false
}
removed their assignment
on Apr 22, 2019
akbyrd

akbyrd commented on Aug 12, 2019

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

locked and limited conversation to collaborators on Oct 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Language ServicefixedCheck the Milestone for the release in which the fix is or will be available.quick fix

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @akbyrd@BillyONeal@herrberk@rkeithhill@bobbrow

        Issue actions

          Can we store files.associations elsewhere? · Issue #722 · microsoft/vscode-cpptools