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

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

[Philipp Stephani]

After pressing M-s-a, I get the message:
M-s-å is undefined
Expected: M-s-a (being defined or undefined)

Tested running Emacs as a Carbon app on OS X:
open -W -n -a /Applications/Emacs.app --args -Q

After pressing C-s-a, I get the message:
<C-s-268632065> is undefined
Expected: C-s-a (being defined or undefined)

Seems to happen for all keys, not just a.  For C-s-<letter>, the
character produced is 0x1002ffa0 + <letter> instead of <letter>; for
M-s-<letter> the character produced is whatever OS X maps to
Option+<letter>.  This happens only if Super is pressed as well.  More
discussion at
http://lists.gnu.org/archive/html/help-gnu-emacs/2015-02/msg00503.html.




In GNU Emacs 24.4.1 (x86_64-apple-darwin14.1.0, NS apple-appkit-1344.72)
 of 2015-02-23 on p
Windowing system distributor `Apple', version 10.3.1344
Configured using:
 `configure --prefix=/usr/local/Cellar/emacs/24.4
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs/24.4/share/info/emacs
 --with-file-notification=gfile --with-dbus --with-gnutls --with-rsvg
 --with-imagemagick --without-popmail --with-ns
 --disable-ns-self-contained'

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-h k M-s-å C-h k <C-s-268632065> M-x r e p o r t - 
e m a <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
M-s-å is undefined
<C-s-268632065> is undefined

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify cocoa ns multi-tty emacs)

Memory information:
((conses 16 72131 5145)
 (symbols 48 17549 0)
 (miscs 40 36 136)
 (strings 32 9875 3982)
 (string-bytes 1 263546)
 (vectors 16 9027)
 (vector-slots 8 377107 15432)
 (floats 8 55 300)
 (intervals 56 189 0)
 (buffers 960 11))

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

[Philipp Stephani]

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

Philipp Stephani <p.stephani2@gmail.com> schrieb am So., 1. März 2015 um
17:41 Uhr:

>
> After pressing M-s-a, I get the message:
> M-s-å is undefined
> Expected: M-s-a (being defined or undefined)
>
> Tested running Emacs as a Carbon app on OS X:
> open -W -n -a /Applications/Emacs.app --args -Q
>
> After pressing C-s-a, I get the message:
> <C-s-268632065> is undefined
> Expected: C-s-a (being defined or undefined)
>
> Seems to happen for all keys, not just a.  For C-s-<letter>, the
> character produced is 0x1002ffa0 + <letter> instead of <letter>; for
> M-s-<letter> the character produced is whatever OS X maps to
> Option+<letter>.  This happens only if Super is pressed as well.  More
> discussion at
> http://lists.gnu.org/archive/html/help-gnu-emacs/2015-02/msg00503.html.
>
>
Unfortunately this is still happening with 25.0.92.1.

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

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 29 Mar 2016 10:17:42 +0000
> 
>  After pressing M-s-a, I get the message:
>  M-s-å is undefined
>  Expected: M-s-a (being defined or undefined)
> 
>  Tested running Emacs as a Carbon app on OS X:
>  open -W -n -a /Applications/Emacs.app --args -Q
> 
>  After pressing C-s-a, I get the message:
>  <C-s-268632065> is undefined
>  Expected: C-s-a (being defined or undefined)
> 
>  Seems to happen for all keys, not just a. For C-s-<letter>, the
>  character produced is 0x1002ffa0 + <letter> instead of <letter>; for
>  M-s-<letter> the character produced is whatever OS X maps to
>  Option+<letter>. This happens only if Super is pressed as well. More
>  discussion at
>  http://lists.gnu.org/archive/html/help-gnu-emacs/2015-02/msg00503.html.
> 
> Unfortunately this is still happening with 25.0.92.1. 

What is the evidence that this is an Emacs problem?

What do you get if you type s-a?

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

[Philipp Stephani]

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

Eli Zaretskii <eliz@gnu.org> schrieb am Di., 29. März 2016 um 17:11 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Tue, 29 Mar 2016 10:17:42 +0000
> >
> >  After pressing M-s-a, I get the message:
> >  M-s-å is undefined
> >  Expected: M-s-a (being defined or undefined)
> >
> >  Tested running Emacs as a Carbon app on OS X:
> >  open -W -n -a /Applications/Emacs.app --args -Q
> >
> >  After pressing C-s-a, I get the message:
> >  <C-s-268632065> is undefined
> >  Expected: C-s-a (being defined or undefined)
> >
> >  Seems to happen for all keys, not just a. For C-s-<letter>, the
> >  character produced is 0x1002ffa0 + <letter> instead of <letter>; for
> >  M-s-<letter> the character produced is whatever OS X maps to
> >  Option+<letter>. This happens only if Super is pressed as well. More
> >  discussion at
> >  http://lists.gnu.org/archive/html/help-gnu-emacs/2015-02/msg00503.html.
> >
> > Unfortunately this is still happening with 25.0.92.1.
>
> What is the evidence that this is an Emacs problem?
>

Because in other apps I can use these key combinations. E.g. C-s-f in
Chrome toggles fullscreen mode. But in Emacs, such keybindings don't work.
E.g. after evaluating (global-set-key (kbd "C-s-f") (lambda ()
(interactive) (message "It works"))) hitting C-s-f will lead to the error
message "<C-s-268632070> is undefined", and M-x lossage will contain "
<C-s-268632070> [nil]".


>
> What do you get if you type s-a?
>

This works as expected (i.e. I get whatever is bound to s-a, and s-a
appears in lossage). It's only the combination of C-s and M-s that gets
translated incorrectly.

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

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

[Philipp Stephani]

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

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

>
>> What do you get if you type s-a?
>>
>
> This works as expected (i.e. I get whatever is bound to s-a, and s-a
> appears in lossage). It's only the combination of C-s and M-s that gets
> translated incorrectly.
>

Some more debugging output, using NS_KEYLOG = 1. The input sequence is a,
C-a, M-a, s-a, C-S-a, M-S-a, s-S-a, C-s-a, M-s-a. As you can see, 'code' is
correct (A or a), except for the last two cases.

keyDown: code =61 fnKey =0 flags = 100 mods = 0
keyDown: Begin compose sequence.
2016-03-29 17:37:57.711 Emacs[59410:2534138] insertText 'a' len = 1
keyDown: code =61 fnKey =0 flags = 40101 mods = 4000000
keyDown: code =61 fnKey =0 flags = 80120 mods = 8000000
keyDown: code =61 fnKey =0 flags = 100108 mods = 800000
keyDown: code =41 fnKey =0 flags = 60103 mods = 6000000
keyDown: code =41 fnKey =0 flags = a0122 mods = a000000
keyDown: code =41 fnKey =0 flags = 12010a mods = 2800000
keyDown: code =1 fnKey =0 flags = 140109 mods = 4800000
keyDown: code =e5 fnKey =0 flags = 180128 mods = 8800000

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

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

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 29 Mar 2016 15:45:13 +0000
> Cc: 19977@debbugs.gnu.org
> 
> Some more debugging output, using NS_KEYLOG = 1. The input sequence is a, C-a, M-a, s-a, C-S-a, M-S-a,
> s-S-a, C-s-a, M-s-a. As you can see, 'code' is correct (A or a), except for the last two cases.

I guess someone who understand how keyboard input works on OS X will
have to look into this.

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

[Philipp Stephani]

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

Eli Zaretskii <eliz@gnu.org> schrieb am Di., 29. März 2016 um 18:00 Uhr:

> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Tue, 29 Mar 2016 15:45:13 +0000
> > Cc: 19977@debbugs.gnu.org
> >
> > Some more debugging output, using NS_KEYLOG = 1. The input sequence is
> a, C-a, M-a, s-a, C-S-a, M-S-a,
> > s-S-a, C-s-a, M-s-a. As you can see, 'code' is correct (A or a), except
> for the last two cases.
>
> I guess someone who understand how keyboard input works on OS X will
> have to look into this.
>

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.

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

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

[Philipp Stephani]

[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]

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

> Eli Zaretskii <eliz@gnu.org> schrieb am Di., 29. März 2016 um 18:00 Uhr:
>
>> > From: Philipp Stephani <p.stephani2@gmail.com>
>> > Date: Tue, 29 Mar 2016 15:45:13 +0000
>> > Cc: 19977@debbugs.gnu.org
>> >
>> > Some more debugging output, using NS_KEYLOG = 1. The input sequence is
>> a, C-a, M-a, s-a, C-S-a, M-S-a,
>> > s-S-a, C-s-a, M-s-a. As you can see, 'code' is correct (A or a), except
>> for the last two cases.
>>
>> I guess someone who understand how keyboard input works on OS X will
>> have to look into this.
>>
>
> 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.

[-- Attachment #1.2: Type: text/html, Size: 1860 bytes --]

[-- Attachment #2: 0001-Fix-bug-19977.patch --]
[-- Type: application/octet-stream, Size: 2480 bytes --]

From a43dc5205c47aa9a4dd4378240ef2ecd49a3904a Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Tue, 29 Mar 2016 18:37:40 +0200
Subject: [PATCH] Fix bug#19977

* nsterm.m (keyDown:): Remove special-casing of Command key to fix
bug#19977.
---
 src/nsterm.m | 37 ++-----------------------------------
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4048ac4..dd51e99 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -5873,41 +5873,8 @@ not_in_argv (NSString *arg)
            : ns_right_command_modifier);
 
       if (is_left_key)
-        {
-          emacs_event->modifiers |= parse_solitary_modifier
-            (ns_command_modifier);
-
-          /* if super (default), take input manager's word so things like
-             dvorak / qwerty layout work */
-          if (EQ (ns_command_modifier, Qsuper)
-              && !fnKeysym
-              && [[theEvent characters] length] != 0)
-            {
-              /* XXX: the code we get will be unshifted, so if we have
-                 a shift modifier, must convert ourselves */
-              if (!(flags & NSShiftKeyMask))
-                code = [[theEvent characters] characterAtIndex: 0];
-#if 0
-              /* this is ugly and also requires linking w/Carbon framework
-                 (for LMGetKbdType) so for now leave this rare (?) case
-                 undealt with.. in future look into CGEvent methods */
-              else
-                {
-                  long smv = GetScriptManagerVariable (smKeyScript);
-                  Handle uchrHandle = GetResource
-                    ('uchr', GetScriptVariable (smv, smScriptKeys));
-                  UInt32 dummy = 0;
-                  UCKeyTranslate ((UCKeyboardLayout*)*uchrHandle,
-                                 [[theEvent characters] characterAtIndex: 0],
-                                 kUCKeyActionDisplay,
-                                 (flags & ~NSCommandKeyMask) >> 8,
-                                 LMGetKbdType (), kUCKeyTranslateNoDeadKeysMask,
-                                 &dummy, 1, &dummy, &code);
-                  code &= 0xFF;
-                }
-#endif
-            }
-        }
+        emacs_event->modifiers |= parse_solitary_modifier
+          (ns_command_modifier);
 
       is_right_key = (flags & NSRightControlKeyMask) == NSRightControlKeyMask;
       is_left_key = (flags & NSLeftControlKeyMask) == NSLeftControlKeyMask
-- 
2.7.4

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

[Eli Zaretskii]

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

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

[Adrian Robert]

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.


-Adrian

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

[Philipp Stephani]

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

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.

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

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

[Adrian Robert]

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

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

[Philipp Stephani]

[-- 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 --]

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

[Philipp Stephani]

[-- 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 --]

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

[Eli Zaretskii]

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

Thanks.

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

[Philipp Stephani]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 1899 bytes --]

[-- Attachment #2: 0001-Fix-handling-of-modifier-keys-on-OS-X.patch --]
[-- Type: application/octet-stream, Size: 13651 bytes --]

From 008e71c08cbc06ac2d3ee3b353fe363ba620f4fd Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Wed, 30 Mar 2016 19:22:56 +0200
Subject: [PATCH] Fix handling of modifier keys on OS X
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/nsterm.m (is_shift_modifier, has_shift_modifiers): New helper
functions.
(keyDown:): Distinguish between shift-like and control-like modifier
keys.  Allow treating ⌘ as shift-like modifier (e.g. for the
Gujarati – QUERTY input method, where ⌘ switches to QUERTY.)

* lisp/cus-start.el (standard): Change nil to none for
ns-command-modifier; update description.
---
 lisp/cus-start.el |   8 ++-
 src/nsterm.m      | 208 ++++++++++++++++++++++++------------------------------
 2 files changed, 98 insertions(+), 118 deletions(-)

diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 5be61ce..12269c1 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -389,6 +389,10 @@ minibuffer-prompt-properties--setter
 	     ;; msdos.c
 	     (dos-unsupported-char-glyph display integer)
 	     ;; nsterm.m
+             ;;
+             ;; FIXME: Why does ⌃ use nil instead of none?  Also the
+             ;; description is confusing; setting it to nil disables ⌃
+             ;; entirely.
 	     (ns-control-modifier
 	      ns
 	      (choice (const :tag "No modifier" nil)
@@ -405,13 +409,13 @@ minibuffer-prompt-properties--setter
 		      (const super)) "24.1")
 	     (ns-command-modifier
 	      ns
-	      (choice (const :tag "No modifier" nil)
+	      (choice (const :tag "No modifier (work as layout switch)" none)
 		      (const control) (const meta)
 		      (const alt) (const hyper)
 		      (const super)) "23.1")
 	     (ns-right-command-modifier
 	      ns
-	      (choice (const :tag "No modifier (work as command)" none)
+	      (choice (const :tag "No modifier (work as layout switch)" none)
 		      (const :tag "Use the value of ns-command-modifier"
 			     left)
 		      (const control) (const meta)
diff --git a/src/nsterm.m b/src/nsterm.m
index 4048ac4..ebccb27 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -37,6 +37,7 @@ GNUstep port and post-20 update by Adrian Robert (arobert@cogsci.ucsd.edu)
 #include <time.h>
 #include <signal.h>
 #include <unistd.h>
+#include <stdbool.h>
 
 #include <c-ctype.h>
 #include <c-strcase.h>
@@ -5670,6 +5671,43 @@ not_in_argv (NSString *arg)
 @end  /* EmacsApp */
 
 
+static bool
+is_shift_modifier (NSEventModifierFlags flags,
+                   NSEventModifierFlags generic_mask,
+                   NSEventModifierFlags left_mask,
+                   NSEventModifierFlags right_mask,
+                   Lisp_Object left_option,
+                   Lisp_Object right_option)
+{
+  bool is_right_key = (flags & right_mask) == right_mask;
+  bool is_left_key = (flags & left_mask) == left_mask
+    || (! is_right_key && (flags & generic_mask) == generic_mask);
+
+  unsigned int modifiers = 0;
+  if (is_right_key)
+    modifiers |= parse_solitary_modifier (EQ (right_option, Qleft)
+                                          ? left_option : right_option);
+  if (is_left_key)
+    modifiers |= parse_solitary_modifier (left_option);
+
+  /* parse_solitary_modifier returns 0 for a shift-like modifier.  */
+  return (is_left_key || is_right_key) && modifiers == 0;
+}
+
+static bool
+has_shift_modifiers (NSEventModifierFlags flags)
+{
+  /* Check only Command, Option, and Shift modifiers.  Control is
+     never a shift-like modifier key.  */
+  return is_shift_modifier (flags, NSCommandKeyMask,
+                            NSLeftCommandKeyMask, NSRightCommandKeyMask,
+                            ns_command_modifier, ns_right_command_modifier)
+    || is_shift_modifier (flags, NSAlternateKeyMask,
+                          NSLeftAlternateKeyMask, NSRightAlternateKeyMask,
+                          ns_alternate_modifier, ns_right_alternate_modifier)
+    || (flags & NSShiftKeyMask) == NSShiftKeyMask;
+}
+
 
 /* ==========================================================================
 
@@ -5812,10 +5850,8 @@ not_in_argv (NSString *arg)
 
   if (!processingCompose)
     {
-      /* When using screen sharing, no left or right information is sent,
-         so use Left key in those cases.  */
-      int is_left_key, is_right_key;
-
+      /* FIXME: What should happen for key sequences with more than
+         one character?  */
       code = ([[theEvent charactersIgnoringModifiers] length] == 0) ?
         0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0];
 
@@ -5862,131 +5898,50 @@ not_in_argv (NSString *arg)
       if (flags & NSShiftKeyMask)
         emacs_event->modifiers |= shift_modifier;
 
-      is_right_key = (flags & NSRightCommandKeyMask) == NSRightCommandKeyMask;
-      is_left_key = (flags & NSLeftCommandKeyMask) == NSLeftCommandKeyMask
-        || (! is_right_key && (flags & NSCommandKeyMask) == NSCommandKeyMask);
+      /* The ⌘ and ⌥ modifiers can be either shift-like (for alternate
+         character input) or control-like (as command prefix).  If we
+         have only shift-like modifiers, then we should use the
+         translated characters (returned by the characters method); if
+         we have only control-like modifiers, then we should use the
+         untranslated characters (returned by the
+         charactersIgnoringModifiers method).  An annoyance happens if
+         we have both shift-like and control-like modifiers because
+         the NSEvent API doesn’t let us ignore only some modifiers.
+         Therefore we ignore all shift-like modifiers in that
+         case.  */
+
+      /* EV_MODIFIERS2 uses parse_solitary_modifier on all known
+         modifier keys, which returns 0 for shift-like modifiers.
+         Therefore its return value is the set of control-like
+         modifiers.  */
+      unsigned int control_modifiers = EV_MODIFIERS2 (flags);
+      bool shift_modifiers =
+        control_modifiers ? false : has_shift_modifiers (flags);
+
+      emacs_event->modifiers |= control_modifiers;
 
-      if (is_right_key)
-        emacs_event->modifiers |= parse_solitary_modifier
-          (EQ (ns_right_command_modifier, Qleft)
-           ? ns_command_modifier
-           : ns_right_command_modifier);
-
-      if (is_left_key)
-        {
-          emacs_event->modifiers |= parse_solitary_modifier
-            (ns_command_modifier);
-
-          /* if super (default), take input manager's word so things like
-             dvorak / qwerty layout work */
-          if (EQ (ns_command_modifier, Qsuper)
-              && !fnKeysym
-              && [[theEvent characters] length] != 0)
-            {
-              /* XXX: the code we get will be unshifted, so if we have
-                 a shift modifier, must convert ourselves */
-              if (!(flags & NSShiftKeyMask))
-                code = [[theEvent characters] characterAtIndex: 0];
-#if 0
-              /* this is ugly and also requires linking w/Carbon framework
-                 (for LMGetKbdType) so for now leave this rare (?) case
-                 undealt with.. in future look into CGEvent methods */
-              else
-                {
-                  long smv = GetScriptManagerVariable (smKeyScript);
-                  Handle uchrHandle = GetResource
-                    ('uchr', GetScriptVariable (smv, smScriptKeys));
-                  UInt32 dummy = 0;
-                  UCKeyTranslate ((UCKeyboardLayout*)*uchrHandle,
-                                 [[theEvent characters] characterAtIndex: 0],
-                                 kUCKeyActionDisplay,
-                                 (flags & ~NSCommandKeyMask) >> 8,
-                                 LMGetKbdType (), kUCKeyTranslateNoDeadKeysMask,
-                                 &dummy, 1, &dummy, &code);
-                  code &= 0xFF;
-                }
-#endif
-            }
-        }
-
-      is_right_key = (flags & NSRightControlKeyMask) == NSRightControlKeyMask;
-      is_left_key = (flags & NSLeftControlKeyMask) == NSLeftControlKeyMask
-        || (! is_right_key && (flags & NSControlKeyMask) == NSControlKeyMask);
-
-      if (is_right_key)
-          emacs_event->modifiers |= parse_solitary_modifier
-              (EQ (ns_right_control_modifier, Qleft)
-               ? ns_control_modifier
-               : ns_right_control_modifier);
-
-      if (is_left_key)
-        emacs_event->modifiers |= parse_solitary_modifier
-          (ns_control_modifier);
-
-      if (flags & NS_FUNCTION_KEY_MASK && !fnKeysym)
-          emacs_event->modifiers |=
-            parse_solitary_modifier (ns_function_modifier);
-
-      left_is_none = NILP (ns_alternate_modifier)
-        || EQ (ns_alternate_modifier, Qnone);
-
-      is_right_key = (flags & NSRightAlternateKeyMask)
-        == NSRightAlternateKeyMask;
-      is_left_key = (flags & NSLeftAlternateKeyMask) == NSLeftAlternateKeyMask
-        || (! is_right_key
-            && (flags & NSAlternateKeyMask) == NSAlternateKeyMask);
-
-      if (is_right_key)
-        {
-          if ((NILP (ns_right_alternate_modifier)
-               || EQ (ns_right_alternate_modifier, Qnone)
-               || (EQ (ns_right_alternate_modifier, Qleft) && left_is_none))
-              && !fnKeysym)
-            {   /* accept pre-interp alt comb */
-              if ([[theEvent characters] length] > 0)
-                code = [[theEvent characters] characterAtIndex: 0];
-              /*HACK: clear lone shift modifier to stop next if from firing */
-              if (emacs_event->modifiers == shift_modifier)
-                emacs_event->modifiers = 0;
-            }
-          else
-            emacs_event->modifiers |= parse_solitary_modifier
-              (EQ (ns_right_alternate_modifier, Qleft)
-               ? ns_alternate_modifier
-               : ns_right_alternate_modifier);
-        }
-
-      if (is_left_key) /* default = meta */
-        {
-          if (left_is_none && !fnKeysym)
-            {   /* accept pre-interp alt comb */
-              if ([[theEvent characters] length] > 0)
-                code = [[theEvent characters] characterAtIndex: 0];
-              /*HACK: clear lone shift modifier to stop next if from firing */
-              if (emacs_event->modifiers == shift_modifier)
-                emacs_event->modifiers = 0;
-            }
-          else
-              emacs_event->modifiers |=
-                parse_solitary_modifier (ns_alternate_modifier);
-        }
-
-  if (NS_KEYLOG)
-    fprintf (stderr, "keyDown: code =%x\tfnKey =%x\tflags = %x\tmods = %x\n",
-             code, fnKeysym, flags, emacs_event->modifiers);
+      if (NS_KEYLOG)
+        fprintf (stderr, "keyDown: code =%x\tfnKey =%x\tflags = %x\tmods = %x\n",
+                 code, fnKeysym, flags, emacs_event->modifiers);
 
-      /* if it was a function key or had modifiers, pass it directly to emacs */
+      /* If it was a function key or had control-like modifiers, pass
+         it directly to Emacs.  */
       if (fnKeysym || (emacs_event->modifiers
                        && (emacs_event->modifiers != shift_modifier)
                        && [[theEvent charactersIgnoringModifiers] length] > 0))
 /*[[theEvent characters] length] */
         {
           emacs_event->kind = NON_ASCII_KEYSTROKE_EVENT;
+          /* FIXME: What are the next four lines supposed to do?  */
           if (code < 0x20)
             code |= (1<<28)|(3<<16);
           else if (code == 0x7f)
             code |= (1<<28)|(3<<16);
           else if (!fnKeysym)
+            /* FIXME: This seems wrong, characters in the range
+               [0x80, 0xFF] are not ASCII characters.  Can’t we just
+               use MULTIBYTE_CHAR_KEYSTROKE_EVENT here for all kinds
+               of characters?  */
             emacs_event->kind = code > 0xFF
               ? MULTIBYTE_CHAR_KEYSTROKE_EVENT : ASCII_KEYSTROKE_EVENT;
 
@@ -5997,11 +5952,32 @@ not_in_argv (NSString *arg)
         }
     }
 
+  /* If we get here, a non-function key without control-like modifiers
+     was hit.  Use interpretKeyEvents, which in turn will call
+     insertText; see
+     https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html.  */
 
   if (NS_KEYLOG && !processingCompose)
     fprintf (stderr, "keyDown: Begin compose sequence.\n");
 
+  /* FIXME: interpretKeyEvents doesn’t seem to send insertText if ⌘ is
+     used as shift-like modifier, at least on El Capitan.  Mask it
+     out.  This shouldn’t be needed though; we should figure out what
+     the correct way of handling ⌘ is.  */
+  if ([theEvent modifierFlags] & NSCommandKeyMask)
+    theEvent = [NSEvent keyEventWithType:[theEvent type]
+                                location:[theEvent locationInWindow]
+                           modifierFlags:[theEvent modifierFlags] & ~NSCommandKeyMask
+                               timestamp:[theEvent timestamp]
+                            windowNumber:[theEvent windowNumber]
+                                 context:[theEvent context]
+                              characters:[theEvent characters]
+                        charactersIgnoringModifiers:[theEvent charactersIgnoringModifiers]
+                               isARepeat:[theEvent isARepeat]
+                                 keyCode:[theEvent keyCode]];
+
   processingCompose = YES;
+  /* FIXME: Use [NSArray arrayWithObject:theEvent]?  */
   [nsEvArray addObject: theEvent];
   [self interpretKeyEvents: nsEvArray];
   [nsEvArray removeObject: theEvent];
-- 
2.7.4

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

[Alan Third]

Philipp Stephani <p.stephani2@gmail.com> writes:

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

Hi Philipp,

Do you think this patch is still good?

I reckon the issues with command-key modifiers should be fixed, even if
it's just a new variable that disables the shift-like behaviour of
command.
-- 
Alan Third

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

[Philipp Stephani]

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

Alan Third <alan@idiocy.org> schrieb am Di., 26. Dez. 2017 um 18:42 Uhr:

> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > 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.
>
> Hi Philipp,
>
> Do you think this patch is still good?
>

I think so, modulo the caveats mentioned in the comments. Do you want me to
rebase and commit it?


>
> I reckon the issues with command-key modifiers should be fixed, even if
> it's just a new variable that disables the shift-like behaviour of
> command.
>
>
Do you mean "should be fixed" as in "I believe it's fixed" or as in "I want
it to be fixed, but it's not yet fixed"?

If the former, could you point me to the commit that fixed it?
If the latter, I'm not sure whether the macOS event model allows us to do
this. As mentioned in the comments in the patch, some information just
appears to be lost entirely.

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

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

[Alan Third]

On Tue, Dec 26, 2017 at 08:14:59PM +0000, Philipp Stephani wrote:
> Alan Third <alan@idiocy.org> schrieb am Di., 26. Dez. 2017 um 18:42 Uhr:
> 
> > Do you think this patch is still good?
> >
> 
> I think so, modulo the caveats mentioned in the comments. Do you want me to
> rebase and commit it?

As far as I can tell from the comments with the patch installed we
should be no worse off than we are at the moment?

I can’t quite work this out from a quick look at the code, but is it
the case that when option or command is bound to meta or super then it
acts as a control‐like modifier, but when it’s unbound then it acts as
a shift‐like modifier?

So this should give us the same behaviour for both keys that we have
with option just now?

> > I reckon the issues with command-key modifiers should be fixed, even if
> > it's just a new variable that disables the shift-like behaviour of
> > command.
> >
> >
> Do you mean "should be fixed" as in "I believe it's fixed" or as in "I want
> it to be fixed, but it's not yet fixed"?

Definitely the latter.

> If the latter, I'm not sure whether the macOS event model allows us to do
> this. As mentioned in the comments in the patch, some information just
> appears to be lost entirely.

I recently found myself using this lovely binding:

    (define-key global-map [C-s-268632064]
                'ns-do-show-character-palette)

and it seems crazy to me that the default behaviour of Emacs requires
us to use 268632064 instead of SPC when we could tell people using
unusual keyboard layouts to set a variable or something instead.

As for losing data, as long as it’s no worse than what we have at the
moment, which I believe you said is the case in a previous email, then
I don’t see a problem with that.

But perhaps I’ve misunderstood and there’s some worse behaviour?

Thanks!
-- 
Alan Third

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

[Philipp Stephani]

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

Alan Third <alan@idiocy.org> schrieb am Di., 26. Dez. 2017 um 22:16 Uhr:

> On Tue, Dec 26, 2017 at 08:14:59PM +0000, Philipp Stephani wrote:
> > Alan Third <alan@idiocy.org> schrieb am Di., 26. Dez. 2017 um 18:42 Uhr:
> >
> > > Do you think this patch is still good?
> > >
> >
> > I think so, modulo the caveats mentioned in the comments. Do you want me
> to
> > rebase and commit it?
>
> As far as I can tell from the comments with the patch installed we
> should be no worse off than we are at the moment?
>

I think it introduces some minor other issues (when a shift-like and a
control-like key are used at the same time), but the overall benefit should
be positive.


>
> I can’t quite work this out from a quick look at the code, but is it
> the case that when option or command is bound to meta or super then it
> acts as a control‐like modifier, but when it’s unbound then it acts as
> a shift‐like modifier?
>

The macOS code doesn't check whether certain keystrokes are bound. Rather,
it uses the ns-FOO-modifier customization options.


>
> So this should give us the same behaviour for both keys that we have
> with option just now?
>

Yes, command and option should have the same behavior (controlled by
customization options).


>
> > If the latter, I'm not sure whether the macOS event model allows us to do
> > this. As mentioned in the comments in the patch, some information just
> > appears to be lost entirely.
>
> I recently found myself using this lovely binding:
>
>     (define-key global-map [C-s-268632064]
>                 'ns-do-show-character-palette)
>
> and it seems crazy to me that the default behaviour of Emacs requires
> us to use 268632064 instead of SPC when we could tell people using
> unusual keyboard layouts to set a variable or something instead.
>
> As for losing data, as long as it’s no worse than what we have at the
> moment, which I believe you said is the case in a previous email, then
> I don’t see a problem with that.
>
> But perhaps I’ve misunderstood and there’s some worse behaviour?
>
>
I think it should be a significant improvement in practice. I'd suggest to
apply it and see whether we get any complaints.

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

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

[Alan Third]

On Sun, Feb 04, 2018 at 07:07:14PM +0000, Philipp Stephani wrote:
> >
> > I can’t quite work this out from a quick look at the code, but is it
> > the case that when option or command is bound to meta or super then it
> > acts as a control‐like modifier, but when it’s unbound then it acts as
> > a shift‐like modifier?
> >
> 
> The macOS code doesn't check whether certain keystrokes are bound. Rather,
> it uses the ns-FOO-modifier customization options.

That’s what I meant. Bind was a bad choice of word.

> I think it should be a significant improvement in practice. I'd suggest to
> apply it and see whether we get any complaints.

I expect we’ll get a few folk complaining that they’ve bound some
exotic looking key combination (C-π, C-¥, etc.) that no longer works,
but yes, I think we should apply it and see what happens.
-- 
Alan Third

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

[Philipp Stephani]

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

Alan Third <alan@idiocy.org> schrieb am So., 4. Feb. 2018 um 21:18 Uhr:

>
> > I think it should be a significant improvement in practice. I'd suggest
> to
> > apply it and see whether we get any complaints.
>
> I expect we’ll get a few folk complaining that they’ve bound some
> exotic looking key combination (C-π, C-¥, etc.) that no longer works,
> but yes, I think we should apply it and see what happens.
>
>
Sounds good, pushed to master as 8fbf28536e.

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