Add the ability to disable a package’s snippets.

[savetheclocktower]

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.

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.

[savetheclocktower]

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

[Ben3eeE]

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?

[daviwil]

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?

[savetheclocktower]