GNU bug report logs - #19977
24.4; Incorrect translation of Super modifier with Ctrl or Meta on OS X

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19977 in the body.
You can then email your comments to 19977 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4;
 Incorrect translation of Super modifier with Ctrl or Meta on OS X
Date: Sun, 01 Mar 2015 17:36:29 +0100

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

Message #10 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 10:17:42 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #13 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4;
 Incorrect translation of Super modifier with Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 18:10:32 +0300

> From: Philipp Stephani <p.stephani2 <at> 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?

Message #16 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 15:29:56 +0000

[Message part 1 (text/plain, inline)]

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

> > From: Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #19 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 15:45:13 +0000

[Message part 1 (text/plain, inline)]

Philipp Stephani <p.stephani2 <at> 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

[Message part 2 (text/html, inline)]

Message #22 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 18:59:55 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Tue, 29 Mar 2016 15:45:13 +0000
> Cc: 19977 <at> 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.

Message #25 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 16:31:28 +0000

[Message part 1 (text/plain, inline)]

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

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Tue, 29 Mar 2016 15:45:13 +0000
> > Cc: 19977 <at> 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.

[Message part 2 (text/html, inline)]

Message #28 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 16:38:52 +0000

[Message part 1 (text/plain, inline)]

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

> Eli Zaretskii <eliz <at> gnu.org> schrieb am Di., 29. März 2016 um 18:00 Uhr:
>
>> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> > Date: Tue, 29 Mar 2016 15:45:13 +0000
>> > Cc: 19977 <at> 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.

[Message part 2 (text/html, inline)]

[0001-Fix-bug-19977.patch (application/octet-stream, attachment)]

Message #31 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>,
 Adrian Robert <Adrian.B.Robert <at> gmail.com>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 19:57:10 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Tue, 29 Mar 2016 16:38:52 +0000
> Cc: 19977 <at> 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.

Message #34 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4;
 Incorrect translation of Super modifier with Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 20:19:23 +0300

On 2016.3.29, at 19:57, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> Date: Tue, 29 Mar 2016 16:38:52 +0000
>> Cc: 19977 <at> 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

Message #37 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 17:44:20 +0000

[Message part 1 (text/plain, inline)]

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

>
> On 2016.3.29, at 19:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> >> Date: Tue, 29 Mar 2016 16:38:52 +0000
> >> Cc: 19977 <at> 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.

[Message part 2 (text/html, inline)]

Message #40 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4;
 Incorrect translation of Super modifier with Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 20:56:40 +0300

On 2016.3.29, at 20:44, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:

> 
> 
> Adrian Robert <adrian.b.robert <at> gmail.com> schrieb am Di., 29. März 2016 um 19:19 Uhr:
> 
> On 2016.3.29, at 19:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> >> Date: Tue, 29 Mar 2016 16:38:52 +0000
> >> Cc: 19977 <at> 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>.

Message #43 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 19:43:47 +0000

[Message part 1 (text/plain, inline)]

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

>
> On 2016.3.29, at 20:44, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
>
> >
> >
> > Adrian Robert <adrian.b.robert <at> gmail.com> schrieb am Di., 29. März 2016
> um 19:19 Uhr:
> >
> > On 2016.3.29, at 19:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > >> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > >> Date: Tue, 29 Mar 2016 16:38:52 +0000
> > >> Cc: 19977 <at> 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.

[Message part 2 (text/html, inline)]

Message #46 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Adrian Robert <adrian.b.robert <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 29 Mar 2016 20:07:55 +0000

[Message part 1 (text/plain, inline)]

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

> Adrian Robert <adrian.b.robert <at> gmail.com> schrieb am Di., 29. März 2016
> um 19:56 Uhr:
>
>>
>> On 2016.3.29, at 20:44, Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
>>
>> >
>> >
>> > Adrian Robert <adrian.b.robert <at> gmail.com> schrieb am Di., 29. März
>> 2016 um 19:19 Uhr:
>> >
>> > On 2016.3.29, at 19:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >
>> > >> From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> > >> Date: Tue, 29 Mar 2016 16:38:52 +0000
>> > >> Cc: 19977 <at> 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.

[Message part 2 (text/html, inline)]

Message #49 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: adrian.b.robert <at> gmail.com, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Wed, 30 Mar 2016 05:39:23 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Tue, 29 Mar 2016 20:07:55 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 19977 <at> 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.

Message #52 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: adrian.b.robert <at> gmail.com, 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Wed, 30 Mar 2016 17:35:30 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> schrieb am Mi., 30. März 2016 um 04:39 Uhr:

> > From: Philipp Stephani <p.stephani2 <at> gmail.com>
> > Date: Tue, 29 Mar 2016 20:07:55 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 19977 <at> 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.

[Message part 2 (text/html, inline)]

[0001-Fix-handling-of-modifier-keys-on-OS-X.patch (application/octet-stream, attachment)]

Message #55 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: "Mikhail Gusarov" <dottedmag <at> dottedmag.net>
To: "Anders Lindgren" <andlind <at> gmail.com>,
 "Kai Yu Zhang" <yeannylam <at> gmail.com>, 21551 <at> debbugs.gnu.org,
 "Philipp Stephani" <p.stephani2 <at> gmail.com>, 21330 <at> debbugs.gnu.org,
 19977 <at> debbugs.gnu.org
Subject: Re: Fix Mac OS X key bindings bug
Date: Mon, 26 Dec 2016 21:12:46 +0100

[Message part 1 (text/plain, inline)]

Hi Anders,

I have tried reproducing this discrepancy using my patch from #21330
on top of branch emacs-25.

Swedish layout, ns-alternate-modifier set to nil, LCmd-LAlt-9 replies
"s-]".

Maybe you could check again as well?

Best regards,
Mikhail.

On 2 Jan 2016, at 9:08, Anders Lindgren wrote:

> I found a case where the code in question is needed, which none of the
> suggested patches handle correctly.
>
> Steps to repeat:
>
>     (setq ns-alternate-modifier nil)
>
>     Press left CMD-ALT-9
>
>     An unmodified Emacs replies "s-]" is not bound. (This assumes a Swedish
> keyboard layout, other layouts would yield a different character, but the
> principle is the same).
>
>     With either of the two patches, Emacs respond with "s-9" is not bound,
> which isn't correct.
>
> Unfortunately, I don't know how to distinguish between the cases where we
> need to strip away modifiers (C-s-a) and when we shouldn't, so I'm leaving
> this open for now.
>
>     -- Anders Lindgren
>
>
> On Wed, Dec 30, 2015 at 9:50 AM, Anders Lindgren <andlind <at> gmail.com> wrote:
>
>> Hi,
>>
>> I'm looking into a key binding bug on OS X reported multiple times (19977,
>> 21330, 21551). Two different patches have been submitted.
>>
>> The original code looks like:
>>
>>       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];
>>
>> One of the patches simply removes the `if (EQ(...))' statement. The other
>> modifies the code to strip away modifiers.
>>
>> First question: What is the code in the `if (EQ(...))' supposed to do? In
>> other words, what will stop working if it is removed?
>>
>> Second question: if it is needed for the LEFT command key, should the
>> corresponding code be added for the RIGHT?
>>
>> I've tested removing the `if' and Emacs still seems to be working as
>> intended, both with a normal key layout and when Dvorak is used. If no one
>> comes up with a reason to keep the code, I will remove it.
>>
>> Third question: Does anybody know of a good way to automatically test
>> things like this? What I'm looking for is a way to send keystrokes like
>> Cmd-Alt-a to Emacs, that way it could be possible to write tests ensuring
>> that things like this don't break in the future.
>>
>>     -- Anders Lindgren
>>
>>

[Message part 2 (text/html, inline)]

Message #58 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com,
 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4;
 Incorrect translation of Super modifier with Ctrl or Meta on OS X
Date: Tue, 26 Dec 2017 17:42:48 +0000

Philipp Stephani <p.stephani2 <at> 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

Message #61 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com,
 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 26 Dec 2017 20:14:59 +0000

[Message part 1 (text/plain, inline)]

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

> Philipp Stephani <p.stephani2 <at> 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.

[Message part 2 (text/html, inline)]

Message #64 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com,
 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Tue, 26 Dec 2017 21:16:03 +0000

On Tue, Dec 26, 2017 at 08:14:59PM +0000, Philipp Stephani wrote:
> Alan Third <alan <at> 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

Message #67 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com,
 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Sun, 04 Feb 2018 19:07:14 +0000

[Message part 1 (text/plain, inline)]

Alan Third <alan <at> 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 <at> 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.

[Message part 2 (text/html, inline)]

Message #70 received at 19977 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com,
 19977 <at> debbugs.gnu.org
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Sun, 4 Feb 2018 20:18:28 +0000

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

Message #75 received at 19977-done <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, 19977-done <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, adrian.b.robert <at> gmail.com
Subject: Re: bug#19977: 24.4; Incorrect translation of Super modifier with
 Ctrl or Meta on OS X
Date: Mon, 05 Feb 2018 08:02:44 +0000

[Message part 1 (text/plain, inline)]

Alan Third <alan <at> 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.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.