On 2016.3.29, at 20:44, Philipp Stephani <p.stephani2@gmail.com> wrote:
>
>
> Adrian Robert <adrian.b.robert@gmail.com> schrieb am Di., 29. März 2016 um 19:19 Uhr:
>
> On 2016.3.29, at 19:57, Eli Zaretskii <eliz@gnu.org> wrote:
>
> >> From: Philipp Stephani <p.stephani2@gmail.com>
> >> Date: Tue, 29 Mar 2016 16:38:52 +0000
> >> Cc: 19977@debbugs.gnu.org
> >>
> >> If I comment out the if block below the comment
> >>
> >> /* if super (default), take input manager's word so things like
> >> dvorak / qwerty layout work */
> >>
> >> in nsterm.m, everything works. Unless somebody can explain why that if block exists at all (i.e. why
> >> [theEvent characters] instead of [theEvent charactersIgnoringModifiers] is used), then I'd suggest to
> >> remove the block completely.
> >>
> >> Attached a patch to remove this code.
> >
> > Adrian, any comments? It's your code from 7 years ago.
>
>
> Heh, well of the top of my head… ;-)
>
> Did you try testing Dvorak / Qwerty layout? If not, that’s under System Preferences, Keyboard, add new, English, select Dvorak or Dvorak / Qwerty.
>
> From what I remember, the issue had to do with cmd-key shortcuts when one of those layouts was in use. I think users were expecting the letter reported for the cmd shortcut to either agree with or disagree with the dvorak layout. Using [theEvent characters] caused it to use what they were expecting.
>
> It sounds like either this wasn’t the right solution, or user expectations vary. In either case I would agree with simplifying the code and removing the part you suggest.
>
>
> Yes, I can see what the problem is, thanks for the pointer. Basically in a couple of layouts (there are others, e.g. "Gujarati - QUERTY"), Command acts as shift-like character, like Option and Shift, selecting a different character, and not as a control-like character. For Option, Emacs allows switching between shift-like and control-like behavior using the `ns-alternate-modifier' option. The same should be implemented for Command.
> However, the code for `ns-alternate-modifier' is also somewhat broken. If it's set to 'none, C-M-<letter> doesn't work any more. This needs a bit more thought. What exactly is supposed to happen if both a shift-like and a control-like modifier are pressed at the same time? Emacs is inconsistent here: C-S-a remains C-S-a, but M-S-a gets translated to M-A.
I would say the correct behavior is to combine the modifier and the “shift”ed result. C-S-a should be C-A. But my memory is fuzzy as to whether nsterm should do this or it happens in emacs generic code. And if ns-alternate-modifier is ‘none’, then there is no such thing as C-M-letter, just C-letter, where the identify of ‘letter' is determined by what comes from opt-<original-key>.
I agree that this behavior is the desired/expected one. Unfortunately it seems the NSEvent API makes this somewhat hard to implement: you can either ignore all modifiers except shift (using charactersIgnoringModifiers) or none (using characters), but we'd need to ignore a certain subset of the modifiers.
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.