Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to disable a package’s snippets. #277

merged 6 commits into from Oct 17, 2018


Copy link

@savetheclocktower savetheclocktower commented Oct 3, 2018

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 new ScopedPropertyStore 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 the getUnparsedSnippets 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 second ScopedPropertyStore 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.


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.

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.
@savetheclocktower savetheclocktower requested a review from Ben3eeE Oct 3, 2018
Copy link
Collaborator Author

@savetheclocktower savetheclocktower commented Oct 3, 2018

@Ben3eeE, I suggested you as a reviewer because you reviewed #242, but don’t feel any obligation.

Copy link

@Ben3eeE Ben3eeE commented Oct 9, 2018

This looks great. I will take a closer look later this week.
I'd like if we merged this together with the settings-view PR that adds the ui. Can you ping me on that PR once it's opened?

Copy link

@daviwil daviwil left a comment

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?

Copy link
Collaborator Author

@savetheclocktower savetheclocktower commented Oct 17, 2018


@Ben3eeE Ben3eeE merged commit 72b3d3d into atom:master Oct 17, 2018
2 checks passed
2 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants