Re: Emacs 26 MacOS bugs

[Ben McGinnes]

On Fri, Feb 09, 2018 at 01:13:12PM -0500, Noam Postavsky wrote:
> On Fri, Feb 9, 2018 at 12:22 PM, Ben McGinnes <address@hidden> 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

signature.asc
Description: PGP signature