Add the ability to disable a package’s snippets. #277
Merged
Conversation
Includes on-the-fly disabling and enabling without the need to reload the window. The UI to expose this will come later; see atom/settings-view#1076.
This looks great. I will take a closer look later this week. |
This change looks great to me! Thanks so much for the thorough comments too, that's really helpful. Do you think this is ready to be merged? |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Closes #242. Fixes #55.
Description of the Change
I wanted to pick up where #242 left off; @layonferreira did some great work, but had to put the PR aside for lack of time.
I cribbed from that PR a bit and also looked at the existing code for keymaps. The exact UI is being worked out in atom/settings-view#1076, but if everyone’s agreed that this functionality should essentially behave like per-package keymap disabling, then the logic we need within the snippets package is pretty straightforward.
There’s a new
Map
in there so we can associate a package's name with the snippet file(s) and snippets that it loads, and a newScopedPropertyStore
to act as a sort of quarantine zone for any snippets that get disabled. That store will get ignored by most methods but is consulted in thegetUnparsedSnippets
method so that the settings view is made aware of all snippets, not just the ones that happen to be active right now. Imagine seeing a list of ten snippets in a package’s Settings view, unchecking the “Enable” box above that list, and seeing those ten snippets disappear… because you just deactivated them. The secondScopedPropertyStore
is how we avoid that pitfall.We spy on the
core.packagesWithDisabledSnippets
setting so that we can do targeted adding or removing of certain snippets when the setting changes. It will not be necessary to reload the window. The change handler will add or remove the smallest number of snippets possible to account for the settings change; bundled snippets and user-defined snippets won’t get touched, nor will snippets from unrelated packages.Alternate Designs
The proposed design was selected almost entirely upon the feedback given in #242. If, within this design, there are better ways to accomplish any of the things that this PR adds, please let me know.
Benefits
Issue #55 has been open since 2014. It’s a quality-of-life issue when you accidentally trigger a snippet you didn’t realize existed, or have snippets suggested to you that aren’t helpful and that you’ll never use. It might also make package authors feel more entitled to include snippets in their packages without worrying if it’s too opinionated of a choice to push out to their users.
Possible Drawbacks
Aside from bugs, I can’t really think of any. This change shouldn’t regress performance for anyone who doesn’t care about this feature. (And it could theoretically improve the startup time of this package in an extreme case where a user has disabled most or all of the snippets provided by packages. But I haven’t tested this.)
Applicable Issues
Original issue is #55; PR #242 was a previous attempt to close it.