Ignore more temporary files by default

[GitMensch]

files.exclude allows users to define which things should be not in file explorer, should not be searched and not indexed.
They can still be opened using "file open".

Reasonably the default

vscode/src/vs/workbench/contrib/files/browser/files.contribution.ts

Lines 155 to 159 in 4c31caa

	'markdownDescription': nls.localize('exclude', "Configure [glob patterns](https://aka.ms/vscode-glob-patterns) for excluding files and folders. For example, the File Explorer decides which files and folders to show or hide based on this setting. Refer to the `#search.exclude#` setting to define search-specific excludes. Refer to the `#explorer.excludeGitIgnore#` setting for ignoring files based on your `.gitignore`."),
	'default': {
	...{ '**/.git': true, '**/.svn': true, '**/.hg': true, '**/CVS': true, '**/.DS_Store': true, '**/Thumbs.db': true },
	...(isWeb ? { '**/*.crswap': true /* filter out swap files used for local file access */ } : undefined)
	},

includes commonly used VCS' subfolders like .git, .svn, ...

The last commit there 1d9dc8b "web - filter out *.crswap via files.exclude" sneaked in the windows-only Thumbs.db (which I find a reasonable addition in any case), the previous fa0bc23 added CVS, with previous .hg and .svn additions.

I suggest to add more files there and while I initially had a bunch of files in my mind, including the list from the end, I've stepped down and suggest to at least add files ending with a~ because those are, over several systems and software, always temporary files #228981.

I'd like the community to:

• vote for general addition of more entries, staring with **/**~
• discuss which entries should be added, possibly including (this list is from a portable C build)

*.la
*.lo
*.o
*.so
*.obj
*.dll
*.lib
*.exe

*cache*
*-coverage
*.bak
*.gcda
*.gcno
*.diff
*.patch
*.tmp
cscope.*
TAGS

ipch
.vs
*.aps
*.ncb
*.*sdf
*.suo

.libs
.deps

Users can override that (which then means to also include the default values wanted) in their settings (so workspace/user/machine scope), so files that are "only very seldom should be used in the UI" can still be included (for example if someone wants his Thumbs.db or TAGS files shown), but we should still consider the likelyness (.deps seems to also be "something .NET/C#, not sure if this is like .vscode which you want to have included by default, for example).

Entries like *cache* are likely bad, thinking of for example package names including it. But who should have .bak or .tmp files shown and searched...

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vs-code-engineering]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[GitMensch]

@lramos15 Can you please explain why the previous changes in that area got in without a community vote, but this one doesn't?

[lramos15]

The two commits you mentioned are

• A VS Code core team member who added it to support our web initiative
• A commit from 7 years ago which added a single exclude from when VS Code was quite a bit younger and our take on defaults was a bit different

If you think about the millions of users that use VS Code, 20 upvotes is not a large bar to cross. We receive tons of feature requests daily and the community helps us appropriately prioritize them.

[GitMensch]

I see and for prioritizing, especially "harder" parts or things that change the core design like #41309 with hundreds of votes > 4 year I totally understand that procedure (and it is always said to see "votes needed for backlog" and then issues like the referenced with many much votes standing still).

... for this case there is an existing PR (so the work to be done is possibly documentation, but otherwise nothing than the PR handling itself).
So... I guess this and the PR will go down for not enough upvotes.

[lramos15]

... for this case there is an existing PR (so the work to be done is possibly documentation, but otherwise nothing than the PR handling itself).
So... I guess this and the PR will go down for not enough upvotes.

I understand why you feel that way but this is the first feature request that I can recall for this which means most users are not missing this as a default or are just configuring it themselves. Changing defaults always has a much broader impact than expected so we want to be sure of it when it is done and the community helps us decide that.

[vs-code-engineering]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!