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

Previous Next

Full log

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

Previous Next

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