Ignore system filters and splitting globs

[dimateos]

Describe the Problem

Hello! thanks for the great extension!

I want to use this extension more but I always kind of ignore it because the list of filters gets too cluttered.
What do I mean? Basically the same as #44 but let me explain it:

You have the GLOBAL setting "files.exclude" (default by vscode or custom), for example:

"files.exclude": {
    "**/{.DS_Store,Thumbs.db}": true,
    "**/{.hg,.svn}": true,
    "**/.git": true,
    "**/{__pycache__,.pytest_cache}": true,
},

Now if you use any of the extension features, the LOCAL "files.exclude" will be populated with ALL those GLOBAL values + whatever you need for filtering. As you can see here, even marked as "System":

Welp, now I have a long list of filters I will UNLIKELY touch ever (that is why I put them in the GLOBAL settings)... on top of the one I MAY toggle on/off! Plus all the array ends up in the LOCAL settings.json

My second request is also related to reducing noise. I only had 4 elements in my exclude list, but here the extension tries to be "too-smart" and splits my hand-made blob groups (not all tho bug?). I had my reasons to group those and I will never toggle them individially, so I much prefer to reduce the list elements and get some vertical space back!

Describe the Solution

My feature requests are simple. Note that IMO, these suggestions should be the default behavior, but I guess I would introduce settings so users can still pick the previous one if they see the need etc:

1. SETTING: completely ignore the "System" GLOBAL file.exclude setting, just as it never existed: render only the content of the LOCAL file.exclude and simply modify that without adding values from the GLOBAL settings.

IMPORTANT note here: IDK before or if ever, but since many versions LOCAL files.exclude does NOT replace the GLOBAL setting, both settings are MERGED! So the only thing the user would lose is the ability to see/toggle the GLOBAL ones using the visual panel. But IMO I would prefer a simpler more usable list and edit those manually in the GLOBAL settings JSON.

FEATURE: Maybe the cog button could search for "files.exclude" instead of "explorerExclude." as a shortcut to edit those settings. IMO "explorerExclude." settings seem more like set and forget kind-off so I dont see the need for a shortcut whereas an alternative quick way to edit "files.exclude" seems neat.

2. SETTING: completely ignore glob groups and simply treat them as a SINGLE regular path. These glob groups are a tool we have for grouping related stuff so why the split? is it how the vscode API returns them?

EXAMPLE: I would even manually edit the LOCAL files.exclude and group some paths to help reduce the list size and make it even more usable.

BUG: It does not work very well as of now too (see the pycache glob example).

Alternatives

No response

Additional Context

As final context, I have been using this extension for years but basically only as a neat way of visualizing what is currently ignored in the explorer. So never really interactuated with it :(

But I see it as a great extension with even greated potential!

Would love to be able to toggle glob groups of related LOCAL folders,
This would be super useful e.g. limit the workspace search in very user-friendly way (inherits files.exlude).

Thanks, regards!

[guilhermedsz]

If you want to fix this, based nm the lack of engagement, there is no chance the original maintainer is coming here to help - just clone the repo / grab the extension from its installed location by clicking the blue link on the filesize of the installed extension in VSCode and then editing away!

Heres your problem 😆

I am sure once you are in there, you'll see how easy it is to edit it to make it what you want.

[manifestinteractive]

Hi @dimateos, just to clarify a bit:

This extension doesn’t create or control the list of excluded files and folders — it simply visualizes what’s already defined in your VS Code files.exclude settings. That list is managed entirely by VS Code itself.

The defaultExclude value shown in @guilhermedsz’s screenshot only comes into play if you click the reset icon in the extension, which restores files.exclude to VS Code’s default state. Again, that default comes from VS Code, not this extension.

It seems there may be some confusion about the scope of what this extension can do. It does not perform any actual hiding of files or folders. Only VS Code does that, using its own files.exclude setting.

What this extension does provide is a simple UI to:

• View your current files.exclude entries
• Toggle visibility of items without needing to manually edit your settings JSON
• Add new items more easily

That’s the full extent of its functionality — it’s a management tool for an existing VS Code feature, not a replacement for or enhancement of VS Code’s native rendering behavior.

I hope that clears things up. Feature requests that fall outside this scope are unlikely to be implemented, not because they aren't valid ideas, but because they'd require building a completely different extension with different goals. That’s not something I plan to do with this one.

[manifestinteractive]

@guilhermedsz Appreciate you jumping in here, but I want to offer a quick clarification for others reading this thread.

While it's totally valid to fork or modify an extension for personal use, suggesting that's the only path forward isn’t quite accurate — especially when the original issue may stem from a misunderstanding of what the extension actually does.

Also, just a friendly reminder: it's best to avoid assuming a maintainer’s level of engagement or intent based on a snapshot in time. Many open source maintainers contribute in cycles or in the spare time they have available. Making assumptions like this can discourage participation and isn’t always reflective of reality.

If you have constructive ideas or want to propose a change, contributions and thoughtful suggestions are always welcome — that’s what helps projects grow!

Thanks again for being part of the conversation.

[guilhermedsz]

@manifestinteractive thanks for the comprehensive response for @dimateos , appreciate your work on this extension over the years!

With that said, I would hope you were not so quick to assume that people didn't understand or were 'confused" about what it does or doesn't do. Above you have indicated (and a similar sentiment on #44 in response to people not wanting to have the great list you provided with defaults that, as you've elegantly noted multiple times, no one has any control over

What everyone was asking for, perhaps not in the best way, but they just dont want to have all the system defaults cluttering everything in the list of ones that they have added themselves.

Here is what they are after (following a few tweaks of my own) - surely you'd agree its better to have those seperately categorised, and allow people to focus on the defaults they have actively opted into (and the ones they care about)

Really, its just removing the visual noise of the defaults from the list.

VS all of this noise:

Surly we all agree the first shorter list better focuses on the ones someone has actively added themselves?