Eli Zaretskii <
eliz@gnu.org> schrieb am Mi., 30. März 2016 um 04:39 Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 29 Mar 2016 20:07:55 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 19977@debbugs.gnu.org
>
> It seems that this behavior cannot be implemented without resorting to UCKeyTranslate. Therefore I'd
> suggest to fall back to the next best option and ignore all shift-like modifiers if control-like modifiers are
> present, similar to what we're doing with C-S on Unix terminals.
I'm not sure what this means, but if it means something that worked
before won't, please provide an option to get the old behavior back,
just in case.
I've attached a patch that should keep the aforementioned input methods working (by setting ns-command-modifier to none) and allow Command and Option to be treated as either shift-like or control-like modifiers.
In my tests input now works as expected with the Dvorak - Querty and similar input methods if ns-command-modifier is none. Also various key combinations with Super work now if it's set to super.
One thing that might be unexpected is that e.g. Command-Control-A will be interpreted as Control-A if ns-command-modifier is none, even if Command-A would insert something other than A. It seems this is (undesirable) behavior is actually already present at head.
0001-Fix-handling-of-modifier-keys-on-OS-X.patch