[Bug]: undefined keys

[kapmix]

Bug summary

安装了最新的neomacs-0.0.17-aarch64-apple-darwin.dmg

发现两个按键有问题：

输入M-< 显示为M-¯ 输入M-> 显示为M-˘ 然后报错:

M-¯ is undefined 
M-˘ is undefined

并且查询函数 beginning-of-buffer

Steps to reproduce

1. 输入 M-<，
2. 输入M->，

Expected behavior

M-< runs the command beginning-of-buffer
M-> runs the command end-of-buffer

Neomacs --version output

Neomacs 0.0.17
Git commit: e0f4e9bb1e047314849fa84f9eeb33427e7d2e5d
Source date: 2026-09-06T12:03:34.000000000-04:00
Build: release for aarch64-apple-darwin with rustc 1.96.1
Standalone Rust binary for Neomacs (no C dependency)

Extra context

No response

[eval-exec]

Thank you for the report, investigating... 🤔

[eval-exec]

@kapmix

neomacs.txt

It's invalid link:

[kapmix]

能下载啊。

[kapmix]

附件是 RUST_LOG=debug ./neomacs -Q 的日志
neomacs-log.txt.gz

上个日志忘记压缩了，请重新查看。

[eval-exec]

Fixed on main in ebf363d + 51d0d11 (#361). Thanks for the RUST_LOG=debug log — it pinned the bug exactly.

What was wrong. macOS composes an Option chord in the window server, so AppKit hands the application the composed character. Your log shows it precisely:

ModifiersChanged: shift=true ctrl=false alt=true super=false
KeyboardInput: logical_key=Character("¯") physical_key=Code(Comma) mods=5
msg = M-¯ is undefined

The physical key is Comma — macOS had already turned Option+Shift+, into ¯ before Neomacs saw it, and Neomacs was reading that composed character.

GNU Emacs never does. keyDown: takes its code from [theEvent charactersIgnoringModifiers] (src/nsterm.m), which applies Shift but not Option. Under the default ns-alternate-modifier of meta, that is the value Emacs binds against. Neomacs now asks the window for the same thing at creation time.

Also fixed: every other Option+Shift chord — M->, M-{, M-}, M-|, M-:, M-?, M-", M-~, M-_, M-(, M-).

And a second bug you have not hit yet: Option+E/I/N/U/` are dead keys on the US layout, so macOS turned them into marked text and Neomacs received no key event at all. M-e (forward-sentence), M-i (tab-to-tab-stop) and M-u (upcase-word) were silently dead, and each also swallowed the next keystroke. Those should work now too.

One deliberate tradeoff: Option no longer types composed characters (Option+E then A now gives a, not á). This is exactly GNU's default behaviour with ns-alternate-modifier set to meta. GNU lets you set that variable to nil to get composition back; Neomacs does not implement ns-alternate-modifier yet, so there is currently no way to opt out. Please open a separate issue if you need Option-composed input.

Please verify when you can. I do not have a Mac, so this fix is verified by CI compilation and by reading the winit and GNU Emacs sources. It has not been tested on real hardware. If you can try a build from main (or v0.0.18 when it ships) and confirm M-<, M-> and M-u, that would help. If anything still misbehaves, reopen and I will look again.