sfccdevops
Allow removal of default entries in "Hidden items" view
Describe the Problem
The "Hidden items" view beneath the tree always shows entries for **/.git, **/.svn, **/.hg, /.DS_store & **/Thumbs.db. I'm only using git on Windows, so I never need svn, hg & ds_store to be excluded. Since I only have 2 entries in the list which I have created myself and which I toggle regularly, those default entries make the list unnecessarily cluttered which makes it a tiny bit more cumbersome to toggle the things I want.
Describe the Solution
When right clicking on my manually added entries, there's a "Remove from hidden items" context menu option.
-> Provide this for the default/system entries as well.
Alternatives
No response
Additional Context
No response
It is showing this because that is the default settings for VS Code. This extension does not create those records, it simply shows you what those settings are. All new projects within CS Code will start with these default settings as they are what VS Code creates.
For clarity, VS Code uses a files.exclude setting in the native VS Code settings.json file that is built into their app. This extension does not create any settings, other than what you manually add yourself on top of the default settings, which are the ones you reported.
So, this is a VS Code settings thing and there is nothing this extension can do about that :)
Even if you could edit or remove them, they would just get added back in by VS Code. I hope that makes sense.
Ok, I assumed so at first but could not find anything related to e.g. svn in my settings.json which is why I then thought that is somehow hard coded by the extension. Technically, I'm rather sure that you could build some setting into the app, which prevents showing of those entries in the view provided by the extension but I understand if you don't want to implement a feature like this b/c I'm probably the only one asking for it 😉.
Sadly, it's not an issue of wanting to. This extension is bound to the VS Code settings, meaning whatever is shown in this extension is what VS Code has in settings.json and visa-versa. Since these default settings are added by VS Code, they will always appear in this extension.
Since VS Code will always use what is in settings.json under files.exclude setting, this extension MUST directly edit this setting, as any other attempt to hide or exclude files outside are not natively supported by VS Code.
Sure, I understand all that, but the extension does render the items in the list itself (doesn't it?), so it could ignore/filter certain entries based on some extension setting like explorerExclude.hideFromHiddenList: ['**/.svn', ...] w/o touching VSCodes files.exclude.
This explorerExclude.hideFromHiddenList could then be automatically populated when using the Remove from hidden items context menu on those system entries.
Purely hypothetically speaking.
Sure we could choose to hide some stuff that is in VS Code, but that is not something I think we should do, as the extension would not be showing the actual settings, which would just add confusion.
You soon start to run into some major issues, such as, how do you "unhide" something that you chose to hide from being shown in a hidden list... is that a separate panel if you did that by mistake? Do you have to manually edit the settings.json file to get it back? See how it starts to get weird?
Having a separate list to maintain is not ideal. The best/cleanest solution is to just show the user what their actual exclude settings are for the file explorer and let them toggle visibility using that list, without trying to work around the native items that VS Code is 100% going to also be filtering, whether the user sees them in your list or not.
This is mostly what I meant with my initial "... I understand if you don't want to implement a feature like this b/c I'm probably the only one asking for it ...".
In my further comments I just wanted to point out, that this is not a matter of technical feasibility but a matter of "product vision" where introducing such a feature would cause too much (conceptual) trouble and ultimately worsens the extensions UX for most people (more & harder to understand settings etc.) whilst it only serves very few users (me 😉).
Regarding your 2nd paragraph:
Yep, I thought of that as well & I'd just let user "restore" settings by manually editing settings.json but than again: This is just my biased opinion as someone who wants that feature 😉.
Sorry for being so pedantic & thank you for the friendly discourse!
Sure thing! Discussing ideas is always worthwhile.
My initial concern was that most users would have a worse experience with this feature, however, after talking with you, I think there might be a compromise that could work for pro users.
What if we added your idea to create an exclusion list but make that something you have to manually edit. Meaning it's more for hardcore users that KNOW they need to manage this manually ( or in the settings page for the plugin ) but no other UI support would be added.
Basically, list always shows what's in the project settings. If you want to not show an item in the hidden items list, you'll have to go into the settings and add it to an exclusion list manually, and if you need to undo it later, you'll have to do it manually.
Even with that though, it still gets weird as the location of those settings change for different projects, and not everyone knows the difference between Folder, Workspace and User settings, and when each is applied.
This extension kind of auto handles that for the user, but if you start manually tweaking them, it starts to get tricky as you need to edit the correct ones.
That's why it'd be kind of a "pro feature"
Just honestly not sure how many folks would want that. But let's do this, I'll open the feature request back up, and let's see if others ask for it. I think that's fair.
Sounds perfect to me! Thanks for reconsidering!
... Even with that though, it still gets weird as the location of those settings change for different projects, and not everyone knows the difference between Folder, Workspace and User settings, and when each is applied. ...
For me, I'd have this exclusion list set up in my global VSCode config as it would be the same for every project I'm working on.