Emacs 26 MacOS bugs

Emacs 26 MacOS bugs

[Richard Stallman]

The OP, reviewing the draft Emacs manual,
reported these software bugs.

It would be better to fix them than to document them.
I suggest fixing them in Emacs 26.

From: Cena Mayo <cenazoic@gmail.com>
Date: Mon, 5 Feb 2018 12:50:36 -0600
Message-ID: <CAACLqcTAowjT3XEzDz08LcyCjzsgsJcbWvGqEKFvLGgpLh16Hg@mail.gmail.com>
Subject: Re: Appendix C, Appendix F
To: emacs-manual-bugs@gnu.org, John Wiegley <johnw@gnu.org>
Content-Type: multipart/alternative; boundary="001a11432546a52a4005647b89e6"



Appendix C
Command Line Arguments for Emacs Invocation
notes:

C.2 :
- - (p 510) - "--no-build-details" returns:
       Wrong type argument: stringp, nil

C.10 :
- - (p 520) neither -T=title nor --title=title appear to work on macOS
(Sierra), although --name=title does.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Tue, Feb 6, 2018 at 9:49 AM, Richard Stallman <rms@gnu.org> wrote:

> - - (p 510) - "--no-build-details" returns:
>        Wrong type argument: stringp, nil

Not sure about macOS, but on w32 I get an assertion failure, patch attached.

[-- Attachment #2: v1-0001-Handle-nil-system-name-e.g.-when-using-no-build-d.patch --]
[-- Type: application/octet-stream, Size: 1390 bytes --]

From cbf51e0f71906f78e6ff81ed10491e68eb34f882 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Tue, 6 Feb 2018 12:20:37 -0500
Subject: [PATCH v1] Handle nil system-name (e.g., when using
 --no-build-details)

* src/w32term.c (w32_initialize_display_info): Handle nil system-name.
---
 src/w32term.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/src/w32term.c b/src/w32term.c
index db4ccf5..ac29bbb 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6922,10 +6922,15 @@ w32_initialize_display_info (Lisp_Object display_name)
   memset (dpyinfo, 0, sizeof (*dpyinfo));
 
   dpyinfo->name_list_element = Fcons (display_name, Qnil);
-  dpyinfo->w32_id_name = xmalloc (SCHARS (Vinvocation_name)
-				  + SCHARS (Vsystem_name) + 2);
-  sprintf (dpyinfo->w32_id_name, "%s@%s",
-	   SDATA (Vinvocation_name), SDATA (Vsystem_name));
+  if (STRINGP (Vsystem_name))
+    {
+      dpyinfo->w32_id_name = xmalloc (SCHARS (Vinvocation_name)
+                                      + SCHARS (Vsystem_name) + 2);
+      sprintf (dpyinfo->w32_id_name, "%s@%s",
+               SDATA (Vinvocation_name), SDATA (Vsystem_name));
+    }
+  else
+    dpyinfo->w32_id_name = xlispstrdup (Vinvocation_name);
 
   /* Default Console mode values - overridden when running in GUI mode
      with values obtained from system metrics.  */
-- 
2.6.2.windows.1

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On Tue, Feb 06, 2018 at 09:49:16AM -0500, Richard Stallman wrote:
> The OP, reviewing the draft Emacs manual,
> reported these software bugs.
> 
> It would be better to fix them than to document them.
> I suggest fixing them in Emacs 26.

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.

A build up to commit b937381e51df28551463da410577c72fb5fa6ace (end of
January) is mostly behaving itself.  Except for the ERC+ZNC with an
infinite loop of connection failures and a bytecomp error on launch.

Quite happy to help narrow things further if it's needed.  Though this
build is only possible by changing the path to begin with all the
macports paths (/opt/local) in order to find a useable makeinfo and
friends.  So "standard install" it shall never be.


Regards,
Ben

-- 
|  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.   |
| ----------------------------------------------------------------- |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Tue, Feb 6, 2018 at 2:05 PM, Ben McGinnes <ben@adversary.org> 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.)

--- i/lisp/term/ns-win.el
+++ w/lisp/term/ns-win.el
@@ -834,7 +834,7 @@ ns-initialized
             (format "Creation of the standard fontset failed: %s" err)
             :error)))

-  (x-open-connection (system-name) x-command-line-resources t)
+  (x-open-connection (or (system-name) "") x-command-line-resources t)

   ;; Add GNUstep menu items Services, Hide and Quit.  Rename Help to Info
   ;; and put it first (i.e. omit from menu-bar-final-items.

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1.1: Type: text/plain, Size: 644 bytes --]

On Wed, Feb 07, 2018 at 09:27:22AM +1100, Ben McGinnes wrote:
> 
> 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.

Erm, it would, of course, help to actually attach the damned thing ...


Regards,
Ben

[-- Attachment #1.2: emacs27-osx10_9-20180205-01.org --]
[-- Type: text/plain, Size: 3498 bytes --]

* Failures of Feb build of master

** Version

GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2018-02-07

GNU Emacs 27.0.50 (build 1, x86_64-apple-darwin13.4.0, NS
appkit-1265.21 Version 10.9.5 (Build 13F1911)) of 2018-02-07

*** Commit

commit 5c414441ed73f1a302a2953dc493e83b98589262 (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Mon Feb 5 16:27:24 2018 -0800

    Work around macOS faccessat bug

    * src/fileio.c (file_accessible_directory_p): Append an
    extra "/" to work around macOS bug in faccessat (Bug#30350).


** Messages

For information about GNU Emacs and the GNU system, type C-h C-a.
Loading /Users/ben/.emacs...
Loading /Users/ben/.emacs-init/config/modes-non-packages.el (source)...done
Loading /Users/ben/.emacs-init/config/repos.el (source)...done
Loading /Users/ben/.emacs-init/config/modes-non-melpa.el (source)...done
Created magit link.
Loading /Users/ben/.emacs-init/config/modes-non-proxy.el (source)...
Failed to start an edit-server
Loading /Users/ben/.emacs-init/config/modes-non-proxy.el (source)...done
Loading /Users/ben/.emacs-init/config/modes.el (source)...done
Loading /Users/ben/.emacs-init/config/functions.el (source)...done
Loading /Users/ben/.emacs-init/config/globals.el (source)...done
Loading /Users/ben/.emacs-init/config/fonts.el (source)...done
Loading /Users/ben/.emacs-init/config/custom-dev.el (source)...
Loading time...done
Loading winner...done
Loading /Users/ben/.emacs.d/recentf...done
Cleaning up the recentf list...done (0 removed)
Loading /Users/ben/.emacs-init/config/custom-dev.el (source)...done
Loading /Users/ben/.emacs-init/config/theme.el (source)...
Loading /Users/ben/.emacs.d/elpa/color-theme-20080305.34/themes/color-theme-example.el (source)...done
Loading /Users/ben/.emacs.d/elpa/color-theme-20080305.34/themes/color-theme-example.elc...done
Loading /Users/ben/.emacs.d/elpa/color-theme-20080305.34/themes/color-theme-library.el (source)...done
Loading /Users/ben/.emacs.d/elpa/color-theme-20080305.34/themes/color-theme-library.elc...done
Loading /Users/ben/.emacs-init/config/theme.el (source)...done
Loading /Users/ben/.emacs...done
<H-f1> is undefined
<H-up> is undefined
Entering debugger...
Back to top level
<H-up> is undefined
<H-down> is undefined
Loading /Users/ben/.emacs-init/config/globals.el (source)...done
You can run the command ‘load-file’ with <f6>
Loading /Users/ben/.emacs-init/config/globals.el (source)...done
<H-f1> is undefined
Quit [2 times]


** Compile Log

~/.emacs.d/gitpacks/znc/znc.el:Warning: value returned from (get-buffer
    wants-name) is unused

*** ZNC function causing that

(defadvice erc-server-reconnect (after znc-erc-rename last nil activate)
  "Maybe rename the buffer we create"
  (let* ((wants-name (and (local-variable-p 'znc-buffer-name (erc-server-buffer))
                          (buffer-local-value 'znc-buffer-name (erc-server-buffer))))
         (current (erc-server-buffer))
         (returning ad-return-value))
    (if wants-name
        (progn
          (ignore-errors (znc-kill-buffer-always wants-name))
          (with-current-buffer returning
            (znc-set-name wants-name)
            (rename-buffer wants-name))
          (get-buffer wants-name))
      returning)))

See the second last line.  This is what fails when ERC has its infinite loop.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Tue, Feb 6, 2018 at 5:27 PM, Ben McGinnes <ben@adversary.org> wrote:

> 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.

You seem to be describing some different bugs from what is in the OP
of this thread. I think you should open new bugs in the tracker for
them (send email to bug-gnu-emacs@gnu.org).
(and please as much as possible, show how to replicate the bug
starting from emacs -Q)

Re: Emacs 26 MacOS bugs

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

On 02/06/2018 09:30 AM, Noam Postavsky wrote:
> on w32 I get an assertion failure, patch attached.

On Fedora 27 x86-64 I get a crash when running 'emacs 
--no-build-details'. There are several places in the Emacs code that 
crash when Fsystem_name returns a non-string. Proposed patch attached.


[-- Attachment #2: 0001-Fix-crashes-when-run-with-no-build-details.txt --]
[-- Type: text/plain, Size: 2905 bytes --]

From c7602b4e9e074eb8d0fd701d094f1c244713a70f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 6 Feb 2018 15:25:45 -0800
Subject: [PATCH] Fix crashes when run with --no-build-details
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/xrdb.c (get_environ_db):
* src/xterm.c (same_x_server, x_term_init):
Don’t assume Fsystem_name returns a string.
---
 src/xrdb.c  | 19 +++++++++++--------
 src/xterm.c | 16 +++++++++++-----
 2 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/src/xrdb.c b/src/xrdb.c
index b55c0f9011..836c147947 100644
--- a/src/xrdb.c
+++ b/src/xrdb.c
@@ -376,15 +376,18 @@ get_environ_db (void)
 
   if (!p)
     {
-      /* Use ~/.Xdefaults-HOSTNAME.  */
-      char *home = gethomedir ();
-      ptrdiff_t homelen = strlen (home);
       Lisp_Object system_name = Fsystem_name ();
-      ptrdiff_t filenamesize = (homelen + sizeof xdefaults
-				+ 1 + SBYTES (system_name));
-      p = filename = xrealloc (home, filenamesize);
-      lispstpcpy (stpcpy (stpcpy (filename + homelen, xdefaults), "-"),
-		  system_name);
+      if (STRINGP (system_name))
+	{
+	  /* Use ~/.Xdefaults-HOSTNAME.  */
+	  char *home = gethomedir ();
+	  ptrdiff_t homelen = strlen (home);
+	  ptrdiff_t filenamesize = (homelen + sizeof xdefaults
+				    + 1 + SBYTES (system_name));
+	  p = filename = xrealloc (home, filenamesize);
+	  lispstpcpy (stpcpy (stpcpy (filename + homelen, xdefaults), "-"),
+		      system_name);
+	}
     }
 
   db = XrmGetFileDatabase (p);
diff --git a/src/xterm.c b/src/xterm.c
index 364a8a8db0..b10664dda9 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -12150,6 +12150,8 @@ same_x_server (const char *name1, const char *name2)
 {
   bool seen_colon = false;
   Lisp_Object sysname = Fsystem_name ();
+  if (! STRINGP (sysname))
+    sysname = empty_unibyte_string;
   const char *system_name = SSDATA (sysname);
   ptrdiff_t system_name_length = SBYTES (sysname);
   ptrdiff_t length_until_period = 0;
@@ -12572,15 +12574,19 @@ x_term_init (Lisp_Object display_name, char *xrm_option, char *resource_name)
 #endif
 
   Lisp_Object system_name = Fsystem_name ();
-  ptrdiff_t nbytes;
-  if (INT_ADD_WRAPV (SBYTES (Vinvocation_name), SBYTES (system_name) + 2,
-		     &nbytes))
+
+  ptrdiff_t nbytes = SBYTES (Vinvocation_name) + 1;
+  if (STRINGP (system_name)
+      && INT_ADD_WRAPV (nbytes, SBYTES (system_name) + 1, &nbytes))
     memory_full (SIZE_MAX);
   dpyinfo->x_id = ++x_display_id;
   dpyinfo->x_id_name = xmalloc (nbytes);
   char *nametail = lispstpcpy (dpyinfo->x_id_name, Vinvocation_name);
-  *nametail++ = '@';
-  lispstpcpy (nametail, system_name);
+  if (STRINGP (system_name))
+    {
+      *nametail++ = '@';
+      lispstpcpy (nametail, system_name);
+    }
 
   /* Figure out which modifier bits mean what.  */
   x_find_modifier_meanings (dpyinfo);
-- 
2.14.3

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]

On Tue, Feb 06, 2018 at 05:50:18PM -0500, Noam Postavsky wrote:
> On Tue, Feb 6, 2018 at 5:27 PM, Ben McGinnes <ben@adversary.org> wrote:
> 
> > 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.
> 
> You seem to be describing some different bugs from what is in the OP
> of this thread. I think you should open new bugs in the tracker for
> them (send email to bug-gnu-emacs@gnu.org).
> (and please as much as possible, show how to replicate the bug
> starting from emacs -Q)

Sure, how many current OS X bugs have already been reported and which
ones are they?  I also want to be sure I'm not simply duplicating
existing reported bugs.

Oh, it might be worth mentioning that in spite of using Emacs for
years, I didn't get around to subscribing to this list and the orgmode
one until yesterday ... so I almost certainly won't have read back
through the archives enough to know how long or short the osx bug list
currently is.  Nor do I know how pressing the release date for version
26 is, if it's even locked in at all.

The build one I haven't properly replicated, the title one might be
related to what I saw with ERC+ZNC since it pertains to the
buffer-name, but it might be unrelated.

The ns-modifier conflicts and all the related aspects of that, if
there isn't a current bug then I can certainly provide all that and I
may as well test my proposed solution while I'm at it.  I do have a
rather hectic couple of days or so, it might get pushed back to the
weekend, but I'll see where I can squeeze it in.  At worst, though, my
bughunting efforts would only be delayed until early next week.

I have compiled the another copy with the src/nsterm.* and
lisp/cus-start.el copied from the working build from the 4th and
though I've got to do a thorough audit, it's looking like much OS X
pain lies pretty much exactly where I said.  The lisp/cus-start.el
file had the clues, but the majority of the butchery is in
src/nsterm.m.

I'll include diffs later, of course, but since this is likely
frustrating others who may not want to wait for my schedule to lighten
to get stuck into it; ad hoc info be here, proper bug report and
recommendations (or outright fixes) to be advised.


Regards,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Tue, Feb 6, 2018 at 7:43 PM, Ben McGinnes <ben@adversary.org> wrote:

> Sure, how many current OS X bugs have already been reported and which
> ones are they?

Approximately these ones:
https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Amacos;include=subject%3Aosx;package=emacs

>  I also want to be sure I'm not simply duplicating
> existing reported bugs.

Too late! You already reported it by sending it here. ;)

>  Nor do I know how pressing the release date for version
> 26 is, if it's even locked in at all.

AFAIK, there's no firm date, but emacs-26 is in feature freeze and
only taking very safe/urgent bug fixes. So it's possible these bugs
won't be fixed until after 26.1

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Tue, Feb 06, 2018 at 08:33:31PM -0500, Noam Postavsky wrote:
> On Tue, Feb 6, 2018 at 7:43 PM, Ben McGinnes <ben@adversary.org> wrote:
> 
> > Sure, how many current OS X bugs have already been reported and which
> > ones are they?
> 
> Approximately these ones:
> https://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Amacos;include=subject%3Aosx;package=emacs

Cheers.

>>  I also want to be sure I'm not simply duplicating existing
>> reported bugs.
> 
> Too late! You already reported it by sending it here. ;)

Heh.  Of course ...

>>  Nor do I know how pressing the release date for version 26 is, if
>> it's even locked in at all.
> 
> AFAIK, there's no firm date, but emacs-26 is in feature freeze and
> only taking very safe/urgent bug fixes. So it's possible these bugs
> won't be fixed until after 26.1

I think I could make a very convincing argument regarding the modifier
keys here being urgent.  If it was only rendering the hyper key
useless, then maybe you could argue it as not being urgent, but it's
not merely that ... any attempt to assign the hyper function to any
other key (e.g. right alt), just adds the hyper function instead of
replacing the previous function with that.  So if left alt is meta and
you set right alt as hyper, it just becomes a combined hyper-meta.
It's no longer possible to set the hyper key on its own.

Which means the code commentary about changing the nil to none for all
those ns modifier keys is, in fact, completely wrong.  You *do* want nil
there because if you're re-assigning the key to perform another task
you actually do want to clear the original setting out of it.

As for a stable fix, that's dead simple, roll back everything from the
2016 commit that was merged into master on the 5th and it's done.

Anyway, I've got to wander off to one of those other pressing things
and since it involves a wee small hospital visit, it takes priority.
I'll try to take another look at this beast a little later.


Regards,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 6 Feb 2018 15:28:19 -0800
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On 02/06/2018 09:30 AM, Noam Postavsky wrote:
> > on w32 I get an assertion failure, patch attached.
> 
> On Fedora 27 x86-64 I get a crash when running 'emacs 
> --no-build-details'. There are several places in the Emacs code that 
> crash when Fsystem_name returns a non-string. Proposed patch attached.

LGTM, thanks.

Re: Emacs 26 MacOS bugs

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Tue, 6 Feb 2018 12:30:06 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Tue, Feb 6, 2018 at 9:49 AM, Richard Stallman <rms@gnu.org> wrote:
> 
> > - - (p 510) - "--no-build-details" returns:
> >        Wrong type argument: stringp, nil
> 
> Not sure about macOS, but on w32 I get an assertion failure, patch attached.

LGTM, thanks.

Re: Emacs 26 MacOS bugs

[Alan Third]

On Tue, Feb 06, 2018 at 03:30:37PM -0500, Noam Postavsky wrote:
> 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.)
> 
> --- i/lisp/term/ns-win.el
> +++ w/lisp/term/ns-win.el
> @@ -834,7 +834,7 @@ ns-initialized
>              (format "Creation of the standard fontset failed: %s" err)
>              :error)))
> 
> -  (x-open-connection (system-name) x-command-line-resources t)
> +  (x-open-connection (or (system-name) "") x-command-line-resources t)
> 
>    ;; Add GNUstep menu items Services, Hide and Quit.  Rename Help to Info
>    ;; and put it first (i.e. omit from menu-bar-final-items.

That fixes it here.
-- 
Alan Third

Re: Emacs 26 MacOS bugs

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]

On Wed, Feb 07, 2018 at 01:13:01PM +1100, Ben McGinnes wrote:
> On Tue, Feb 06, 2018 at 08:33:31PM -0500, Noam Postavsky wrote:
> > AFAIK, there's no firm date, but emacs-26 is in feature freeze and
> > only taking very safe/urgent bug fixes. So it's possible these bugs
> > won't be fixed until after 26.1
> 
> I think I could make a very convincing argument regarding the modifier
> keys here being urgent.  If it was only rendering the hyper key
> useless, then maybe you could argue it as not being urgent, but it's
> not merely that ...

The good news is that the patch that affects the modifier keys isn’t
in Emacs 26, it was pushed to master only.

> any attempt to assign the hyper function to any
> other key (e.g. right alt), just adds the hyper function instead of
> replacing the previous function with that.  So if left alt is meta and
> you set right alt as hyper, it just becomes a combined hyper-meta.
> It's no longer possible to set the hyper key on its own.
> 
> Which means the code commentary about changing the nil to none for all
> those ns modifier keys is, in fact, completely wrong.  You *do* want nil
> there because if you're re-assigning the key to perform another task
> you actually do want to clear the original setting out of it.
> 
> As for a stable fix, that's dead simple, roll back everything from the
> 2016 commit that was merged into master on the 5th and it's done.

I know you think there was nothing wrong with the old code, but it was
broken in various ways that weren’t obvious how to fix. The new code
should behave more consistently, once we clear up the bugs you’ve
found.

Can you please try the attached patch?

Philipp, it seems that EV_MODIFIERS2 was quite, quite broken. I’ve
split it into various parts and tried to fix it.

Additionally the fn key has some strange interactions with ‘function’
keys, like the Fx keys, arrows, tab and so on. The old code simply
didn’t set its modifier when those keys were used, so I’ve followed
that lead and am XORing it out of emacs_event->modifiers.
-- 
Alan Third

[-- Attachment #2: 0001-Fix-modifier-keys-on-NS-port.patch --]
[-- Type: text/plain, Size: 6472 bytes --]

From b089831704c91fbd0bf0baa45ba6f0c78cf06e41 Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Wed, 7 Feb 2018 22:39:17 +0000
Subject: [PATCH] Fix modifier keys on NS port

* src/nsterm.m (EV_MODIFIERS_OPTION):
(EV_MODIFIERS_CONTROL):
(EV_MODIFIERS_COMMAND): New macros.
(EV_MODIFIERS2): Split out into new macros to make it easier to
understand.
(EmacsView::keyDown): Remove duplicate functionality and handle fn key
correctly.
---
 src/nsterm.m | 83 ++++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 47 insertions(+), 36 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index b7f5a32c09..58ebca4153 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -352,31 +352,45 @@ - (NSColor *)colorUsingDefaultColorSpace
 #define NSRightCommandKeyMask   (0x000010 | NSEventModifierFlagCommand)
 #define NSLeftAlternateKeyMask  (0x000020 | NSEventModifierFlagOption)
 #define NSRightAlternateKeyMask (0x000040 | NSEventModifierFlagOption)
-#define EV_MODIFIERS2(flags)                          \
-    (((flags & NSEventModifierFlagHelp) ?           \
-           hyper_modifier : 0)                        \
-     | (!EQ (ns_right_alternate_modifier, Qleft) && \
-        ((flags & NSRightAlternateKeyMask) \
-         == NSRightAlternateKeyMask) ? \
-           parse_solitary_modifier (ns_right_alternate_modifier) : 0) \
-     | ((flags & NSEventModifierFlagOption) ?                 \
-           parse_solitary_modifier (ns_alternate_modifier) : 0)   \
-     | ((flags & NSEventModifierFlagShift) ?     \
-           shift_modifier : 0)                        \
-     | (!EQ (ns_right_control_modifier, Qleft) && \
-        ((flags & NSRightControlKeyMask) \
-         == NSRightControlKeyMask) ? \
-           parse_solitary_modifier (ns_right_control_modifier) : 0) \
-     | ((flags & NSEventModifierFlagControl) ?      \
-           parse_solitary_modifier (ns_control_modifier) : 0)     \
-     | ((flags & NS_FUNCTION_KEY_MASK) ?  \
-           parse_solitary_modifier (ns_function_modifier) : 0)    \
-     | (!EQ (ns_right_command_modifier, Qleft) && \
-        ((flags & NSRightCommandKeyMask) \
-         == NSRightCommandKeyMask) ? \
-           parse_solitary_modifier (ns_right_command_modifier) : 0) \
-     | ((flags & NSEventModifierFlagCommand) ?      \
-           parse_solitary_modifier (ns_command_modifier):0))
+
+#define EV_MODIFIERS_OPTION(flags)                                      \
+  (((flags & NSRightAlternateKeyMask) == NSRightAlternateKeyMask &&     \
+    ! EQ (ns_right_alternate_modifier, Qleft)) ?                        \
+   parse_solitary_modifier (ns_right_alternate_modifier) : 0)           \
+  | (((flags & NSLeftAlternateKeyMask) == NSLeftAlternateKeyMask ||     \
+      (flags & NSRightAlternateKeyMask) == NSRightAlternateKeyMask &&   \
+      EQ (ns_right_alternate_modifier, Qleft)) ?                        \
+     parse_solitary_modifier (ns_alternate_modifier) : 0)
+
+#define EV_MODIFIERS_CONTROL(flags)                                   \
+  (((flags & NSRightControlKeyMask) == NSRightControlKeyMask &&       \
+    ! EQ (ns_right_control_modifier, Qleft)) ?                        \
+   parse_solitary_modifier (ns_right_control_modifier) : 0)           \
+  | (((flags & NSLeftControlKeyMask) == NSLeftControlKeyMask ||       \
+      (flags & NSRightControlKeyMask) == NSRightControlKeyMask &&     \
+      EQ (ns_right_control_modifier, Qleft)) ?                        \
+     parse_solitary_modifier (ns_control_modifier) : 0)
+
+#define EV_MODIFIERS_COMMAND(flags)                                     \
+  (((flags & NSRightCommandKeyMask) == NSRightCommandKeyMask &&         \
+    ! EQ (ns_right_command_modifier, Qleft)) ?                          \
+   parse_solitary_modifier (ns_right_command_modifier) : 0)             \
+  | (((flags & NSLeftCommandKeyMask) == NSLeftCommandKeyMask ||         \
+      (flags & NSRightCommandKeyMask) == NSRightCommandKeyMask &&       \
+      EQ (ns_right_command_modifier, Qleft)) ?                          \
+     parse_solitary_modifier (ns_command_modifier) : 0)
+
+#define EV_MODIFIERS2(flags)                                            \
+  (((flags & NSEventModifierFlagHelp) ?                                 \
+    hyper_modifier : 0)                                                 \
+   | ((flags & NSEventModifierFlagShift) ?                              \
+      shift_modifier : 0)                                               \
+   | ((flags & NS_FUNCTION_KEY_MASK) ?                                  \
+      parse_solitary_modifier (ns_function_modifier) : 0)               \
+   | EV_MODIFIERS_OPTION (flags)                                        \
+   | EV_MODIFIERS_CONTROL (flags)                                       \
+   | EV_MODIFIERS_COMMAND (flags))
+
 #define EV_MODIFIERS(e) EV_MODIFIERS2 ([e modifierFlags])
 
 #define EV_UDMODIFIERS(e)                                      \
@@ -6130,15 +6144,6 @@ flag set (this is probably a bug in the OS).
             code = fnKeysym;
         }
 
-      /* are there modifiers? */
-      emacs_event->modifiers = 0;
-
-      if (flags & NSEventModifierFlagHelp)
-          emacs_event->modifiers |= hyper_modifier;
-
-      if (flags & NSEventModifierFlagShift)
-        emacs_event->modifiers |= shift_modifier;
-
       /* The ⌘ and ⌥ modifiers can be either shift-like (for alternate
          character input) or control-like (as command prefix).  If we
          have only shift-like modifiers, then we should use the
@@ -6155,8 +6160,14 @@ untranslated characters (returned by the
          modifier keys, which returns 0 for shift-like modifiers.
          Therefore its return value is the set of control-like
          modifiers.  */
-      unsigned int control_modifiers = EV_MODIFIERS2 (flags);
-      emacs_event->modifiers |= control_modifiers;
+      emacs_event->modifiers = EV_MODIFIERS2 (flags);
+
+      /* Function keys (such as the F-keys, arrow keys, etc.) behave
+         as though the fn key has been pressed even when it hasn't.
+         We need to unset the fn modifier if one of these keys is
+         pressed.  FIXME: Avoid setting it in the first place.  */
+      if (fnKeysym && (flags & NS_FUNCTION_KEY_MASK))
+        emacs_event->modifiers ^= parse_solitary_modifier (ns_function_modifier);
 
       if (NS_KEYLOG)
         fprintf (stderr, "keyDown: code =%x\tfnKey =%x\tflags = %x\tmods = %x\n",
-- 
2.16.1

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 4302 bytes --]

On Wed, Feb 07, 2018 at 10:55:05PM +0000, Alan Third wrote:
> On Wed, Feb 07, 2018 at 01:13:01PM +1100, Ben McGinnes wrote:
> > On Tue, Feb 06, 2018 at 08:33:31PM -0500, Noam Postavsky wrote:
> > > AFAIK, there's no firm date, but emacs-26 is in feature freeze and
> > > only taking very safe/urgent bug fixes. So it's possible these bugs
> > > won't be fixed until after 26.1
> > 
> > I think I could make a very convincing argument regarding the modifier
> > keys here being urgent.  If it was only rendering the hyper key
> > useless, then maybe you could argue it as not being urgent, but it's
> > not merely that ...
> 
> The good news is that the patch that affects the modifier keys isn’t
> in Emacs 26, it was pushed to master only.

That's good, though it does mean I need to clarify something:

When the commit log says something like "Merge from origin/emacs-26" I
should take that to mean not really emacs-26 at all?  Possibly not
from origin either, right?

Because I'm fairly sure most people with moderate (or greater)
familiarity with git would assume that was another standard citation
of $default_remote_alias/$branch_name.  If this project is using that
nomenclature differently, that sounds like a fairly important thing to
add to the CONTRIBUTE file.

>> As for a stable fix, that's dead simple, roll back everything from
>> the 2016 commit that was merged into master on the 5th and it's
>> done.
> 
> I know you think there was nothing wrong with the old code,

I wouldn't go that far, but I figured reverting could only result in
things not being more broken and/or bizarre than previously; as
opposed to what that patch did.

> but it was broken in various ways that weren’t obvious how to
> fix. The new code should behave more consistently, once we clear up
> the bugs you’ve found.
> 
> Can you please try the attached patch?

Yeah, I'll have to try it in a couple of days or so, I'm on the road
at the moment.

> Philipp, it seems that EV_MODIFIERS2 was quite, quite broken. I’ve
> split it into various parts and tried to fix it.
> 
> Additionally the fn key has some strange interactions with ‘function’
> keys, like the Fx keys, arrows, tab and so on. The old code simply
> didn’t set its modifier when those keys were used, so I’ve followed
> that lead and am XORing it out of emacs_event->modifiers.

Both Fn and the Command key will generally do that, but the extent of
it is somewhat customisable to an extent.  It depends on which version
of OS X is used, which programs are used to modify key maps or
functions and some system preferences.

So I'm running OS X 10.9.x along with Karibiner and Seil to modify
various key functions (apparently those 2 projects have merged and
been renamed for more recent versions of OS X).

Both my Command keys are configured as super keys, but if there's a
key sequence for OS X, then it'll take priority (I've already
reconfigured the default quit for OS X to be Command+Q+W because
Command+Q got me in enough trouble without even including Emacs in the
mix).  This means some sequences are either pre-configured with
various ns- functions or have been re-configured to point to 'nil and
a comment to remind myself not to touch it.

Whereas the Fn key is set to hyper and will be that with everything
except the Fx keys.  All those keys are configured to be themselves
primarily and whatever their OS/multimedia function is as the
alternative via Fn.  This also helps since I've got F1-F19 instead of
F1-F12.

Simple enough, but the only real "gotcha" with Fn is Karibiner also
includes a deceptive option to "turn the Fn key into a hyper key" and
this can definitely cause problems because the Karibiner
interpretation of a hyper key is what I've taken to calling a
non-hyper sequence.  When it's activated it won't produce "H-"
bindings, it produces "C-M-S-s-" bindings (sometimes that appears to
be "C-M-S-s-" in the "C-h k" lookups, but "C-M-s-" when actually
used).

Still, all of these things continue to report standard key events in
hexadecimal so at the end of the day, if you can detect that then you
should be able to configure these things any way you please.


Regards,
Ben

P.S.  Great domain name.  ;)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Fri, Feb 9, 2018 at 11:35 AM, Ben McGinnes <ben@adversary.org> wrote:

>> The good news is that the patch that affects the modifier keys isn’t
>> in Emacs 26, it was pushed to master only.
>
> That's good, though it does mean I need to clarify something:
>
> When the commit log says something like "Merge from origin/emacs-26" I
> should take that to mean not really emacs-26 at all?

Perhaps you're looking at the wrong side of the merge?

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]

On Fri, Feb 09, 2018 at 11:57:33AM -0500, Noam Postavsky wrote:
> On Fri, Feb 9, 2018 at 11:35 AM, Ben McGinnes <ben@adversary.org> wrote:
> 
>> When the commit log says something like "Merge from origin/emacs-26" I
>> should take that to mean not really emacs-26 at all?
> 
> Perhaps you're looking at the wrong side of the merge?

I suppose that could be the case, but from my POV I see:

commit 5c414441ed73f1a302a2953dc493e83b98589262 (HEAD -> master, origin/master, origin/HEAD)

Preceded by:

commit 8e42b1bd3c8ba1757c150149f0d21eabd9245dcc

Preceded by the commit I've been referring to:

commit a0c7157a16481b0523ad20cda9115f9435188f73
Merge: c24c5dc4a4 c787a49682

Which means the answer lies in what it is my local copy thinks origin
is and what master and/or HEAD are:

nefarious:gnu-emacs ben$ git remote -v
origin	git://git.sv.gnu.org/emacs.git (fetch)
origin	git://git.sv.gnu.org/emacs.git (push)
nefarious:gnu-emacs ben$ git branch -l
  emacs-25
  emacs-26
* master
nefarious:gnu-emacs ben$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
nefarious:gnu-emacs ben$

Although another fetch proved that last part wrong, of course.


Regards,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

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.

[a0c7157]: 2018-02-05 07:50:22 -0800
  Merge from origin/emacs-26
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a0c7157a16481b0523ad20cda9115f9435188f73

[8fbf285]: 2018-02-04 20:44:45 +0100
  Fix handling of modifier keys on macOS
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8fbf28536ee1169f59206523e2af050916befbf6

[p1]: https://git.savannah.gnu.org/cgit/emacs.git/diff/?id=a0c7157a16481b0523ad20cda9115f9435188f73&id2=c24c5dc4a4cc18e7f1ec949efcfe1d4bae541d02
[p2]: https://git.savannah.gnu.org/cgit/emacs.git/diff/?id=a0c7157a16481b0523ad20cda9115f9435188f73&id2=c787a4968273027960a20ced6d63bae0d1ffa87e

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- 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 --]

Re: Emacs 26 MacOS bugs

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

On Sat, Feb 10, 2018 at 03:35:12AM +1100, Ben McGinnes wrote:
> > Can you please try the attached patch?
> 
> Yeah, I'll have to try it in a couple of days or so, I'm on the road
> at the moment.

Please ignore that last patch and test the one attached to this email.
I discovered a whole other range of problems when I tried building
against GNUstep.

-- 
Alan Third

[-- Attachment #2: v2-0001-Fix-modifier-keys-on-NS-port.patch --]
[-- Type: text/plain, Size: 6562 bytes --]

From 776cd862aa7686e3e72db190c2116b0bf946ca7e Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Wed, 7 Feb 2018 22:39:17 +0000
Subject: [PATCH v2] Fix modifier keys on NS port

* src/nsterm.m (EV_MODIFIERS_OPTION):
(EV_MODIFIERS_CONTROL):
(EV_MODIFIERS_COMMAND): New macros.
(ev_modifiers_helper): New function.
(EV_MODIFIERS2): Use new helper function.
(EmacsView::keyDown): Remove duplicate functionality and handle fn key
correctly.
---
 src/nsterm.m | 94 +++++++++++++++++++++++++++++++++++++-----------------------
 1 file changed, 58 insertions(+), 36 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index b7f5a32c09..f017d8d152 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -352,31 +352,56 @@ - (NSColor *)colorUsingDefaultColorSpace
 #define NSRightCommandKeyMask   (0x000010 | NSEventModifierFlagCommand)
 #define NSLeftAlternateKeyMask  (0x000020 | NSEventModifierFlagOption)
 #define NSRightAlternateKeyMask (0x000040 | NSEventModifierFlagOption)
-#define EV_MODIFIERS2(flags)                          \
-    (((flags & NSEventModifierFlagHelp) ?           \
-           hyper_modifier : 0)                        \
-     | (!EQ (ns_right_alternate_modifier, Qleft) && \
-        ((flags & NSRightAlternateKeyMask) \
-         == NSRightAlternateKeyMask) ? \
-           parse_solitary_modifier (ns_right_alternate_modifier) : 0) \
-     | ((flags & NSEventModifierFlagOption) ?                 \
-           parse_solitary_modifier (ns_alternate_modifier) : 0)   \
-     | ((flags & NSEventModifierFlagShift) ?     \
-           shift_modifier : 0)                        \
-     | (!EQ (ns_right_control_modifier, Qleft) && \
-        ((flags & NSRightControlKeyMask) \
-         == NSRightControlKeyMask) ? \
-           parse_solitary_modifier (ns_right_control_modifier) : 0) \
-     | ((flags & NSEventModifierFlagControl) ?      \
-           parse_solitary_modifier (ns_control_modifier) : 0)     \
-     | ((flags & NS_FUNCTION_KEY_MASK) ?  \
-           parse_solitary_modifier (ns_function_modifier) : 0)    \
-     | (!EQ (ns_right_command_modifier, Qleft) && \
-        ((flags & NSRightCommandKeyMask) \
-         == NSRightCommandKeyMask) ? \
-           parse_solitary_modifier (ns_right_command_modifier) : 0) \
-     | ((flags & NSEventModifierFlagCommand) ?      \
-           parse_solitary_modifier (ns_command_modifier):0))
+
+static unsigned int
+ev_modifiers_helper (unsigned int flags, unsigned int left_mask,
+                     unsigned int right_mask, unsigned int either_mask,
+                     Lisp_Object left_modifier, Lisp_Object right_modifier)
+{
+  unsigned int modifiers = 0;
+
+  if (flags & either_mask)
+    {
+      BOOL left_key = (flags & left_mask) == left_mask;
+      BOOL right_key = (flags & right_mask) == right_mask
+        && ! EQ (right_modifier, Qleft);
+
+      if (right_key)
+        modifiers |= parse_solitary_modifier (right_modifier);
+
+      /* GNUstep (and possibly macOS in certain circumstances) doesn't
+         differentiate between the left and right keys, so if we can't
+         identify which key it is, we use the left key setting.  */
+      if (left_key || ! right_key)
+        modifiers |= parse_solitary_modifier (left_modifier);
+    }
+
+  return modifiers;
+}
+
+#define EV_MODIFIERS2(flags)                                            \
+  (((flags & NSEventModifierFlagHelp) ?                                 \
+    hyper_modifier : 0)                                                 \
+   | ((flags & NSEventModifierFlagShift) ?                              \
+      shift_modifier : 0)                                               \
+   | ((flags & NS_FUNCTION_KEY_MASK) ?                                  \
+      parse_solitary_modifier (ns_function_modifier) : 0)               \
+   | ev_modifiers_helper (flags, NSLeftControlKeyMask,                  \
+                          NSRightControlKeyMask,                        \
+                          NSEventModifierFlagControl,                   \
+                          ns_control_modifier,                          \
+                          ns_right_control_modifier)                    \
+   | ev_modifiers_helper (flags, NSLeftCommandKeyMask,                  \
+                          NSRightCommandKeyMask,                        \
+                          NSEventModifierFlagCommand,                   \
+                          ns_command_modifier,                          \
+                          ns_right_command_modifier)                    \
+   | ev_modifiers_helper (flags, NSLeftAlternateKeyMask,                \
+                          NSRightAlternateKeyMask,                      \
+                          NSEventModifierFlagOption,                    \
+                          ns_alternate_modifier,                        \
+                          ns_right_alternate_modifier))
+
 #define EV_MODIFIERS(e) EV_MODIFIERS2 ([e modifierFlags])
 
 #define EV_UDMODIFIERS(e)                                      \
@@ -6130,15 +6155,6 @@ flag set (this is probably a bug in the OS).
             code = fnKeysym;
         }
 
-      /* are there modifiers? */
-      emacs_event->modifiers = 0;
-
-      if (flags & NSEventModifierFlagHelp)
-          emacs_event->modifiers |= hyper_modifier;
-
-      if (flags & NSEventModifierFlagShift)
-        emacs_event->modifiers |= shift_modifier;
-
       /* The ⌘ and ⌥ modifiers can be either shift-like (for alternate
          character input) or control-like (as command prefix).  If we
          have only shift-like modifiers, then we should use the
@@ -6155,8 +6171,14 @@ untranslated characters (returned by the
          modifier keys, which returns 0 for shift-like modifiers.
          Therefore its return value is the set of control-like
          modifiers.  */
-      unsigned int control_modifiers = EV_MODIFIERS2 (flags);
-      emacs_event->modifiers |= control_modifiers;
+      emacs_event->modifiers = EV_MODIFIERS2 (flags);
+
+      /* Function keys (such as the F-keys, arrow keys, etc.) behave
+         as though the fn key has been pressed even when it hasn't.
+         We need to unset the fn modifier if one of these keys is
+         pressed.  FIXME: Avoid setting it in the first place.  */
+      if (fnKeysym && (flags & NS_FUNCTION_KEY_MASK))
+        emacs_event->modifiers ^= parse_solitary_modifier (ns_function_modifier);
 
       if (NS_KEYLOG)
         fprintf (stderr, "keyDown: code =%x\tfnKey =%x\tflags = %x\tmods = %x\n",
-- 
2.16.1

Re: Emacs 26 MacOS bugs

[Uwe Brauer]

>>> "Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:

   > On 02/06/2018 09:30 AM, Noam Postavsky wrote:
   >> on w32 I get an assertion failure, patch attached.

   > On Fedora 27 x86-64 I get a crash when running 'emacs
   > --no-build-details'. There are several places in the Emacs code that
   > crash when Fsystem_name returns a non-string. Proposed patch attached.

I can confirm the crash for Ubuntu 16.04 (64) 

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2018-01-25 built on Utnapischtim
Repository revision: a84c3810b56f7bd56d455dfa8962f2e4653ce490
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 16.04.3 LTS

Re: Emacs 26 MacOS bugs

[Alan Third]

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

This fixes it for me.
-- 
Alan Third

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Sat, Feb 10, 2018 at 9:55 AM, Uwe Brauer <oub@mat.ucm.es> wrote:
>>>> "Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:
>
>    > On 02/06/2018 09:30 AM, Noam Postavsky wrote:
>    >> on w32 I get an assertion failure, patch attached.
>
>    > On Fedora 27 x86-64 I get a crash when running 'emacs
>    > --no-build-details'. There are several places in the Emacs code that
>    > crash when Fsystem_name returns a non-string. Proposed patch attached.
>
> I can confirm the crash for Ubuntu 16.04 (64)
>
> In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2018-01-25 built on Utnapischtim
> Repository revision: a84c3810b56f7bd56d455dfa8962f2e4653ce490

The --no-build-details should be fixed in all platforms on emacs-26 as
of Feb 8th [1: 19fa6d561a], and on master as of the 9th [3:
875cb835f0].
The --title=title bug for macOS is still outstanding (I don't see that
problem on GNU/Linux, or w32).

[1: 19fa6d561a]: 2018-02-08 19:10:11 -0500
  Fix --no-build-details for w32 and macOS
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=19fa6d561abd91e9ad71a6799c5ed4f582c9f351

[2: c2727e3c40]: 2018-02-08 09:31:20 -0800
  Fix crashes when run with --no-build-details
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c2727e3c40bcafdc7c32b3f02b78e6cbe87e1647

[3: 875cb835f0]: 2018-02-09 11:12:48 -0800
  Merge from origin/emacs-26
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=875cb835f00260d58c536b3a3f7c0343fd5f28dc

Re: Emacs 26 MacOS bugs

[Alan Third]

On Tue, Feb 06, 2018 at 09:49:16AM -0500, Richard Stallman wrote:
> C.10 :
> - - (p 520) neither -T=title nor --title=title appear to work on macOS
> (Sierra), although --name=title does.

I believe this is caused by the way macOS handles filenames in the
titlebar.

It’s possible it can be fixed, but I don’t really understand the
reasons behind it.
-- 
Alan Third

Re: Emacs 26 MacOS bugs

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Sat, Feb 10, 2018 at 10:45:16PM +0000, Alan Third wrote:
> On Tue, Feb 06, 2018 at 09:49:16AM -0500, Richard Stallman wrote:
> > C.10 :
> > - - (p 520) neither -T=title nor --title=title appear to work on macOS
> > (Sierra), although --name=title does.
> 
> I believe this is caused by the way macOS handles filenames in the
> titlebar.

Fix attached. It seems to work for me, but I only learned today that
the macOS ‘proxy icon’ is anything other than just an icon, so if it
breaks anything subtle I probably wouldn’t notice.
-- 
Alan Third

[-- Attachment #2: 0001-Remove-NS-special-handling-of-frame-title-format.patch --]
[-- Type: text/plain, Size: 7011 bytes --]

From c89bfa7e6fc634a6da01ca37abb9e726bea83c3b Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sun, 11 Feb 2018 11:34:49 +0000
Subject: [PATCH] Remove NS special handling of 'frame-title-format'

* lisp/term/ns-win.el (frame-title-format, icon-title-format): Change
default format to just the filename.
* src/nsfns.m (ns-use-proxy-icon): New variable.
(ns_set_name_as_filename): Remove function.
(x_implicitly_set_name): Get rid of special handling of
frame-title-format.
* src/nsterm.h (ns_set_represented_filename): Use new definition.
* src/nsterm.m (ns_set_represented_filename): Move some of the logic
from ns_set_name_as_filename into this function.
---
 etc/NEWS            |  5 +++
 lisp/term/ns-win.el |  4 +--
 src/nsfns.m         | 91 +++++------------------------------------------------
 src/nsterm.h        |  2 +-
 src/nsterm.m        | 30 +++++++++++++++++-
 5 files changed, 45 insertions(+), 87 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index 8fed15af5b..005f177a27 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -289,6 +289,11 @@ Previously it was supported only in the Cygwin-w32 build.
 ** Emacs now handles key combinations involving the macOS "command"
 and "option" modifier keys more correctly.
 
+** The special handling of `frame-title-format' on NS where setting it
+to `t' would enable the macOS proxy icon has been replaced with a
+separate variable, `ns-use-proxy-icon'. `frame-title-format' will now
+work as on other platforms.
+
 \f
 ----------------------------------------------------------------------
 This file is part of GNU Emacs.
diff --git a/lisp/term/ns-win.el b/lisp/term/ns-win.el
index eab95e02d8..ea9991ba36 100644
--- a/lisp/term/ns-win.el
+++ b/lisp/term/ns-win.el
@@ -807,8 +807,8 @@ ns-suspend-error
 
 
 ;; Set some options to be as Nextstep-like as possible.
-(setq frame-title-format t
-      icon-title-format t)
+(setq frame-title-format "%b"
+      icon-title-format "%b")
 
 
 (defvar ns-initialized nil
diff --git a/src/nsfns.m b/src/nsfns.m
index 0f60bb8107..bbb6644ce0 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -61,7 +61,6 @@ Updated by Christian Limpach (chris@nice.ch)
 static ptrdiff_t image_cache_refcount;
 
 static struct ns_display_info *ns_display_info_for_name (Lisp_Object);
-static void ns_set_name_as_filename (struct frame *);
 
 /* ==========================================================================
 
@@ -483,17 +482,10 @@ Turn the input menu (an NSMenu) into a lisp list for tracking on lisp side
 {
   NSTRACE ("x_implicitly_set_name");
 
-  Lisp_Object frame_title = buffer_local_value
-    (Qframe_title_format, XWINDOW (f->selected_window)->contents);
-  Lisp_Object icon_title = buffer_local_value
-    (Qicon_title_format, XWINDOW (f->selected_window)->contents);
+  if (! NILP (ns_use_proxy_icon))
+    ns_set_represented_filename (f);
 
-  /* Deal with NS specific format t.  */
-  if (FRAME_NS_P (f) && ((FRAME_ICONIFIED_P (f) && EQ (icon_title, Qt))
-                         || EQ (frame_title, Qt)))
-    ns_set_name_as_filename (f);
-  else
-    ns_set_name (f, arg, 0);
+  ns_set_name (f, arg, 0);
 }
 
 
@@ -520,78 +512,6 @@ Turn the input menu (an NSMenu) into a lisp list for tracking on lisp side
   ns_set_name_internal (f, name);
 }
 
-
-static void
-ns_set_name_as_filename (struct frame *f)
-{
-  NSView *view;
-  Lisp_Object name, filename;
-  Lisp_Object buf = XWINDOW (f->selected_window)->contents;
-  const char *title;
-  NSAutoreleasePool *pool;
-  Lisp_Object encoded_name, encoded_filename;
-  NSString *str;
-  NSTRACE ("ns_set_name_as_filename");
-
-  if (f->explicit_name || ! NILP (f->title))
-    return;
-
-  block_input ();
-  pool = [[NSAutoreleasePool alloc] init];
-  filename = BVAR (XBUFFER (buf), filename);
-  name = BVAR (XBUFFER (buf), name);
-
-  if (NILP (name))
-    {
-      if (! NILP (filename))
-        name = Ffile_name_nondirectory (filename);
-      else
-        name = build_string ([ns_app_name UTF8String]);
-    }
-
-  encoded_name = ENCODE_UTF_8 (name);
-
-  view = FRAME_NS_VIEW (f);
-
-  title = FRAME_ICONIFIED_P (f) ? [[[view window] miniwindowTitle] UTF8String]
-                                : [[[view window] title] UTF8String];
-
-  if (title && (! strcmp (title, SSDATA (encoded_name))))
-    {
-      [pool release];
-      unblock_input ();
-      return;
-    }
-
-  str = [NSString stringWithUTF8String: SSDATA (encoded_name)];
-  if (str == nil) str = @"Bad coding";
-
-  if (FRAME_ICONIFIED_P (f))
-    [[view window] setMiniwindowTitle: str];
-  else
-    {
-      NSString *fstr;
-
-      if (! NILP (filename))
-        {
-          encoded_filename = ENCODE_UTF_8 (filename);
-
-          fstr = [NSString stringWithUTF8String: SSDATA (encoded_filename)];
-          if (fstr == nil) fstr = @"";
-        }
-      else
-        fstr = @"";
-
-      ns_set_represented_filename (fstr, f);
-      [[view window] setTitle: str];
-      fset_name (f, name);
-    }
-
-  [pool release];
-  unblock_input ();
-}
-
-
 void
 ns_set_doc_edited (void)
 {
@@ -3311,6 +3231,11 @@ - (NSString *)panel: (id)sender userEnteredFilename: (NSString *)filename
                doc: /* Toolkit version for NS Windowing.  */);
   Vns_version_string = ns_appkit_version_str ();
 
+  DEFVAR_BOOL ("ns-use-proxy-icon", ns_use_proxy_icon,
+               doc: /* When non-nil display a proxy icon in the titlebar.
+Default is t.  */);
+  ns_use_proxy_icon = Qt;
+
   defsubr (&Sns_read_file_name);
   defsubr (&Sns_get_resource);
   defsubr (&Sns_set_resource);
diff --git a/src/nsterm.h b/src/nsterm.h
index cc4c6d5e91..8b985930ec 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -1237,7 +1237,7 @@ extern void ns_finish_events (void);
 #ifdef __OBJC__
 /* Needed in nsfns.m.  */
 extern void
-ns_set_represented_filename (NSString *fstr, struct frame *f);
+ns_set_represented_filename (struct frame *f);
 
 #endif
 
diff --git a/src/nsterm.m b/src/nsterm.m
index f017d8d152..c694544b07 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -469,10 +469,38 @@ - (NSColor *)colorUsingDefaultColorSpace
    ========================================================================== */
 
 void
-ns_set_represented_filename (NSString *fstr, struct frame *f)
+ns_set_represented_filename (struct frame *f)
 {
+  NSView *view;
+  Lisp_Object filename, encoded_filename;
+  Lisp_Object buf = XWINDOW (f->selected_window)->contents;
+  NSAutoreleasePool *pool;
+  NSString *fstr;
+
+  NSTRACE ("ns_set_represented_filename");
+
+  if (f->explicit_name || ! NILP (f->title))
+    return;
+
+  block_input ();
+  pool = [[NSAutoreleasePool alloc] init];
+  filename = BVAR (XBUFFER (buf), filename);
+
+  if (! NILP (filename))
+    {
+      encoded_filename = ENCODE_UTF_8 (filename);
+
+      fstr = [NSString stringWithUTF8String: SSDATA (encoded_filename)];
+      if (fstr == nil) fstr = @"";
+    }
+  else
+    fstr = @"";
+
   represented_filename = [fstr retain];
   represented_frame = f;
+
+  [pool release];
+  unblock_input ();
 }
 
 void
-- 
2.16.1

Re: Emacs 26 MacOS bugs

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Alan Third <alan@idiocy.org> schrieb am Mi., 7. Feb. 2018 um 23:55 Uhr:

> On Wed, Feb 07, 2018 at 01:13:01PM +1100, Ben McGinnes wrote:
>
> Philipp, it seems that EV_MODIFIERS2 was quite, quite broken. I’ve
> split it into various parts and tried to fix it.
>
> Additionally the fn key has some strange interactions with ‘function’
> keys, like the Fx keys, arrows, tab and so on. The old code simply
> didn’t set its modifier when those keys were used, so I’ve followed
> that lead and am XORing it out of emacs_event->modifiers.
>
>
Sounds good, feel free to install the patch.
Is there some documentation for the strange interactions? If so, please add
it to the comment.

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

Re: Emacs 26 MacOS bugs

[Eli Zaretskii]

> Date: Sun, 11 Feb 2018 11:47:31 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: emacs-devel@gnu.org
> 
> > > - - (p 520) neither -T=title nor --title=title appear to work on macOS
> > > (Sierra), although --name=title does.
> > 
> > I believe this is caused by the way macOS handles filenames in the
> > titlebar.
> 
> Fix attached. It seems to work for me, but I only learned today that
> the macOS ‘proxy icon’ is anything other than just an icon, so if it
> breaks anything subtle I probably wouldn’t notice.

Looks risky for emacs-26, do you agree?  The original problem is quite
old, so I tend to ask you to install this on master.

Thanks.

Re: Emacs 26 MacOS bugs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > C.10 :
  > > - - (p 520) neither -T=title nor --title=title appear to work on macOS
  > > (Sierra), although --name=title does.

  > I believe this is caused by the way macOS handles filenames in the
  > titlebar.

If we don't fix the code, can someone please fix the Emacs 26 manual?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: Emacs 26 MacOS bugs

[Alan Third]

On Sun, Feb 11, 2018 at 05:52:12PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 11 Feb 2018 11:47:31 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> > 
> > Fix attached. It seems to work for me, but I only learned today that
> > the macOS ‘proxy icon’ is anything other than just an icon, so if it
> > breaks anything subtle I probably wouldn’t notice.
> 
> Looks risky for emacs-26, do you agree?  The original problem is quite
> old, so I tend to ask you to install this on master.

Yes, I agree.

Pushed to master.
-- 
Alan Third

Re: Emacs 26 MacOS bugs

[Alan Third]

On Sun, Feb 11, 2018 at 01:53:10PM +0000, Philipp Stephani wrote:
> Alan Third <alan@idiocy.org> schrieb am Mi., 7. Feb. 2018 um 23:55 Uhr:
> 
> > On Wed, Feb 07, 2018 at 01:13:01PM +1100, Ben McGinnes wrote:
> >
> > Philipp, it seems that EV_MODIFIERS2 was quite, quite broken. I’ve
> > split it into various parts and tried to fix it.
> >
> > Additionally the fn key has some strange interactions with ‘function’
> > keys, like the Fx keys, arrows, tab and so on. The old code simply
> > didn’t set its modifier when those keys were used, so I’ve followed
> > that lead and am XORing it out of emacs_event->modifiers.
> >
> >
> Sounds good, feel free to install the patch.
> Is there some documentation for the strange interactions? If so, please add
> it to the comment.

I’ve pushed it to master.

I don’t have any documentation, but I did add a bit more information
to the comment.

Simply put, the system sometimes reports the fn key being pressed at
times when you wouldn’t expect it to, but only when ‘function’ keys
like <F1>, <tab> or <left arrow> are being used.

It also reports the fn key being pressed when you’re using it to turn
something like <left arrow> into <home>. We clearly don’t want that.
(i.e. fn‐<left> gives fn‐<home> instead of just <home>.)
-- 
Alan Third

Re: Emacs 26 MacOS bugs

[Ben McGinnes]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Sun, Feb 11, 2018 at 08:57:13PM +0000, Alan Third wrote:
> On Sun, Feb 11, 2018 at 05:52:12PM +0200, Eli Zaretskii wrote:
>> 
>> Looks risky for emacs-26, do you agree?  The original problem is
>> quite old, so I tend to ask you to install this on master.
> 
> Yes, I agree.
> 
> Pushed to master.

I finally got back to a position where I could do some more work on
this, sorry about the delay.  Anyway, the current code in master up to
commit 1d135af78c3ddd502b5feb84884ea55cbc664753 appears to behave
correctly, including the use of the Fn as hyper key.

I never saw the reported build errors, so I can't determine whether or
not they were fixed.

The only thing left that I'm still seeing as a problem is the ERC+ZNC
connection failures and reconnection infinite loop (which always
requires force quitting the entire Emacs instance).  I'll have to keep
looking into that one, but excellent work on the rest.


Regards,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Emacs 26 MacOS bugs

[Noam Postavsky]

On Tue, Feb 13, 2018 at 2:41 PM, Ben McGinnes <ben@adversary.org> wrote:

> The only thing left that I'm still seeing as a problem is the ERC+ZNC
> connection failures and reconnection infinite loop (which always
> requires force quitting the entire Emacs instance).

This could be Bug#28467.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28467