This was bootstrapped with running `decaffeinate` on both command-registry
and its spec, but involved a line-by-line eyeing and updating for idioms
and, in one case, correctness:
For some reason, copying the keys to the new dispatchedEvent in
coffeescript (command-registry.coffee:235) currently does not result in a thrown
exception, as it should when trying to write over the read-only property
`isTrusted`, so I added a check to ensure that the key did not already
exist in the new event. Moreover, other definitions of `preventDefault`,
`stopPropagation` and friends, which are also enumerable afaict, would
also overwrite the ones defined just prior (command-registry.coffee:220
and command-registry.js:325), so that check ensures we don't overwrite
those either.
Test plan: `./script/lint && ./script/test`, and a lengthy smoke test of
various commands through keybindings, command palette, and package
interfaces.
Released under CC0.
Etch's reconciliation routine causes elements to be sometimes
re-ordered. In order to move an element, however, Etch needs to first
detach it from the DOM and then re-append it at the right location.
This behavior is unacceptable for highlight decorations because it could
re-start CSS animations on a certain highlight decoration when a
completely different one is added or removed.
Even though we are still interested in restructuring etch's
reconciliation logic to prevent unwanted re-orderings, with this commit
we are switching to a custom routine to create/update/remove highlight
decorations that prevents unnecessary moves and, as a result, fixes the
undesired behavior described above.
On Linux, when the user performs a middle-button mouse click, Chromium
fires both a mouse-down event *and* a paste event. This commit teaches
the TextEditorComponent to ignore the paste event.
When the user performs a middle-mouse click on a tab, we get close the
tab and attempt to prevent Chromium's default processing for the event.
[1] This prevents Chromium's default processing for the *mouse down*
event, but then Chromium also fires a *paste* event, and that event
pastes the clipboard's current content into the newly-focused text
editor. 🙀
Since Atom already has its own logic for handling pasting, we
shouldn't (🤞) need to handle browser paste events. By ignoring the
browser paste events on Linux, we fixatom/tabs#461.
[1]
ce1d92e0ab/lib/tab-bar-view.coffee (L416-L418)
