Philipp Stephani schrieb am Di., 29. März 2016 um 21:43 Uhr: > Adrian Robert schrieb am Di., 29. März 2016 > um 19:56 Uhr: > >> >> On 2016.3.29, at 20:44, Philipp Stephani wrote: >> >> > >> > >> > Adrian Robert schrieb am Di., 29. März >> 2016 um 19:19 Uhr: >> > >> > On 2016.3.29, at 19:57, Eli Zaretskii wrote: >> > >> > >> From: Philipp Stephani >> > >> 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- 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-. >> >> >> >> >> > 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.