Specify patterns to ignore resource files in packages

[FichteFoll]

Source

It may occur that you don't want the default snippets that ship with a package, and instead would like to replace them either with your own or those by a third party. Currently, you could

1. Override the files by creating a corresponding override file in the Packages folder, for each file.
2. Unpack the .sublime-package, remove all snippets, pack again and replace original (or in Installed Packages, if original is a shipped package)

Option 1 is infeasable, option 2 is suboptimal since we don't override correctly and messed with our updates.

Thus, I propose a general purpose approach as follows (using glob patterns):

"ignore_resources_patterns": [
    "Packages/Java/**/*.sublime-snippet",
    "!Packages/Java/Snippets/precious.tmSnippet",
    "Packages/**/*.tmSnippet"
]

This has the advantage of being able to ignore any file, not just snippets, without requiring to override with an empty file. This should apply to Python plugins as well.

Globs would support at least the patterns from glob(7) plus resursive (**) patterns that match every number of directories, including 0. {this,or that} could also be added, as they are commonly used in shells.

Patterns starting with an exclamation mark (!) would remove matching files from the "ignore" list.

[FichteFoll]

The more I think about this, the better it gets. Ignoring a package's key bindings would just be a matter of adding it to that list instead of overriding each binding the package inconveniently overrides in your User file again.

I'm not so sure about the "Packages" part in the pattern though. It seems redundant, since we're always handling package resources anyway, so I guess we could remove it. ignored_packages doesn't have it either. On the other hand, what if I only want to ignore resources of an "Installed Package" and add my own custom resources in an override package? By allowing Installed Packages/RandomSyntax/*.sublime-snippet this could be restricted to only installed packages, but wouldn't work on shipped packages.

[ghost]

I like this. Another user case would be to ignore color schemes (including the default bundled ones). Most themes insist in including the dev's favorite syntax color schemes, resulting in lots of duplicates.

[FichteFoll]

Adjusted the proposal to use somewhat standardized recursive globs (with **) instead of some custom interpretation.

[FichteFoll]

Added a concept of negative patterns, which are useful to reinclude a certain file, such as when you want to ignore all main menu additions from packages but must not exclude the default file.

"**/Main.sublime-menu",
"!Packages/Default/Main.sublime-menu"

[Enteleform]

+1

This will greatly improve maintenance of menus [ file, sidebar, context, etc ], command palette entries, snippets, etc.

Currently, the only option is to override every instance with a blank|commented file.  And that has the downfall of requiring perpetual maintenance.  EG: Once you've set up your ideal __entry_type__ configuration, you must track down any newly installed packages that add new, unwanted entries.

[ctf0]

@FichteFoll any news ?

[kylebebak]

It might be easier to just remove the snippets that ship with the default ST language packages.

The default language packages should not ship with snippets. Languages change, and the snippets get outdated. People don't write JS the way they did in 2012. Every last one of these JS snippets is useless!

I think whoever has write access to the default language packages ought to just remove snippets from all of them.

[FichteFoll]

The suggestion goes way beyond snippets as those were merely used as a good example. Not considering that this covers third-party packages as well, you may also use the suggested functionality to ignore a package's key bindings, for example.

For removing the default snippets entirely, discussion has moved to https://github.com/sublimehq/Packages/issues/1988.

[FichteFoll]

4050 ships with a ignored_snippets setting that allows specifying glob patterns to ignore snippets. Snippets where the main use case I outlined in the OP, but other use cases may include menu or completions files, which is why I'll leave this issue open but reduced severity.