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: 3849 bytes --]

Philipp Stephani <p.stephani2@gmail.com> schrieb am Di., 29. März 2016 um
21:43 Uhr:

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

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.

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