From: Ben McGinnes <ben@adversary.org>
To: Alan Third <alan@idiocy.org>
Cc: Philipp Stephani <p.stephani2@gmail.com>,
Noam Postavsky <npostavs@users.sourceforge.net>,
Emacs developers <emacs-devel@gnu.org>
Subject: Re: Emacs 26 MacOS bugs
Date: Sat, 10 Feb 2018 03:35:12 +1100 [thread overview]
Message-ID: <20180209163512.bgoqgj2ayyv4vvyq@adversary.org> (raw)
In-Reply-To: <20180207225505.GB1066@breton.holly.idiocy.org>
[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]
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. ;)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2018-02-09 16:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-06 14:49 Emacs 26 MacOS bugs Richard Stallman
2018-02-06 17:30 ` Noam Postavsky
2018-02-06 23:28 ` Paul Eggert
2018-02-07 3:37 ` Eli Zaretskii
2018-02-10 14:55 ` Uwe Brauer
2018-02-10 15:18 ` Noam Postavsky
2018-02-07 3:52 ` Eli Zaretskii
2018-02-06 19:05 ` Ben McGinnes
2018-02-06 20:30 ` Noam Postavsky
2018-02-06 22:27 ` Ben McGinnes
2018-02-06 22:30 ` Ben McGinnes
2018-02-06 22:50 ` Noam Postavsky
2018-02-07 0:43 ` Ben McGinnes
2018-02-07 1:33 ` Noam Postavsky
2018-02-07 2:13 ` Ben McGinnes
2018-02-07 22:55 ` Alan Third
2018-02-09 16:35 ` Ben McGinnes [this message]
2018-02-09 16:57 ` Noam Postavsky
2018-02-09 17:22 ` Ben McGinnes
2018-02-09 18:13 ` Noam Postavsky
2018-02-10 1:46 ` Ben McGinnes
2018-02-10 1:47 ` Alan Third
2018-02-11 13:53 ` Philipp Stephani
2018-02-11 21:06 ` Alan Third
2018-02-07 20:01 ` Alan Third
2018-02-10 15:01 ` Alan Third
2018-02-10 22:45 ` Alan Third
2018-02-11 11:47 ` Alan Third
2018-02-11 15:52 ` Eli Zaretskii
2018-02-11 20:57 ` Alan Third
2018-02-13 19:41 ` Ben McGinnes
2018-02-13 19:46 ` Noam Postavsky
2018-02-11 20:43 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180209163512.bgoqgj2ayyv4vvyq@adversary.org \
--to=ben@adversary.org \
--cc=alan@idiocy.org \
--cc=emacs-devel@gnu.org \
--cc=npostavs@users.sourceforge.net \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.