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.