From: Ben McGinnes <ben@adversary.org>
To: Noam Postavsky <npostavs@users.sourceforge.net>
Cc: Alan Third <alan@idiocy.org>,
Philipp Stephani <p.stephani2@gmail.com>,
Emacs developers <emacs-devel@gnu.org>
Subject: Re: Emacs 26 MacOS bugs
Date: Sat, 10 Feb 2018 12:46:04 +1100 [thread overview]
Message-ID: <20180210014604.4342tjuqn3pynppf@adversary.org> (raw)
In-Reply-To: <CAM-tV-9ya=+fh0Y5OEuNmNrNj3qrT8CpweWpXDjnmoemab2pTA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4962 bytes --]
On Fri, Feb 09, 2018 at 01:13:12PM -0500, Noam Postavsky wrote:
> On Fri, Feb 9, 2018 at 12:22 PM, Ben McGinnes <ben@adversary.org> wrote:
>
> > Preceded by the commit I've been referring to:
> >
> > commit a0c7157a16481b0523ad20cda9115f9435188f73
> > Merge: c24c5dc4a4 c787a49682
>
> Looking at the diff of [a0c7157] (e.g., with git show -p --stat
> a0c7157), I can see the merge mainly affected documentation and did
> not touch src/nsterm.m, unlike [8fbf285] (the commit you identified as
> the original source of trouble). By default git shows the diff against
> the first parent [p1] which is the previous commit of master, if you
> look at the diff against the second parent [p2] you see the diff
> against the emacs-26 commit which was merged. The latter diff shows
> the nsterm.m modification, indicating that master has the
> modification, but emacs-26 does not.
That is much clearer and it prompted me to take a much closer look at
commit 8fbf28536ee1169f59206523e2af050916befbf6. Specifically with
the "--pretty=fuller" and "--pretty=raw" options. I'd thought that
the "mysterious appearance" of a commit from 2016, followed a shortly
after by a merge commit containing a bunch of references to issues and
bugs indicated it was part of the merge and thus would've been an
accepted pull request that was added during that merge. Now it's
looking more like it was just coincidence.
It also looks like it's really been working from around (and no later
than) commit df441b362c25c4ad59ea3d83137328d0d4098eaf, or maybe commit
22443312188ff097b69d9ff4b87c2b4f7bbbc263, though I suspect it may
really be from one of the ones just prior to those in preparation for
Emacs 25's release.
> [p2]: https://git.savannah.gnu.org/cgit/emacs.git/diff/?id=a0c7157a16481b0523ad20cda9115f9435188f73&id2=c787a4968273027960a20ced6d63bae0d1ffa87e
This diff was more useful, though, because while it did break things
it did identify a few quirks and provided a dead-ish (sometimes it'll
forward properly, but sometimes it doesn't), but still useful
reference link. That's this link included in the comments for
interpretKeyEvents and insertText:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
Which forwards here (eventually):
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
This page looks like it may be particularly helpful too:
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/EventOverview/TextDefaultsBindings/TextDefaultsBindings.html
The StandardKeyBinding.dict file mentioned on that page is Apple's
annoying binary format, but if anyone working on these issues needs a
copy converted back to XML as StandardKeyBinding.plist I can dump the
one I've got here somewhere. When viewing it I *highly* recommend
using a configuration with a broad range of fontset fallback coverage,
the fonts to display at least the first multiplane and bind
describe-char to something convenient.
This is, of course, because it's an XML file, which means the content
must be either UTF-8 or UTF-16 (it's UTF-8). So a lot of those key
sequences or special functions are associated with certain higher
hexadecimal values which display as apparently incongruous characters.
There's also some kind of system of setting hidden modifier keys which
it appears can't be modified or utilised, or not easily at any rate.
The directional keys for up, down, left and right are a good example.
Their codes don't match the corresponding UTF-8 characters (0x7b to
0x7e), but that's less an issue than the fact that pressing one of
those keys on its own activates a modifier key called NumPad Fn, which
is different from Fn. Indeed, pressing Fn and either of the arrows
produces entirely different results (page up, page down, home and
end), but for those of us with separate keys for those actions using
the Fn key with them (e.g. Fn+Home) makes no difference.
On top of which NSEvent.h indicates they may chage a bit (based on a
diff of the one for 10.9 and the one for 10.10). I'm fairly sure I've
got a barely checked Apple developer account, I might have to see if I
can unearth every version of NSEvent.h since Leopard or Snow Leopard.
It seems like that might come in handy at some point.
Although I strongly suspect the answers to a lot of the problems here
will ultimately be found via the source code of Karibiner, Seil and
their related projects:
https://github.com/tekezo?tab=repositories
The chances are quite high that those projects solve much of what is
being attempted here or at least demonstrate how to do the sorts of
things being attempted. The terms that code is released under is
quite compatible with any version of the GPL too (it's all public
domain).
Regards,
Ben
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2018-02-10 1:46 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
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 [this message]
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=20180210014604.4342tjuqn3pynppf@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.