Re: Emacs 26 MacOS bugs

[Ben McGinnes]

On Tue, Feb 06, 2018 at 03:30:37PM -0500, Noam Postavsky wrote:
> On Tue, Feb 6, 2018 at 2:05 PM, Ben McGinnes <address@hidden> 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.   |
| ----------------------------------------------------------------- |

signature.asc
Description: PGP signature