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

[Philipp Stephani <p.stephani2@gmail.com>]

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