On Tue, Feb 06, 2018 at 03:30:37PM -0500, Noam Postavsky wrote: > On Tue, Feb 6, 2018 at 2:05 PM, Ben McGinnes wrote: > > > I can't test Sierra (yet), but if it's actually across the board with > > OS X. I can test Mavericks. I may be able to test Sierra later. > > The --no-build-details problem seems pretty straightforward, does the > following fix it? (I'm not sure what the macOS does with the first arg > exactly, i.e., if an empty string is okay there.) Getting the most recent commit to build on Mavericks (with path update at build time) isn't actually a problem. It will build and it will load ... it'll even load enough of my init to reach the theme at the end ... but I wouldn't exactly describe it as functional. What could be extracted from that is in the attached org-file. I was, however able to identify the bytecomp failure (which was also what wreaked havoc on the ERC+ZNC connection infinite loop. More pressing, however (and somewhat ironically), is the complete failure to handle ns-modifier keys correctly and thus nullify most, if not all, keybindings. This catastrophic error (which I suspect will be behind or directly related to the other major errors) can be traced back to commit 8fbf28536ee1169f59206523e2af050916befbf6 (March 30, 2016) which tried to "fix" something that wasn't broken. It was subsequently merged from the emacs-26 branch in commit a0c7157a16481b0523ad20cda9115f9435188f73 the other day. Unlike "normal" OS X users, I have my function keys permanently set as regular function keys and use the Fn key to access the multimedia features instead of the other way around. This change to the way ns-function operates in cus-start.el results in the function key not working at all (it's configured as a hyper key for use with other key combinations) and every single F-key registers as H-F* instead of F*. That doesn't even get into how these changes mess with other OS level key mapping (using Karibiner and Seil on OS X to get useful things like the caps lock as a control key and so on). Also, there have been changes to both lisp/cus-start.el and src/nsterm.m in master between March 2016 and the merging of that code. I think it's highly likely that some of those changes have tried to address similar things in different ways and when that code from 2 years ago was merged it created the joyous little catastrophe we see here. I strongly suspect that reversing that part of the merge, to restore src/nsterm.m and list/cus-start.el to the way they were a couple of days ago will restore functionality to most, if not all builds. If I'm right, then maybe take a bit more of a conservative approach to assumptions regarding how the hardware actually works (and can be made to work by the sort of people who use Emacs). Regards, Ben -- | Ben McGinnes | Adversarial Press | Author and Publisher | | Writer, Trainer, Systems Administrator, Developer, ICT Consultant | | Twitter: @benmcginnes (personal) | @AdversaryPub (publishing) | | Web: http://www.adversary.org/ http://publishing.adversary.org/ | | ----------------------------------------------------------------- | | GPG Made Easy (GPGME) Python 3 API Maintainer, GNU Privacy Guard | | GPG key: 0x321E4E2373590E5D http://www.adversary.org/ben-key.asc | | GPG key fpr: DB47 24E6 FA42 86C9 2B4E 55C4 321E 4E23 7359 0E5D | | https://www.gnupg.org/ https://securetheinternet.org/ | | ----------------------------------------------------------------- | | This message may be delayed by failures of the Australian NBN. | | ----------------------------------------------------------------- |