I've taken another approach. Making the XSetErrorHandler an opt-in for Linux implementation only.
We keep the common API consistent.
We do not introduce any undesired, hidden from the user behaviour on Linux.
We provide a proper way for the user to receive the actual XErrorEvent.

@changkun any feedback here? Do you have something against the new approach?

Thanks for contributing another workaround. The approach might solve the Linux problem, but introducing a platform-specific API is not the goal of simplicity.

The issue should be resolved with the absence of public APIs regarding explicit error handling. We either stick to the runtime panic that effectively warns the user or solve the problem entirely by knowing the registration error immediately at the Register call.

I do not have a chance to work on this before the end of next week, if this is needed urgently, you may switch back to a forked version that applies this patch.

According to the previous discussion, I'd like to close this for the clarification of rejecting any platform-specific workarounds. Any other actual solutions that match the previously described expectations remain kindly welcome and appreciated.

I see. Will be great if you manage to solve it properly. But I disagree that runtime panic is acceptable. IMO panic should happen only on startup and not based on user configuration that may change at runtime.

On another note regarding API consistency and simplicity. There currently are platform specific variables which will be better to be handled in a single wrapper in the hotkey package.
Alt key per platforms:

• darwin - https://github.com/golang-design/hotkey/blob/main/hotkey_darwin.go#L98
• linux - https://github.com/golang-design/hotkey/blob/main/hotkey_linux.go#L129
• windows - https://github.com/golang-design/hotkey/blob/main/hotkey_windows.go#L146

I've currently added per platform wrappers for these:
https://github.com/ventsislav-georgiev/prosper/tree/main/pkg/helpers/hotkeyh

The key variables are different. The actual unification is hotkey.Key and hotkey.Modifier. Using keycode directly is possible:

switch runtime.GOOS {
case "linux":
    mods = []hotkey.Modifier{0x1, 0x2, 0x3}
case "darwin":
    mods = []hotkey.Modifier{0x4, 0x5, 0x6}
case "windows":
    mods = []hotkey.Modifier{0x9, 0x8, 0x7}

without being bothered by those convenient name shortcuts.

Using hotkey.Modifier directly for unification makes the existence of the key variables redundant and is confusing to keep them for per platform usage as per your reasoning for closing this PR.

Using hotkey.Modifier directly for unification makes the existence of the key variables redundant and is confusing to keep them for per platform usage as per your reasoning for closing this PR.

If you find the package confusing then please leave it. Thanks.

I like the package, just giving my two cents about improving it. Didn't mean to offend you or the package in any way. I apologise I sounded like that.