2

An Autohotkey remapping script I'm using uses the function keys F13-F24 to keep track of layers. This means that {F13 Down}, for example, may get sent as a virtual key code.

This works fine for most applications. However, Emacs recognizes the function keys and does not pass them through (even though they don't exist on my keyboard and I can't activate them external to Autohotkey). This is causing unwanted behavior when I switch layers.

I can make the "key undefined" messages go away by using

(global-set-key [f13] 'ignore)
(global-set-key [f14] 'ignore)
...

However, Emacs still registers the keys, and they will stop sequences for commands. For example, in Spacemacs one switches windows using Spc 0-9. To access the numbers, I press a key that sends {F13 down}, then press a letter key. Rather than Spacemacs interpreting this as Spc #, a message prints saying that Spc <f13> is undefined. Even though they are nil, Emacs still "recognizes" them.

What I would like to do would be to have Emacs completely ignore the F13-F24 keys. That is, if Emacs receives a keycode corresponding to some key from F13-F24, it doesn't even register it, but ignores it as if it had not been pressed.

I tried using

(define-key input-decode-map (kbd "<f13>") nil)
(define-key input-decode-map (kbd "<f14>") nil)
...

in my config file, but the keys still register. According to my understanding of Translation Keymaps, I thought this would work. I'm at a bit of a loss now as to how I might go about disabling these keys.

Help?


Edit: I have solved the issue on the Autohotkey end of things. Instead of using F13-F24 for keeping track of layers, I'm using unassigned virtual key codes. (See this thread). It's a bit harder to maintain, but there is no interference with Emacs.

I've gone ahead and accepted @Gilles' answer since it mostly worked on the Emacs side of things. There were intermittent problems with auxiliary modes/maps getting activated that I was never able to pinpoint. I seemed to only have problems switching windows with Spc <f13> <letter> = Spc # when I was going from window to window with no keypresses in between. If I pressed Esc every time I arrived at a window before using Spc # to go to a different one, everything worked fine.

I'm pretty new to programming in general and Emacs in particular, so someone more knowledgeable might be able to actually create full pass through on the Emacs side of things. Here's some links that looked like they would be useful if I knew what I was doing:

  • In your global-set-key version, try setting them to nil. ignore is a function and will swallow the keybindings. – Dan Jan 18 '18 at 16:17
  • If I understood what you suggested correctly, this seems to cause Emacs to throw undefined key errors. Rather than ignoring the keys, it complains about them. – Steven Tammen Jan 18 '18 at 16:49
3

nil in input-decode-map (or any of the other translation maps) means “don't translate this key”, not “translate this key to an empty sequence”. Use an empty vector instead.

(define-key input-decode-map [f13] [])

This will effectively make Emacs ignore the key in most circumstances. For example, f13 won't interrupt a multi-key binding or a prefix argument. Some modes do read events at a lower level and will treat the key as undefined, for example f13 still interrupts incremental search or anything else that uses overriding-terminal-local-map. I don't know how Spacemacs will treat it.

I'm not sure whether that solves your actual problem, because I don't understand what you're trying to do from your question. If Emacs is doing something that prevents Autohotkey from seeing an event, this has to do with how the two programs process input events and cannot be solved through keymaps in Emacs.

  • This almost works. Sometimes I get a message "auxiliary keymap for motion state" which I'm assuming has a higher precedence than input-decode-map. I found a keymaps guide for Spacemacs, and am going to see if I can't figure out how to define the empty vector bindings in a map with higher precedence. – Steven Tammen Jan 18 '18 at 20:20
2

Emacs cannot be told to function as a sieve. If Emacs can see the key press, then Autohotkey is not remapping the keys at the system level. The original poster should consider submitting a feature request or bug report to Autohotkey and ask what workarounds are available. This is not something that Emacs can resolve, sorry.

  • This is not an upstream problem. I am asking how to make Emacs ignore certain key events in general. My situation happens to have these key events being generated from Autohotkey, but it would be just as valid a concern if they were coming from somewhere else. – Steven Tammen Jan 18 '18 at 20:01
  • 1
    It's a valid answer. For starters your "pass through emacs" wording is very confusing, and not what you're actually asking as far as I can tell; but moreover if your problem is "I'm sending key sequences to Emacs and I want Emacs to ignore them" then the most sensible solution would indeed seem to be "Stop sending the key sequences to Emacs" (and in fact it appears from your edit to the question that this is ultimately what you've done). – phils Jan 19 '18 at 0:24
  • 2
    I apologize if I came off as dismissive. That was not my intent. I think I also did a rather poor job at really explaining what I was trying to do ("I'm sending key sequences to Emacs and I want Emacs to ignore them" is exactly it... I don't know why I didn't think to phrase it more concisely like that). All I was trying to convey was that implementing "Emacs totally ignoring keys" seems like something that the Autohotkey devs would not be interested in: it would (hypothetically) be Emacs-related functionality not Autohotkey related functionality. Thanks for your help. – Steven Tammen Jan 19 '18 at 4:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.