Show names/count of hidden files

[fregante]

Show 14 hidden items: .github, .babelignore, .babelrc.js, .editorconfig, .eslintignore, .eslintrc, ...

or

Hidden: .github, .babelignore, .babelrc.js, .editorconfig, .eslintignore, .eslintrc, and 8 more

Or even better, make each item clickable:

Hidden: and 8 more would still open the entire list on click.

[radiovisual]

I like this more as an option than a default but I can see how some users might like this. 👍

I have since changed my mind. See comment below.

[sindresorhus]

Not something I would use. Just creates a lot of noise with files I don't usually care about.

Why do you want this? Is it really too much with two clicks for such files?

[radiovisual]

Yeah, the more I think about it, the less I like the idea, because we essentially aren't hiding anything if we just show the files grouped together inline at the top of the files table. This extension is meant to hide these files, but if we list the files on the top row, then nothing is hidden (the filenames are just moved to a new location, and then there would be TWO different places to see the filenames listed, so instead of hiding the files, there are now two different ways to see the filenames crowd the repo).

[fregante]

I assume the point of this extension is to bring relevant files to our attention by hiding others. If you don't really care about those files, why don't we completely hide them instead of dimming/toggling them?

Showing them on a single line still keeps important files higher but also makes it easier to see what's being hidden.

Files .gitignore and .gitattributes are actually useless, but .babelrc and .eslintrc are configuration files no different from package.json.

Also I access .travis.yml regularly, even though I don't consider it an important file.

[fregante]

Also: it's not strictly to save one click but also to just see what's being hidden exactly.

there would be TWO different places to see the filenames listed

Yes, but no, once you expand the list the items in line will disappear — if you need to expand it at all, thanks to this change.

[radiovisual]

If you don't really care about those files, why don't we completely hide them instead of dimming/toggling them?

I care about the files we are hiding, it's just like you said, some of the files are still important. They just have been deemed "less important" or needed "less frequently" so they can be tucked out of the way, but still easily accessible with the toggle.

Along the same lines, because some of these "less frequently accessed" files are still important, like configuration files, then I still want to see the git activity on the file, or see when it was last updated, and you won't have that in your top-row inline view, so you would still have to toggle the files visible in order to see the repo activity on that file. So I think the files are still important, they can just be safely tucked out of the way for when we rarely need to access them.

If configuration files (or any other files) are really important to you and frequently accessed, then you can just tell the extension to not hide those at all and you have the best of all worlds.

This proposed use case is not really about hiding the files (which is the purpose of the extension), you are wanting to move file access to a new, consolidated location.

[radiovisual]

Though, there have been times when I thought it would be nice to at least see how many files have been hidden:

[fregante]

This proposed use case is not really about hiding the files (which is the purpose of the extension), you are wanting to move file access to a new, consolidated location.

Come on, that's just discussing semantics. 😄 Even now we're not 100% hiding them, we're just moving them inside an accordion that still takes 980x30px of screen estate!

I'm asking to keep a visible reference to what's being compressed into one line/button.

[radiovisual]

Come on, that's just discussing semantics. 😄

Haha. Yeah, it might feel that way a little. But what you are proposing is to not hide the files, but to move them (which feels like a counter to this extension) so semantics, as subtle distinctions are important here. 😆

But what you are also asking, is that we add in code (that would need to be maintained) to do some things that GitHub already gives us for free, or this extension is already doing, or is nearly solved by this extension in a slightly different way:

1. You want us to make the links in your inline accordion clickable: GitHub already does that for us.
2. You want to create a concatenated list of files, where only the first few hidden files are listed in your accordion view, but this extension will already reveal ALL the hidden files with a single click, (your proposal will still hide some of the files: what if I think one of the files that didn't make it to the accordion list are important? What I wanted to click on the 6th file but only 5 files were listed in your concatenated list? it would still be hidden no matter what, and I would still have to toggle to see the file)
3. You are proposing that some of the files will NEVER be hidden, at all, regardless of the state of the "toggle" button, some "hidden" files will always be visible.

I think that the option we wrote in to ignore the hiding of certain files is actually really good for your use case, because you essentially want to still be able to access certain files, but with this particular proposal, you won't have any control over which files make it to the inline accordion list (for example, what if one of your configuration files were the 6th file but you only have 5 files listed in the accordion, you would be even more frustrated that this feature doesn't give you any control).

So as a fair compromise, I think it would be nice to give users a tiny bit more control over the files that are hidden (or what they consider "non essential"), like what if, for example, you could supply a dimOnly RegExp of files to always dim (not hide). That way the files that are important to you are never hidden, but still "out of the way". This would require a lot less code to maintain, but gives users more control. I know Sindre hates options, haha, but this could be a fair compromise for added flexibility.

[fregante]

Again, this is just irrelevant semantics. It all comes down to what the extension developer wants.

1. GitHub's links are clickable, but also take screen space.
2. If there are 100 hidden files, tough luck. Some files is better than no files. 980px can include 10+ filenames and that's more than enough for most repos.
3. Semantics. This is not an npm module but a utility tool, it doesn't have to strictly adhere to its name. Heck even wget can make post requests 😜

Everything else, back to point 1: .travis.yml would still be visible but it wouldn't take screen space.

[sindresorhus]

If you don't really care about those files, why don't we completely hide them instead of dimming/toggling them?

They're useless for me 99% of the time, but should still be accessible for that 1%.

Also I access .travis.yml regularly, even though I don't consider it an important file.

Unrelated, but I'm curious why you access it regularly?

[fregante]

To make PRs towards it 😁

Plus it useful to see what node versions are supported and any additional build steps.

Also sometimes you might not necessarily need to open the files, but it's good to see if a project has Travis, babel or eslint set up without clicking anywhere (even in projects that don't have a Travis badge, like your awesome lists)