bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Yoichi Nakayama]

I found that bug#55940 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55940)
has not been fixed on Emacs started by "emacs -nw"

(substitute-command-keys "\\[customize]")
#("<ns-show-prefs>" 0 15 (font-lock-face help-key-binding face
help-key-binding))

I think this is because make-non-key-event for ns-* is not called
in this situation.

Tested environment:
GNU Emacs 29.4 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60
Version 12.6.6 (Build 21G646)) of 2024-08-03

-- 
Yoichi NAKAYAMA

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Sat, 30 Nov 2024 16:40:53 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:

    Yoichi> I found that bug#55940 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55940)
    Yoichi> has not been fixed on Emacs started by "emacs -nw"

    Yoichi> (substitute-command-keys "\\[customize]")
    Yoichi> #("<ns-show-prefs>" 0 15 (font-lock-face help-key-binding face
    Yoichi> help-key-binding))

    Yoichi> I think this is because make-non-key-event for ns-* is not called
    Yoichi> in this situation.

Right, but OTOH typical terminal setups donʼt allow you to use super
as a modifier anyway (unless Gerd has a magic recipe). I guess it
couldnʼt do too much harm to call the ns-specific portion of
`x-setup-function-keys' even when not in a graphical frame, but Iʼm
not sure where we could hook that into.

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sat, 30 Nov 2024 16:40:53 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:
>
>     Yoichi> I found that bug#55940 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55940)
>     Yoichi> has not been fixed on Emacs started by "emacs -nw"
>
>     Yoichi> (substitute-command-keys "\\[customize]")
>     Yoichi> #("<ns-show-prefs>" 0 15 (font-lock-face help-key-binding face
>     Yoichi> help-key-binding))
>
>     Yoichi> I think this is because make-non-key-event for ns-* is not called
>     Yoichi> in this situation.
>
> Right, but OTOH typical terminal setups donʼt allow you to use super
> as a modifier anyway (unless Gerd has a magic recipe). I guess it
> couldnʼt do too much harm to call the ns-specific portion of
> `x-setup-function-keys' even when not in a graphical frame, but Iʼm
> not sure where we could hook that into.
>
> Robert

I think I have even 2 magic recipes :-).

1. Use a terminal like iTerm that supports the Kitty Keyboard Protocol,
and use kkp.el in Emacs. Example from my Emacs C-h k Command-M g ives

  s-m runs the command magit-file-dispatch (found in global-map), which
  is an autoloaded interactive native-comp-function in ‘magit-files.el’.

That requires some fiddling with iTerm key settings so that iTerm itself
doesn't use the Command keys one wants to define.

  https://sw.kovidgoyal.net/kitty/keyboard-protocol/
  https://github.com/benjaminor/kkp


2. Use something like Devil

  https://github.com/susam/devil/blob/main/devil.el

In short, that can map input like `. x' to `s-x'. I think there is at
least one other similar package named God, but I haven't tried that.

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Yoichi Nakayama]

> Right, but OTOH typical terminal setups donʼt allow you to use super
> as a modifier anyway (unless Gerd has a magic recipe).

It's not true. We can run commands that use super with "C-x @ s" instead.
I think there is no way to enter ns-*.

On Mon, Dec 2, 2024 at 11:09 PM Robert Pluim <rpluim@gmail.com> wrote:
>
> >>>>> On Sat, 30 Nov 2024 16:40:53 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:
>
>     Yoichi> I found that bug#55940 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55940)
>     Yoichi> has not been fixed on Emacs started by "emacs -nw"
>
>     Yoichi> (substitute-command-keys "\\[customize]")
>     Yoichi> #("<ns-show-prefs>" 0 15 (font-lock-face help-key-binding face
>     Yoichi> help-key-binding))
>
>     Yoichi> I think this is because make-non-key-event for ns-* is not called
>     Yoichi> in this situation.
>
> Right, but OTOH typical terminal setups donʼt allow you to use super
> as a modifier anyway (unless Gerd has a magic recipe). I guess it
> couldnʼt do too much harm to call the ns-specific portion of
> `x-setup-function-keys' even when not in a graphical frame, but Iʼm
> not sure where we could hook that into.
>
> Robert
> --



-- 
Yoichi NAKAYAMA

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Wed, 4 Dec 2024 22:53:43 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:

    >> Right, but OTOH typical terminal setups donʼt allow you to use super
    >> as a modifier anyway (unless Gerd has a magic recipe).

    Yoichi> It's not true. We can run commands that use super with "C-x @ s" instead.
    Yoichi> I think there is no way to enter ns-*.

Thatʼs true, Iʼd forgotten about that.

So calling the right bits of `x-setup-function-keys' would fix this,
but I have no clue where we could call that from. Perhaps we can add a
"term/ns-common.el" and load that from "loadup.el" when (featurep 'ns)
? Except then it would probably end up being called twice when using
GUI emacs on macOS.

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Yoichi Nakayama]

I think it is not necessary to call `x-setup-function-keys` for emacs -nw,
because the docstring says that it is for graphical frames.
Just moving the `make-non-key-event` calls in `x-setup-function-keys` to the
toplevel of term/common-win.el fixes the problem.

On Wed, Dec 4, 2024 at 11:38 PM Robert Pluim <rpluim@gmail.com> wrote:
>
> >>>>> On Wed, 4 Dec 2024 22:53:43 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:
>
>     >> Right, but OTOH typical terminal setups donʼt allow you to use super
>     >> as a modifier anyway (unless Gerd has a magic recipe).
>
>     Yoichi> It's not true. We can run commands that use super with "C-x @ s" instead.
>     Yoichi> I think there is no way to enter ns-*.
>
> Thatʼs true, Iʼd forgotten about that.
>
> So calling the right bits of `x-setup-function-keys' would fix this,
> but I have no clue where we could call that from. Perhaps we can add a
> "term/ns-common.el" and load that from "loadup.el" when (featurep 'ns)
> ? Except then it would probably end up being called twice when using
> GUI emacs on macOS.
>
> Robert
> --



-- 
Yoichi NAKAYAMA

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Fri, 6 Dec 2024 22:46:23 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:

    Yoichi> I think it is not necessary to call `x-setup-function-keys` for emacs -nw,
    Yoichi> because the docstring says that it is for graphical frames.
    Yoichi> Just moving the `make-non-key-event` calls in `x-setup-function-keys` to the
    Yoichi> toplevel of term/common-win.el fixes the problem.

If that works, ok. It does feel a little hacky to just stick stuff at
the toplevel of term/common-win.el. What do the maintainers think?
(would it work to move them to term/ns-win.el instead?)

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  74619@debbugs.gnu.org
> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 06 Dec 2024 16:16:19 +0100
> 
> >>>>> On Fri, 6 Dec 2024 22:46:23 +0900, Yoichi Nakayama <yoichi.nakayama@gmail.com> said:
> 
>     Yoichi> I think it is not necessary to call `x-setup-function-keys` for emacs -nw,
>     Yoichi> because the docstring says that it is for graphical frames.
>     Yoichi> Just moving the `make-non-key-event` calls in `x-setup-function-keys` to the
>     Yoichi> toplevel of term/common-win.el fixes the problem.
> 
> If that works, ok. It does feel a little hacky to just stick stuff at
> the toplevel of term/common-win.el. What do the maintainers think?
> (would it work to move them to term/ns-win.el instead?)

I admit that I don't understand the issue, and not how an NS-specific
problem is solved in common-win.el.  Can you summarize the
discussion's conclusions till now?

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Fri, 06 Dec 2024 18:22:11 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> I admit that I don't understand the issue, and not how an NS-specific
    Eli> problem is solved in common-win.el.  Can you summarize the
    Eli> discussion's conclusions till now?

common-win.el has a definition of `x-setup-function-keys' that does
the appropriate magic with `system-key-alist' to fix this issue. That
code is conditional on (featurep 'ns), and `x-setup-function-keys' is
called when creating a GUI frame on macOS, but not when creating a tty
frame.

So the solution is to somehow perform the magic just when (featurep
'ns), regardless of frame type. One way of doing that is by just
putting it at the toplevel in common-win.el (although putting it at
the toplevel in ns-win.el works as well).

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: yoichi.nakayama@gmail.com,  gerd.moellmann@gmail.com,
>   74619@debbugs.gnu.org
> Date: Fri, 06 Dec 2024 17:53:47 +0100
> 
> >>>>> On Fri, 06 Dec 2024 18:22:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> I admit that I don't understand the issue, and not how an NS-specific
>     Eli> problem is solved in common-win.el.  Can you summarize the
>     Eli> discussion's conclusions till now?
> 
> common-win.el has a definition of `x-setup-function-keys' that does
> the appropriate magic with `system-key-alist' to fix this issue. That
> code is conditional on (featurep 'ns), and `x-setup-function-keys' is
> called when creating a GUI frame on macOS, but not when creating a tty
> frame.
> 
> So the solution is to somehow perform the magic just when (featurep
> 'ns), regardless of frame type. One way of doing that is by just
> putting it at the toplevel in common-win.el (although putting it at
> the toplevel in ns-win.el works as well).

NS specific code should definitely go to ns-win.el.  But is that file
loaded in a -nw session, especially if Emacs is compiled to only
support TTY frames (if that can be done with the NS port)?

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: yoichi.nakayama@gmail.com,  gerd.moellmann@gmail.com,
>>   74619@debbugs.gnu.org
>> Date: Fri, 06 Dec 2024 17:53:47 +0100
>> 
>> >>>>> On Fri, 06 Dec 2024 18:22:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> 
>>     Eli> I admit that I don't understand the issue, and not how an NS-specific
>>     Eli> problem is solved in common-win.el.  Can you summarize the
>>     Eli> discussion's conclusions till now?
>> 
>> common-win.el has a definition of `x-setup-function-keys' that does
>> the appropriate magic with `system-key-alist' to fix this issue. That
>> code is conditional on (featurep 'ns), and `x-setup-function-keys' is
>> called when creating a GUI frame on macOS, but not when creating a tty
>> frame.
>> 
>> So the solution is to somehow perform the magic just when (featurep
>> 'ns), regardless of frame type. One way of doing that is by just
>> putting it at the toplevel in common-win.el (although putting it at
>> the toplevel in ns-win.el works as well).
>
> NS specific code should definitely go to ns-win.el.  But is that file
> loaded in a -nw session, especially if Emacs is compiled to only
> support TTY frames (if that can be done with the NS port)?

I configure --without-ns, and ns-win.el is not loaded in that case.

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Fri, 06 Dec 2024 18:11:10 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:
    >> 
    >> NS specific code should definitely go to ns-win.el.  But is that file
    >> loaded in a -nw session, especially if Emacs is compiled to only
    >> support TTY frames (if that can be done with the NS port)?

Itʼs loaded for me, but my emacs is built with NS support, just run
with "-nw".

    Gerd> I configure --without-ns, and ns-win.el is not loaded in that case.

So (featurep 'ns) is false for you, so the load of term/ns-win in
loadup.el doesnʼt happen.

We could add something like

(if (eq system-type 'darwin)
    (load "term/darwin.el"))

with a new "term/darwin.el" file, I guess (but what about GNUStep?).

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  yoichi.nakayama@gmail.com,
>   74619@debbugs.gnu.org
> Date: Fri, 06 Dec 2024 18:24:26 +0100
> 
>     Gerd> I configure --without-ns, and ns-win.el is not loaded in that case.
> 
> So (featurep 'ns) is false for you, so the load of term/ns-win in
> loadup.el doesnʼt happen.
> 
> We could add something like
> 
> (if (eq system-type 'darwin)
>     (load "term/darwin.el"))
> 
> with a new "term/darwin.el" file, I guess (but what about GNUStep?).

What will be in term/darwin.el?

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Yoichi Nakayama]

> I configure --without-ns, and ns-win.el is not loaded in that case.

If term/ns-win.el is not loaded, no need to call make-non-key-event for ns-".
It is because global-set-key for ns-" is only in term/ns-win.el.

On Sat, Dec 7, 2024 at 2:11 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Robert Pluim <rpluim@gmail.com>
> >> Cc: yoichi.nakayama@gmail.com,  gerd.moellmann@gmail.com,
> >>   74619@debbugs.gnu.org
> >> Date: Fri, 06 Dec 2024 17:53:47 +0100
> >>
> >> >>>>> On Fri, 06 Dec 2024 18:22:11 +0200, Eli Zaretskii <eliz@gnu.org> said:
> >>
> >>     Eli> I admit that I don't understand the issue, and not how an NS-specific
> >>     Eli> problem is solved in common-win.el.  Can you summarize the
> >>     Eli> discussion's conclusions till now?
> >>
> >> common-win.el has a definition of `x-setup-function-keys' that does
> >> the appropriate magic with `system-key-alist' to fix this issue. That
> >> code is conditional on (featurep 'ns), and `x-setup-function-keys' is
> >> called when creating a GUI frame on macOS, but not when creating a tty
> >> frame.
> >>
> >> So the solution is to somehow perform the magic just when (featurep
> >> 'ns), regardless of frame type. One way of doing that is by just
> >> putting it at the toplevel in common-win.el (although putting it at
> >> the toplevel in ns-win.el works as well).
> >
> > NS specific code should definitely go to ns-win.el.  But is that file
> > loaded in a -nw session, especially if Emacs is compiled to only
> > support TTY frames (if that can be done with the NS port)?
>
> I configure --without-ns, and ns-win.el is not loaded in that case.



-- 
Yoichi NAKAYAMA

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Sat, 7 Dec 2024 05:20:42 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>, Robert Pluim <rpluim@gmail.com>, 74619@debbugs.gnu.org
> 
> > I configure --without-ns, and ns-win.el is not loaded in that case.
> 
> If term/ns-win.el is not loaded, no need to call make-non-key-event for ns-".
> It is because global-set-key for ns-" is only in term/ns-win.el.

Sorry, I don't understand: are you saying that those keys don't need
to be supported in the --without-ns build?  Then what exactly is the
meaning of --with-ns for -nw sessions?  Isn't NS a kind-of
window-system?

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Yoichi Nakayama]

The problem I reported is that
  (substitute-command-keys "\\[customize]")
results in "<ns-show-prefs>".

This is caused by defining global key mapping in term/ns-win.el:
  (define-key global-map [ns-show-prefs] 'customize)
without make-non-key-event call for ns-*.

So, if term/ns-win.el is not loaded and the problem doesn't occur.
That is why I said:

> If term/ns-win.el is not loaded, no need to call make-non-key-event for ns-".
> It is because global-set-key for ns-" is only in term/ns-win.el.

(Sorry. I wrote "global-set-key" by mistake, it was "define-key
global-map" in fact)

* Emacs built with --without-ns doesn't load term/ns-win.el (in this
case, the problem doesn't occur)
* Emacs built with --with-ns does load term/ns-win.el even in -nw process

Therefore, putting make-non-key-event for non-key events ns-* in the
toplevel of term/ns-win.el solve the problem, and I also think
term/ns-win.el is better place as you said "NS specific code should
definitely go to ns-win.el".

On Sat, Dec 7, 2024 at 4:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> > Date: Sat, 7 Dec 2024 05:20:42 +0900
> > Cc: Eli Zaretskii <eliz@gnu.org>, Robert Pluim <rpluim@gmail.com>, 74619@debbugs.gnu.org
> >
> > > I configure --without-ns, and ns-win.el is not loaded in that case.
> >
> > If term/ns-win.el is not loaded, no need to call make-non-key-event for ns-".
> > It is because global-set-key for ns-" is only in term/ns-win.el.
>
> Sorry, I don't understand: are you saying that those keys don't need
> to be supported in the --without-ns build?  Then what exactly is the
> meaning of --with-ns for -nw sessions?  Isn't NS a kind-of
> window-system?



-- 
Yoichi NAKAYAMA

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
> Date: Sun, 8 Dec 2024 10:01:16 +0900
> Cc: gerd.moellmann@gmail.com, rpluim@gmail.com, 74619@debbugs.gnu.org
> 
> The problem I reported is that
>   (substitute-command-keys "\\[customize]")
> results in "<ns-show-prefs>".
> 
> This is caused by defining global key mapping in term/ns-win.el:
>   (define-key global-map [ns-show-prefs] 'customize)
> without make-non-key-event call for ns-*.
> 
> So, if term/ns-win.el is not loaded and the problem doesn't occur.
> That is why I said:
> 
> > If term/ns-win.el is not loaded, no need to call make-non-key-event for ns-".
> > It is because global-set-key for ns-" is only in term/ns-win.el.
> 
> (Sorry. I wrote "global-set-key" by mistake, it was "define-key
> global-map" in fact)
> 
> * Emacs built with --without-ns doesn't load term/ns-win.el (in this
> case, the problem doesn't occur)
> * Emacs built with --with-ns does load term/ns-win.el even in -nw process
> 
> Therefore, putting make-non-key-event for non-key events ns-* in the
> toplevel of term/ns-win.el solve the problem, and I also think
> term/ns-win.el is better place as you said "NS specific code should
> definitely go to ns-win.el".

Thanks, then I guess it's okay to move the code there.

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Fri, 06 Dec 2024 20:24:39 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> What will be in term/darwin.el?

Nothing, because my analysis was wrong :-)

Iʼll prepare a patch based on the comments in the other arm of this
bug thread.

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Sun, 08 Dec 2024 08:09:15 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Yoichi Nakayama <yoichi.nakayama@gmail.com>
    >> * Emacs built with --without-ns doesn't load term/ns-win.el (in this
    >> case, the problem doesn't occur)
    >> * Emacs built with --with-ns does load term/ns-win.el even in -nw process
    >> 
    >> Therefore, putting make-non-key-event for non-key events ns-* in the
    >> toplevel of term/ns-win.el solve the problem, and I also think
    >> term/ns-win.el is better place as you said "NS specific code should
    >> definitely go to ns-win.el".

    Eli> Thanks, then I guess it's okay to move the code there.

Except if we do that, then in the --with-ns build, the ⌘-, binding
(and the toplevel emacs/Settings menu item) doesnʼt work anymore. Iʼd
rather not have the code be duplicated, so how about this (I suck at
naming, so we can change the defun name):

diff --git i/lisp/term/common-win.el w/lisp/term/common-win.el
index 181dcc8e6d9..68c3b2d56e3 100644
--- i/lisp/term/common-win.el
+++ w/lisp/term/common-win.el
@@ -45,6 +45,8 @@ x-alternatives-map
     map)
   "Keymap of possible alternative meanings for some keys.")
 
+(declare-function ns-setup-special-keys "term/ns-win" ())
+
 (defun x-setup-function-keys (frame)
   "Set up `function-key-map' on the graphical frame FRAME."
   ;; Don't do this twice on the same display, or it would break
@@ -56,22 +58,7 @@ x-setup-function-keys
         (set-keymap-parent map (keymap-parent local-function-key-map))
         (set-keymap-parent local-function-key-map map))
       (when (featurep 'ns)
-	(setq system-key-alist
-	      (list
-	       ;; These are special "keys" used to pass events from C to lisp.
-	       (cons  1 (make-non-key-event 'ns-power-off))
-	       (cons  2 (make-non-key-event 'ns-open-file))
-	       (cons  3 (make-non-key-event 'ns-open-temp-file))
-	       (cons  4 (make-non-key-event 'ns-drag-file))
-	       (cons  5 (make-non-key-event 'ns-drag-color))
-	       (cons  6 (make-non-key-event 'ns-drag-text))
-	       (cons  8 (make-non-key-event 'ns-open-file-line))
-;;;	       (cons  9 (make-non-key-event 'ns-insert-working-text))
-;;;	       (cons 10 (make-non-key-event 'ns-delete-working-text))
-	       (cons 11 (make-non-key-event 'ns-spi-service-call))
-	       (cons 12 (make-non-key-event 'ns-new-frame))
-	       (cons 13 (make-non-key-event 'ns-toggle-toolbar))
-	       (cons 14 (make-non-key-event 'ns-show-prefs))))))
+        (ns-setup-special-keys)))
     (set-terminal-parameter frame 'x-setup-function-keys t)))
 
 (defvar x-invocation-args)
diff --git i/lisp/term/ns-win.el w/lisp/term/ns-win.el
index 2a29457133e..640b7fe6dc7 100644
--- i/lisp/term/ns-win.el
+++ w/lisp/term/ns-win.el
@@ -168,6 +168,27 @@ global-map
 (define-key global-map [S-mouse-1] 'mouse-save-then-kill)
 (global-unset-key [S-down-mouse-1])
 
+;; Moved here from common-win.el because they need to work in a -nw
+;; invocation of a (featurep 'ns) => true build.  Bug#74619.
+(defun ns-setup-special-keys ()
+  (setq system-key-alist
+        (list
+         ;; These are special "keys" used to pass events from C to lisp.
+         (cons  1 (make-non-key-event 'ns-power-off))
+         (cons  2 (make-non-key-event 'ns-open-file))
+         (cons  3 (make-non-key-event 'ns-open-temp-file))
+         (cons  4 (make-non-key-event 'ns-drag-file))
+         (cons  5 (make-non-key-event 'ns-drag-color))
+         (cons  6 (make-non-key-event 'ns-drag-text))
+         (cons  8 (make-non-key-event 'ns-open-file-line))
+;;;            (cons  9 (make-non-key-event 'ns-insert-working-text))
+;;;            (cons 10 (make-non-key-event 'ns-delete-working-text))
+         (cons 11 (make-non-key-event 'ns-spi-service-call))
+         (cons 12 (make-non-key-event 'ns-new-frame))
+         (cons 13 (make-non-key-event 'ns-toggle-toolbar))
+         (cons 14 (make-non-key-event 'ns-show-prefs)))))
+(ns-setup-special-keys)
+
 ;; Special Nextstep-generated events are converted to function keys.  Here
 ;; are the bindings for them.  Note, these keys are actually declared in
 ;; x-setup-function-keys in common-win.


Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Yoichi Nakayama <yoichi.nakayama@gmail.com>,  gerd.moellmann@gmail.com,
>   74619@debbugs.gnu.org
> Date: Mon, 09 Dec 2024 17:14:52 +0100
> 
> >>>>> On Sun, 08 Dec 2024 08:09:15 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> Thanks, then I guess it's okay to move the code there.
> 
> Except if we do that, then in the --with-ns build, the ⌘-, binding
> (and the toplevel emacs/Settings menu item) doesnʼt work anymore. Iʼd
> rather not have the code be duplicated, so how about this (I suck at
> naming, so we can change the defun name):

Fine by me, thanks.

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

>>>>> On Mon, 09 Dec 2024 18:31:14 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> Fine by me, thanks.

master or emacs-30?

Robert
-- 

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: yoichi.nakayama@gmail.com,  gerd.moellmann@gmail.com,
>   74619@debbugs.gnu.org
> Date: Tue, 10 Dec 2024 14:51:04 +0100
> 
> >>>>> On Mon, 09 Dec 2024 18:31:14 +0200, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> Fine by me, thanks.
> 
> master or emacs-30?

I'd prefer master, unless NS users will be very unhappy without this
change.

Thanks.

bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw

[Robert Pluim]

tags 74619 fixed
close 74619 31.1
quit

>>>>> On Tue, 10 Dec 2024 16:36:59 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> I'd prefer master, unless NS users will be very unhappy without this
    Eli> change.

Itʼs a pretty minor issue, master it is.

Closing.
Committed as ebd8feef149

Robert
--