Subject: bug#44533: 27.1; Mac special key modifiers not functioning as expected

From: Alan Third <[email-masked]>
Date: Tue, 10 Nov 2020 13:11:44 +0000

On Tue, Nov 10, 2020 at 08:09:03PM +0800, YH Tan wrote:
> 
> 
> > On Nov 10, 2020, at 19:11, Alan Third <[email-masked]> wrote:
> > 
> > On Mon, Nov 09, 2020 at 11:23:13PM +0800, YH Tan wrote:
> >> The functioning of certain special key modifiers doesn't seem to work as
> >> expected in 27.1.
> >> 
> >> For example, when I do:
> >> 
> >> (setq mac-left-option-modifier 'nil)
> >            ^^^^
> >> 
> >> nothing happens to the left option key, which retains its meta function. 
> > 
> > You should be using mac-option-modifier, not mac-left-option-modifier.
> 
> This would reset both option keys. I would like to retain meta on the right. 

mac-left-option-modifier has no special function on the NS port of
Emacs. It may on the Mac port, but I don't think so. I recommend you
review the documentation (C-h i m emacs i ns-alternate-modifier).

> > This actually sounds suspiciously like you've remapped fn as option in
> > the system preferences. The fn key has some strange behaviours when
> > used with "control" keys like the arrows.
> > 
> 
> Yes. I do have: 
> 
> (setq mac-function-modifier 'meta)
> 
> which maps function to meta. You mean this can actually interfere
> with the right-option meta key? I’ve been using the same setup for
> previous versions of emacs without problem.

We reworked the keyboard handling for Emacs 27 because there were a
lot of strange behaviours.

I've attached a patch, it's for the master branch but is easily
adapted for Emacs 27.

Assuming this works I'd like to apply it to Emacs 27, but I'm not 100%
sure it won't break anything, so perhaps it's best to put it in master
first and back-port to Emacs 27 when/if we're happy with it.
-- 
Alan Third
>From 8c4ff510a580e2b66e6ed7e6e7f96fcf557429fc Mon Sep 17 00:00:00 2001
From: Alan Third <[email-masked]>
Date: Tue, 10 Nov 2020 12:54:50 +0000
Subject: [PATCH] Fix error with fn key in NS port (bug#44533)

* src/nsterm.m ([EmacsView keyDown:]): Move the correction for fn key
handling to before the modifiers are calculated.
---
 src/nsterm.m | 19 ++++++++-----------
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 4fad521b74..a9280eb4af 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6531,6 +6531,14 @@ flag set (this is probably a bug in the OS).  */
             code = 0xFF08; /* backspace */
           else
             code = fnKeysym;
+
+          /* Function keys (such as the F-keys, arrow keys, etc.) set
+             modifiers as though the fn key has been pressed when it
+             hasn't.  Also some combinations of fn and a function key
+             return a different key than was pressed (e.g. fn-<left>
+             gives <home>).  We need to unset the fn key flag in these
+             cases.  */
+          flags &= ~NS_FUNCTION_KEY_MASK;
         }
 
       /* The ⌘ and ⌥ modifiers can be either shift-like (for alternate
@@ -6552,17 +6560,6 @@ In that case we use UCKeyTranslate (ns_get_shifted_character)
       Lisp_Object kind = fnKeysym ? QCfunction : QCordinary;
       emacs_event->modifiers = EV_MODIFIERS2 (flags, kind);
 
-      /* Function keys (such as the F-keys, arrow keys, etc.) set
-         modifiers as though the fn key has been pressed when it
-         hasn't.  Also some combinations of fn and a function key
-         return a different key than was pressed (e.g. fn-<left> gives
-         <home>).  We need to unset the fn modifier in these cases.
-         FIXME: Can we avoid setting it in the first place?  */
-      if (fnKeysym && (flags & NS_FUNCTION_KEY_MASK))
-        emacs_event->modifiers
-          ^= parse_solitary_modifier (mod_of_kind (ns_function_modifier,
-                                                   QCfunction));
-
       if (NS_KEYLOG)
         fprintf (stderr, "keyDown: code =%x\tfnKey =%x\tflags = %x\tmods = %x\n",
                  code, fnKeysym, flags, emacs_event->modifiers);
-- 
2.26.1