On Wed, Feb 07, 2018 at 10:55:05PM +0000, Alan Third wrote:
> On Wed, Feb 07, 2018 at 01:13:01PM +1100, Ben McGinnes wrote:
> > On Tue, Feb 06, 2018 at 08:33:31PM -0500, Noam Postavsky wrote:
> > > AFAIK, there's no firm date, but emacs-26 is in feature freeze and
> > > only taking very safe/urgent bug fixes. So it's possible these bugs
> > > won't be fixed until after 26.1
> > 
> > I think I could make a very convincing argument regarding the modifier
> > keys here being urgent.  If it was only rendering the hyper key
> > useless, then maybe you could argue it as not being urgent, but it's
> > not merely that ...
> 
> The good news is that the patch that affects the modifier keys isn’t
> in Emacs 26, it was pushed to master only.

That's good, though it does mean I need to clarify something:

When the commit log says something like "Merge from origin/emacs-26" I
should take that to mean not really emacs-26 at all?  Possibly not
from origin either, right?

Because I'm fairly sure most people with moderate (or greater)
familiarity with git would assume that was another standard citation
of $default_remote_alias/$branch_name.  If this project is using that
nomenclature differently, that sounds like a fairly important thing to
add to the CONTRIBUTE file.

>> As for a stable fix, that's dead simple, roll back everything from
>> the 2016 commit that was merged into master on the 5th and it's
>> done.
> 
> I know you think there was nothing wrong with the old code,

I wouldn't go that far, but I figured reverting could only result in
things not being more broken and/or bizarre than previously; as
opposed to what that patch did.

> but it was broken in various ways that weren’t obvious how to
> fix. The new code should behave more consistently, once we clear up
> the bugs you’ve found.
> 
> Can you please try the attached patch?

Yeah, I'll have to try it in a couple of days or so, I'm on the road
at the moment.

> Philipp, it seems that EV_MODIFIERS2 was quite, quite broken. I’ve
> split it into various parts and tried to fix it.
> 
> Additionally the fn key has some strange interactions with ‘function’
> keys, like the Fx keys, arrows, tab and so on. The old code simply
> didn’t set its modifier when those keys were used, so I’ve followed
> that lead and am XORing it out of emacs_event->modifiers.

Both Fn and the Command key will generally do that, but the extent of
it is somewhat customisable to an extent.  It depends on which version
of OS X is used, which programs are used to modify key maps or
functions and some system preferences.

So I'm running OS X 10.9.x along with Karibiner and Seil to modify
various key functions (apparently those 2 projects have merged and
been renamed for more recent versions of OS X).

Both my Command keys are configured as super keys, but if there's a
key sequence for OS X, then it'll take priority (I've already
reconfigured the default quit for OS X to be Command+Q+W because
Command+Q got me in enough trouble without even including Emacs in the
mix).  This means some sequences are either pre-configured with
various ns- functions or have been re-configured to point to 'nil and
a comment to remind myself not to touch it.

Whereas the Fn key is set to hyper and will be that with everything
except the Fx keys.  All those keys are configured to be themselves
primarily and whatever their OS/multimedia function is as the
alternative via Fn.  This also helps since I've got F1-F19 instead of
F1-F12.

Simple enough, but the only real "gotcha" with Fn is Karibiner also
includes a deceptive option to "turn the Fn key into a hyper key" and
this can definitely cause problems because the Karibiner
interpretation of a hyper key is what I've taken to calling a
non-hyper sequence.  When it's activated it won't produce "H-"
bindings, it produces "C-M-S-s-" bindings (sometimes that appears to
be "C-M-S-s-" in the "C-h k" lookups, but "C-M-s-" when actually
used).

Still, all of these things continue to report standard key events in
hexadecimal so at the end of the day, if you can detect that then you
should be able to configure these things any way you please.


Regards,
Ben

P.S.  Great domain name.  ;)