Feature request: allow multiple key bindings for a single function in `hs.spoons.bindHotkeysToSpec` about hammerspoon

[asmagill]

This may sound antagonistic, and that's not my intention, but you do know that you can create your own hotkeys wrt Spoons -- you don't need to use the bindHotkeyToSpec function (and I usually don't; I find it more confusing, personally).

// the global variable `spoon` contains key's corresponding to any already loaded Spoon, so
// assuming the FadeLogo spoon has already been loaded:
hs.hotkey.bind({"cmd", "shift"}, "l", function() spoon.FadeLogo:start(.5) end)

// or if you prefer the fnutils.partial approach:
// hs.hotkey.bind({"cmd", "shift"}, "l", hs.fnutils.partial(spoon.FadeLogo.start, spoon.FadeLogo, .5))

[ambirdsall]

This may sound antagonistic, and that's not my intention, but you do know that you can create your own hotkeys wrt Spoons -- you don't need to use the bindHotkeyToSpec function (and I usually don't; I find it more confusing, personally).

I also prefer directly using hs.hotkey.bind too when I can—and I appreciate the disclaimer, conveying tone in text is hard 🙂. The trouble is that not every spoon exports its bindable actions in a way that's suitable to bind a la carte. My motivating example was the PaperWM spoon, which does not define direction-specific actions outside of its bindHotkeys method. In my personal case, I was able to work around the lack by directly using the lower-level API and hardcoding the equivalent integer values of the non-exported Direction enum; but that's a hacky and brittle approach, and it clearly depends on the happy accident that the spoon's OOP implementation happened to expose that lower-level internal method in the first place.

If this issue gets no traction, I intend to open a PR to make that particular spoon's API a bit more flexible, but it seems to me that the root of the issue is with bindHotkeysToSpec: it is the documentation-blessed Right Way to expose keybindings to users, after all, and there's no assurance that users of a spoon that straightforwardly follows that recommended API (as PaperWM.spoon appears to do) will be able to reference individual actions for a la carte bindings.

[ambirdsall]

Again, this was not a hard blocker for me, but it does seem suboptimal that I had to open a pull request on an individual spoon to work around the fact that spoons' documented keybinding mechanism lacks support for a pretty basic keybinding use case; and that, of course, only resolves the issue for users of that specific spoon. (I realize that also may sound antagonistic—that is not my intention, either 🙂)