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