bug#19977: 24.4; Incorrect translation of Super modifier with Ctrl or Meta on OS X

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]

Adrian Robert <adrian.b.robert@gmail.com> schrieb am Di., 29. März 2016 um
19:56 Uhr:

>
> 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.

[-- Attachment #2: Type: text/html, Size: 4255 bytes --]