Hammerspoon: hotkey binding problem with key 'a'

Created on 22 Jan 2017  路  13Comments  路  Source: Hammerspoon/hammerspoon

I attempted to write an auto-replacement tool for latex in hamerspoon and encountered the following problem.

hs.hotkey.bind({"cmd", "alt", "ctrl"} , 'a',
function()
hs.eventtap.keyStrokes("\phi")
end
)

does not work for me. It types 'ph' instead of '\phi' I suspect that the problem lies with the 'a' key since, replacing with any other character such as 'y' works for me.

I am using the latest version of os x (10.12.2) and the latest version of Hammerspoon (0.9.52). I am new to writing on this forum, please let me know if I should supply more information. Thanks!

All 13 comments

Apologies, I found a related question does not solve the problem that I am encountering...
https://github.com/Hammerspoon/hammerspoon/issues/1144

With the extra space " \phi", it now prints '\p'. I feel like it is only printing the second and third character.

One thing to note is that"\" is an escape so "\\" would give "\"

But you're right using 'a' with command alt ctrl causes the problem regardless of the string supplied

yeah apologies, i placed two backslash //phi , but it showed up as /phi ...
Do the you know the cause of this problem? Is there any other keys that I should be on the lookout for?

No idea to be honest, I'll take a look at the source code to see if i can figure it out

Even using 0 does not change anything, 0 is the mapping to 'a'

The only thing I can think of is that there may be some sort of system wide shortcut or some other similar override that is causing a problem?

Try moving the function to the key-release position (e.g.:

~lua
hs.hotkey.bind({"cmd", "alt", "ctrl"} , 'a', nil,
function()
hs.eventtap.keyStrokes("\phi")
end
)
~

it works! any idea why it needs to be done in a certain way?

Thanks for the smart workaround! I will use it for the time being.

This is a guess, but I think it has to do with how an event propagates and at what point the receiving application gets it...

hs.hotkey accepts up to three functions - the first one when you first press the key down, the second one when you release it, and the third for if you hold the key down long enough for it to be considered repeating. While the key down function is invoked, you are still holding down the modifier keys for the hotkey. While hs.eventtap.keyStrokes does create a clean series of events representing the keystrokes without modifiers specified in the string, we have no way of determining when or if some other piece of code might do a check of the current modifiers, and if any are held down, "coalesce" them into the key event hs.eventtap.keyStrokes has created.

This seems to be worst with characters like a and o which when held down cause Apple's text handler to pop-up a menu (unless you disable this feature) of optional variants, but it can happen with any combination, depending upon what else might be running on your machine, system load, etc.

Generally if your hotkey is using hs.eventtap, we've found it most reliable to set the function as the key-up function.

I'm pretty sure there's no way around this without us getting into kernel space (which we won't be doing). I continue to recommend that hotkeys which emit keystrokes, always use the releasefn callback, or an hs.timer.doAfter().

(I'm going to close this out because I don't think there is any work to be done in Hammerspoon. Please re-open if you disagree!)

Thanks for all of your help! I learned a lot through this seemingly random phenomenal.

Was this page helpful?
0 / 5 - 0 ratings