Open aplum opened 3 years ago
That change isn't relevant to this issue. Do you have an editor open? Adding atom-workspace
means that holding CMD even when an editor is not open will trigger this shortcut. #87 only changed the shortcut to CMD, so it is consistent with other operating systems.
Looking at the Flight Manual about specificity ("when multiple bindings match for a single element, the conflict is resolved by choosing the most specific selector") and my testing, I still think it is relevant. (And the problematic shortcut is alt-enter
, not cmd
. cmd
seems to work fine, but I never really use that one so I can't say for sure.)
To simplify the following tests, I removed the keybinding from my ~/.atom/keymap.cson
and made the changes in ~/.atom/packages/intentions/keymaps/intentions.json
(restarting Atom after each change).
The following selectors all had the same result shown in this screenshot:
atom-workspace atom-text-editor:not([mini])
.platform-darwin atom-text-editor:not([mini])
body atom-text-editor:not([mini])
However, something like the following does not trigger. You can see that both selectors (body
and atom-text-editor:not([mini])
) matched, but neither is as specific as the core keybinding.
body, atom-text-editor:not([mini])
alt-enter
(previously ctrl-enter
) from .platform-darwin atom-text-editor:not([mini])
to atom-text-editor:not([mini])
, which is less specific than the core keybinding's atom-workspace atom-text-editor:not([mini])
.So I think your comment
Adding
atom-workspace
means that holding CMD even when an editor is not open will trigger this shortcut.
would only be true if there were a comma to create multiple selectors, i.e. atom-workspace, atom-text-editor:not([mini])
.
The change in #87 made the keybinding's specificity for
intentions:show
lower than a core keybinding, so it's no longer triggered.Screenshot:
I've fixed this on my machine by adding
atom-workspace
to the selector (I'm not sure if there's a more appropriate fix though).Screenshot with fix: