Allowing root view to be focused was stealing focus away from the
editor whenever a click event made it to the root view. This unnecessary
switching of focus was interfering with the ability to drag tabs.
But if RootView can't be focused, focus ends up being returned to the
document body when there are no focusable elements. This would be fine,
except for the fact that we frequently bind global events on root view,
and so they aren't triggered when events are triggered on the body. We
could just bind all global events on the body, but this would require
us to always attach elements to the DOM during specs, which is a serious
performance killer in specs.
The workaround is in the keymap. When the keymap handles a key event
that was triggered on the body, it triggers the corresponding semantic
event on the root view anyway, so from the event perspective, it's as
if the root view actually had focus. The only place this might fall
down is if someone wants to capture raw key events. But that's the
keymap's job anyway, and we maybe add a hook on the keymap if such a
need ever arises.
This was cool, but it's really hard to optimize the keymap with this feature because we never know if a keystroke will match against a binding set with a function, which will force us to always consider this binding set against every key event.
Certain events call `abortKeyBinding` to opt out of handling certain keybindings. Snippets does this with tab for example. If it's not a situation where it's appropriate to go to the next tab stop, we let the next binding be triggered, which could insert a tab, for example. But when we trigger events from the event palette, there *is* no next binding. Having a no-op function helps in this situation.
For example, if you have a very unspecific binding "ctrl-x ctrl-c", you can also have very specific "ctrl-x …" bindings, and bindings from both sets can be matched. A partial match in a more specific does not rule out later matches in a less specific set.
