Binding "A" key does not work

[mexicat]

Hi, I'm trying to bind all combinations of alt + vowels to their respective accented version (so alt+a becomes à, alt+e becomes è, etc). It seems like everything is working perfectly except alt+A, which just maps to... nothing.

Here is my config:

hs.hotkey.bind({"alt"}, "A", function()
  hs.eventtap.keyStrokes('à')
end)

hs.hotkey.bind({"alt"}, "E", function()
  hs.eventtap.keyStrokes('è')
end)

hs.hotkey.bind({"alt", "shift"}, "E", function()
  hs.eventtap.keyStrokes('é')
end)

hs.hotkey.bind({"alt"}, "I", function()
  hs.eventtap.keyStrokes('ì')
end)

hs.hotkey.bind({"alt"}, "O", function()
  hs.eventtap.keyStrokes('ò')
end)

hs.hotkey.bind({"alt"}, "U", function()
  hs.eventtap.keyStrokes('ù')
end)

I tried using the message parameter to check that the combination has been pressed and indeed it shows a dialogue.

I also enabled the debugging of key events via the code from another Github issue, and this is what it shows for one of the working hotkeys:

{
  CGEventData = {
    flags = 524576,
    keycode = 14,
    type = 10
  },
  NSEventData = {
    characters = "",
    charactersIgnoringModifiers = "e",
    keyCode = 14,
    modifierFlags = 524576,
    type = 10,
    windowNumber = 0
  }
}
{
  CGEventData = {
    flags = 536870912,
    keycode = 0,
    type = 10
  },
  NSEventData = {
    characters = "è",
    charactersIgnoringModifiers = "è",
    keyCode = 0,
    modifierFlags = 536870912,
    type = 10,
    windowNumber = 0
  }
}

While this is what it shows when trying alt+a:

{
  CGEventData = {
    flags = 524576,
    keycode = 0,
    type = 10
  },
  NSEventData = {
    characters = "å",
    charactersIgnoringModifiers = "a",
    keyCode = 0,
    modifierFlags = 524576,
    type = 10,
    windowNumber = 0
  }
}
{
  CGEventData = {
    flags = 536870912,
    keycode = 0,
    type = 10
  },
  NSEventData = {
    characters = "à",
    charactersIgnoringModifiers = "à",
    keyCode = 0,
    modifierFlags = 536870912,
    type = 10,
    windowNumber = 0
  }
}

So here it shows å which is the character I'd get regularly if I tried pressing alt+a on my international English layout, while in the previous example it doesn't show the default character for alt+e (which would be the euro symbol).

I've spent the last hour trying to understand what I was doing wrong and what might cause this, and the only reason I could come up with is the fact that the keycode for A is 0, and that might cause some issue with equality checks in Lua code... somewhere...? I don't know enough Lua to be sure about this though. Just please someone tell me I'm not crazy!

[asmagill]

I don't know why, but when I add a space before the "à" (e.g.

a = hs.hotkey.bind({"alt"}, "A", function()
  hs.eventtap.keyStrokes(' à')
end)

It will insert the "à" without a space... it's almost like it needs to "eat" the previous character, but I don't know why it only seems to affect the a version.

I don't see how this could be a problem specifically with Hammerspoon's implementation of hs.eventtap.keyStrokes, but I'll give it some thought and see if I can come up with a way to test and determine exactly what may be going on. In the mean time, see if adding the extra space works for you as well.

[mexicat]

With the space it works, thank you so much! This will do for now :)

Let me know if you find what's causing the problem, I'm genuinely curious as this seems to be a very strange bug...

[ibes]

I have the same problem and the same solution works for me.

Thanks for sharing!

[cmsj]

While there does seem to be a genuine bug here, I'd also like to note that Karabiner Elements has come a long way now, and can do a lot of great keyboard remapping, and if at all possible, is a much more appropriate tool for that, than Hammerspoon :)

[AustinWood]

@cmsj Could you please elaborate on why Karabiner is more appropriate? Among other things, of course, it seems like Hammerspoon is ideal for this (with the exception of this bug :)

[asmagill]

I can't speak to @cmsj's reasons, but my thoughts are that (1) Hammerspoon was not originally written to re-map the keyboard, it just happens to be able to, within certain limits, (2) Hammerspoon's event mechanism (not hs.hotkey, but hs.event) works at the level where events enter the user's login session, not at the hardware or hid layers (to do so requires a kernel extension and/or root/administrative access), and (3) this particular example runs smack into one of my biggest issues with hs.hotkey -- it utilizes the Carbon Event API which is all but deprecated (or at least its use is highly discouraged) in favor of the CoreGraphics event infrastructure -- while "replacing" the event with one created with the CoreGraphics Event API (hs.event).

The problem with switching hotkey to use the favored mechanism is that we run into latency issues that can cause key dropouts in all applications, not just Hammerspoon. I think I have some ideas on how to fix that, but it requires a fundamental rewrite of both hs.hotkey and hs.event and likely the creation of a dedicated thread or dispatch queue just for key events to insure that they are never delayed, no matter what else Hammerspoon might be doing at the time.

Again, just my thoughts, but I see Hammerspoon as a swiss-army knife which can do a lot of things well, but a targeted and dedicated tool will often be able to do a specific sub-set of what Hammerspoon can a little better.

[AustinWood]

Thanks for the great response, @asmagill ! Do you have any suggestions for tools that can do key re-mapping programmatically (not with a GUI, like Karabiner) at the hardware or hid layer?

[asmagill]

Unfortunately not, as it's not something I've found the need to do very often.