I want to use the command key on my Mac as the meta key, so I customize ns-command-modifier. But I also want to still use ⌘-` to cycle through all the windows in Emacs - just like in all other Mac apps.

If I unbind ⌘-`, then I just get an error that there is no binding for that key. I want to somehow tell Emacs not to trap that key at all.

There must be a solution because ⌘-TAB works whether or not the ⌘ key is set to be meta. But ⌘-` does not.

1 Answer
1

What's going on here is that ⌘-⇥ is a low-level hotkey that can't be intercepted (a good thing, too, since it may be one of your only escape hatches if a full-screen game hangs, along with the force-quit ⌥-⌘-⎋ keystroke which is also immutable and uninterceptible).

⌘-`, on the other hand, is a command that macOS provides ordinary apps by default, but that can be reassigned or ignored completely. The way the Cocoa Emacs integration work is largely (though not entirely) by disabling Cocoa's free features (because they don't interact well with a lot of Emacs concepts) and then reintroducing the ones that made sense to the developers.

In some Mac-specific Emacs distributions, this includes window-cycling via ⌘-`, but not in the stock version.

The good news is that, having already set up your modifier keys as you like, you can now just bind a key in the normal Emacs way to the frame-cycling (Mac "windows" are Emacs "frames" while Emacs "windows" don't correspond to anything on the Mac exactly) command other-frame, ordinarily bound to C-x 5 o.

So try M-xglobal-set-keyRET⌘-`other-frameRET. If that works, you can set up this keybind permanently in your init file(s), or whatever method you use (I don't presume to know since there are many takes on managing keybinds in Emacs, but if you don't know how, I can edit this to suggest one, just drop a comment).

(Incidentally, I may have presumed when I took your use of "windows" to mean Mac windows/Emacs frames. If I did, and you want ⌘-` to really cycle the active point through Emacs windows, including within the same frame, then instead of other-frame, you want next-multiframe-window, which cycles between windows regardless of frame. Note its cycling behavior is... unusual, and perhaps a bit unintuitive, though it's the only consistent way for it to work.)