Now that jQuery has been patched to add inline listeners and inline
listeners are reported from findCommands, there’s no reason to include
commands based on $.fn.events. Also, we need to ensure the same command
doesn’t get added to the list twice since it could get added by both
inline and selector-based listeners.
This extends the command registry to support listeners registered on
individual elements in addition to selectors. The analogy is inline
styles vs selector-based styles. I’m hoping this will be the foundation
of integrating cleanly with legacy commands registered via our
jQuery::command extension.
Especially in specs, trigger has been used to invoke events. jQuery does
not invoke native listeners in this situation, so we use ::on to listen
for them instead. If we didn’t handle the event with a native capture
handler, we’ll still support invoking via trigger.
Commands registered with the command registry will always be handled
first, so as long as we disable any listeners in the registry that were
already invoked for the current command, we don’t need to disable jQuery
methods before replaying the command after activating the package.
This commit adds the ability to call .disableInvokedListeners on the
event passed to the command listeners. This returns a function which
can be called to reenable them.
Previously, stopping propagation would work on the synthetic bubbling
phase of the command registry itself, but the original event would
continue to propagate which is counterintuitive.
* Activation events can be handled via atom.commands
* Pre-existing listeners registered via atom.commands are disabled when
replaying events for the activated package.
This commit adds the ability to get and restore snapshots of command
listeners. Whatever commands are installed before specs begin are
preserved, but commands added during specs are always cleared away.
