bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19977: 24.4; Incorrect translation of Super modifier with Ctrl or Me


From: Alan Third
Subject: 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
User-agent: Mutt/1.9.1 (2017-09-22)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]