Global Hotkeys on Sequoia: hs.hotkey.bind({'alt'}, 'a' ... still working?

[muescha]

I've set up some Umlauts using {alt} + a for "ä" and {alt, shift} + a for "Ä" (see the configuration here: Umlauts.lua).

I recently read an article about global hotkeys using the Alt key no longer being available in Sequoia (article in German: ifun.de, or English: Shottr).

Does this limitation also apply to Hammerspoon? Are there any workarounds using Karabiner?

I'm hesitant to update to Sequoia because of this issue...

[kjczarne]

I have a similar issue that I noticed this morning. I had alt + 1, alt + 2, ... using hs.application.launchOrFocus. It works if you use cmd + alt but not with alt itself. Also works with cmd + 1, cmd + 2, ....

[muescha]

oh - I don't want to change it to alt+ additional modifier. I miss then a lot of shortcuts with only alt - modifier :(

[muescha]

As I read in this reddit this change is only for sandboxed apps in the MAS?

https://www.reddit.com/r/macapps/comments/1fjpiiw/psa_macos_15_breaks_optionkey_hotkeys/

[mfrister]

As I read in this reddit this change is only for sandboxed apps in the MAS?

https://www.reddit.com/r/macapps/comments/1fjpiiw/psa_macos_15_breaks_optionkey_hotkeys/

Reading a bit further down, this seems to be related to a specific API for registering global hotkeys, RegisterEventHotkey .

Unfortunately, Hammerspoon uses this API.

Question now is: Does it make sense to change Hammerspoon to use a different API that might need accessibility permissions? On the one hand, as a user, I would love to be able to continue using my Option-Shift shortcuts (which are generally not used by apps, so very useful for global shortcuts). On the other hand, it's unclear if Apple will restrict further APIs in the future, so this might be a temporary improvement and not worth the effort.

[kjczarne]

Same as @muescha I would prefer to be able to use the Option modifier key the way it used to work before. But you are absolutely right, there is no guarantee Apple won't restrict alternative APIs as well. I suppose it depends on how time-consuming would switching to a different API be.

[muescha]

On the one hand, as a user, I would love to be able to continue using my Option-Shift shortcuts

to clarify: Option-Shift-{key} are not effected. only Option-{key}

[muescha]

it would be nice if some user having Sequoia installed run this script and can tell if it is working under Sequoia:

hs.hotkey.bind({'alt'}, 'z', function () hs.alert.show("key pressed", 1) end)

[mfrister]

to clarify: Option-Shift-{key} are not effected. only Option-{key}

What makes you think Option-Shift is not affected? The sources you mentioned in the original issue both say it is and the forum post by an Apple employee mentions it explicitly.

You’re right, though, it would be nice if someone could test this on Sequoia.

[muescha]

You are right. Sorry.

yes Opt+Key and Opt+Shift+Key are blocked.

[piechologist]

I use macOS' native Text System Defaults and Key Bindings to insert strings into text fields. For me, it works in any application with text input, even in the Signal Electron app. Will be fine for umlauts but won't help if you want to execute a command. Just create a text file ~/Library/KeyBindings/DefaultKeyBinding.dict. Mine looks like:

/* -*- coding: utf-8 -*- */
{
  // Ctrl-Cmd-Down/Left/Right: suppress the bonk alert sound in Zed and other apps.
  "@^\UF701" = noop:;
  "@^\UF702" = noop:;
  "@^\UF703" = noop:;

  "~Q" = (insertText:, "≡");
  "~A" = (insertText:, "≢");
  "~I" = (insertText:, "∈");
  "~N" = (insertText:, "∉");
  "~R" = (insertText:, "return ");
  "~F" = (insertText:, "function ");
  "~X" = (insertText:, "×");
  "~C" = (insertText:, "∘");
  "~<" = (insertText:, " .|> ");
  "~>" = (insertText:, " |> ");
  "$~ " = (insertText:, "\U2009"); // thin space
}

For instance, Shift-Opt-Q inserts the "equivalent" unicode character.

Some useful links:

• https://github.com/ttscoff/KeyBindings/blob/master/DefaultKeyBinding.dict
• https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/TextDefaultsBindings/TextDefaultsBindings.html
• https://developer.apple.com/documentation/appkit/nsstandardkeybindingresponding
• http://xahlee.info/kbd/osx_keybinding.html

[mikejsavage]

I'm on Sequoia, my opt/alt hotkeys work everywhere but password fields

[iliyang]

I came here after thinking I was going crazy — sometimes my Alt+key bindings will work (on macOS 15.1), other times not. Indeed, all my other bindings seem unaffected. This is a huge blow for me as I've been relying on Alt+key bindings for many years, primarily to switch between apps (like on Windows you can use Win+number). Is there any hope to fix that? Is there any hack I can do on my side? Any response is appreciated!

[snipem]

Same for me, sometimes my alt+key bindings work, sometimes not. alt+shift+key bindings do not work either. They only produce some unicode characters like they would normally do.

[mfrister]

I've since upgraded to Sequoia and I'm using Karabiner Elements now to map my Caps Lock key to command+control+option+shift for application shortcuts and map the latter using Hammerspoon. It's tedious to learn new shortcuts, but I felt having to press one less key was worth it, now that I have the option with Karabiner.

I'm quite sure it's possible to use a similar workaround to keep using option+shift shortcuts, but it doesn't work to generally map option+shift to command+control+option+shift and binding the latter in Hammerspoon. The problem is that there are lots of other shortcuts using option+shift, most annoyingly per-word selection (e.g. option+shift+left). Mapping individual keys in Karabiner would probably work, so it should be possible to generate JSON for Karabiner to map all normal letters (and whatever else doesn't have conflicts) with option+shift to command+control+option+shift, allowing you to keep the shortcuts mapped via Hammerspoon.