search

sublimehq / sublime_text

Issue tracker for Sublime Text
https://www.sublimetext.com
807 stars 39 forks source link

File patterns in `ignored_packages` #3724

Open mitranim opened 3 years ago

mitranim commented 3 years ago

Problem description

Found myself disabling default packages and replacing them with stripped-down versions, because I strongly dislike some "optional enhancements" that come with them, such as Python plugins, snippets, autocompletions. Off the top of my head, I had to do this for HTML, CSS, Sass (3rd party).

It's currently possible to disable snippets using ignored_snippets, but this doesn't apply to plugins and other things, which can be bigger offenders.

Preferred solution

Would be nice if ignored_packages supported file patterns after plugin names. Any folders or files matched by a pattern would be ignored:

"HTML/*.py"
"HTML/Snippets"
"Text/Snippets"
"CSS/*.py"
// And so on

For safety, I would allow patterns only after the package name. Otherwise writing */* would disable everything including PlainText.

Benefits:

keith-hall commented 3 years ago

possible duplicate of https://github.com/sublimehq/sublime_text/issues/901

rchl commented 3 years ago

The plugins included with HTML and CSS that provide completions can also be disabled using disable_default_completions setting in syntax-specific settings.

See https://github.com/sublimehq/Packages/blob/7989f23ed0782a82e3593cae2c0f789e508050de/CSS/CSS.sublime-settings#L3

mitranim commented 3 years ago

Thanks, didn't know this. Might make use of it. I hope we can agree that the general solution would be preferable.

wbond commented 3 years ago

I hope we can agree that the general solution would be preferable.

I don't think allowing users to ignore individual files would be a good idea, since they will almost certainly be unaware of dependencies within a project.

I think the idea of disabling all plugins for a package sounds like a possibility, although it would probably leave a bit of a mess behind in terms of menus and command palette entries.

I think the correct answer is for packages to be configurable to turn off things the user doesn't want.

UltraInstinct05 commented 3 years ago

I think the correct answer is for packages to be configurable to turn off things the user doesn't want.

This is only possible at the plugin & settings level (I believe). There are other static sublime resource files that a user may want to "ignore" for whatever reasons like completions files, build system files, metadata files, syntax files, keymap files (& ignored_snippets implements only one of them).

wbond commented 3 years ago

This is only possible at the plugin & settings level. There are other static sublime resource files that a user may want to "ignore" for whatever reasons like completions files, build system files, metadata files, syntax files, keymap files (& ignored_snippets implements only one of them).

I don't think build systems need to be ignored - just don't use them. Or write a custom one and use it.

Metadata files and syntaxes are generally ignorable. If they try to override defaults and you don't want them, then don't install the package?

I think fairly logical things to add to make it easy to ignore would be:

Each of these push themselves into your workflow, and can't very easily be opted-out of.

The idea of each user know what files to ignore and how they are changing the configuration isn't very scalable in my opinion, hence why I am not keen on it.

UltraInstinct05 commented 3 years ago

I don't think build systems need to be ignored - just don't use them. Or write a custom one and use it.

Even if you write a custom one, the default build systems will still be shown in the build show quick panel (ctrl + shift + b) and I may want to see only my custom build systems and not have to navigate through the ones I don't use.

Metadata files and syntaxes are generally ignorable. If they try to override defaults and you don't want them, then don't install the package?

Agreed. This is fine.

The idea of each user know what files to ignore and how they are changing the configuration isn't very scalable in my opinion, hence why I am not keen on it.

Can you explain what do you mean by "scalable" in this context. I find it reasonable to let the users use only as much of the package as they want (by helping them "ignore" resource files, since there will always be a mixed audience when it comes to something like "I want completions from completion files", "I don't want them hindering my workflow because I use LSP")

wbond commented 3 years ago

Can you explain what do you mean by "scalable" in this context.

Scalable in the sense that only a small number of people will be able to handle this. It effectively means you need to have all of the knowledge of a package developer to properly use the feature. Which is great for the few hundred people who know all of the ins-and-outs of what files affect things. But they are also the people who could send PRs to fix the issue, or create overrides to ignore the files.

UltraInstinct05 commented 3 years ago

Scalable in the sense that only a small number of people will be able to handle this. It effectively means you need to have all of the knowledge of a package developer to properly use the feature.

I humbly disagree with this. The knowledge of package development spans more than just knowing what are resource files & making one. The feature request is to effectively have option(s) like ignored_keybindings: ["<Package>/*.sublime-keymap"] and the likes. A user doesn't even need to have deep understanding of using resource files to tell what this setting is doing. He/She only needs to have a basic understanding of keymap files and that having "<Package>/*.sublime-keymap" in ignored_keybindings is going to disable all keybindings files in <Package> (in the context of that setting).

I guess, in that sense why have ignored_snippets ? You can't always hand hold users. Plus using ST to a certain extent always requires you to have a basic idea of resource files (not saying plugin development)

wbond commented 3 years ago

The feature request is to effectively have option(s) like ignored_keybindings: ["/*.sublime-keymap"] and the likes.

No the feature request is to ignore arbitrary file patterns.

I am saying it would make more sense to have:

And not allow ignoring arbitrary file paths. If you ignore *.py and don't ignore *.sublime-menu files, you'll get these disabled commands in your menus.

At a higher level, the idea is: don't make every user try disabling various parts of a package, but ideally push packages to not be giant collections of 87 features that no one wants all of. Have a snippets package for someone who wants Vue snippets. Have a Vue linter. Have a Vue syntax.

Granted, some plugin authors and plugin users aren't going to agree. Giving users some failure resistant settings wouldn't be a terrible compromise for now.

UltraInstinct05 commented 3 years ago

No the feature request is to ignore arbitrary file patterns.

I am saying it would make more sense to have:

ignored_keybindings ignored_completions And not allow ignoring arbitrary file paths. If you ignore .py and don't ignore .sublime-menu files, you'll get these disabled > commands in your menus.

Yes, yes. I find it less favorable for arbitrary ignoring after your comment, but I was actually arguing about options like these that can also be useful. Hopefully that confusion is sorted :smile:

mitranim commented 3 years ago

I agree that whichever way we provide, needs to be accessible to most users. Requiring special knowledge, like extensions of various Sublime-specific files, is not accessible.

Part of the idea, which I forgot to include in the issue, was that optional enhancements would be grouped into subfolders like <plugin>/Snippets, maybe overarching <plugin>/Optional, making it easy for users to disable. We could make a convention where most packages would use the same subfolder name for their extras, and tell 3rd party plugins to follow it. Packages could document that folder in their readme. Just a thought.

Settings like ignored_snippets are more accessible because they only need the user to know about snippets, not .sublime-snippet or file paths. <package>/* is easy enough, and in this case only kills snippets. But in the general case, if we wanted to have such a setting for every resource type, that's a lot of settings.

I agree that in theory, having only small focused packages could make this unnecessary. Opt in rather than opt out seems like a nice approach. That said, even within a small package, there might be small things here and there that users would like to opt out of. 🤷‍♀️

If we're going with resource-specific settings, like disabling snippets in a package, I don't see a particularly strong reason why Sublime wouldn't have the option to disable the plugin(s) inside a given package. Such a setting would be able to disable .sublime-commands as well.

mitranim commented 3 years ago

An argument could be made that knowing to disable a plugin of a specific package is already special knowledge, compared to opening its settings and finding a boolean, which only requires an inkling of intuition. Even knowing the difference between a package and a plugin is special knowledge. Furthermore, for most plugins it's pretty easy to implement, as long as the author doesn't forget. The same isn't true for non-Python resources, which aren't easy for authors to disable.

giampaolo commented 3 months ago

@Ultra-Instinct-05 wrote:

Even if you write a custom one, the default build systems will still be shown in the build show quick panel (ctrl + shift + b) and I may want to see only my custom build systems and not have to navigate through the ones I don't use.

This is exactly my use case. I'd love to have the ability to hide "Make - Clean" and "Python - Syntax Check", which I never use:

image