* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw
@ 2024-11-30 7:40 Yoichi Nakayama
2024-12-02 14:09 ` Robert Pluim
0 siblings, 1 reply; 18+ messages in thread
From: Yoichi Nakayama @ 2024-11-30 7:40 UTC (permalink / raw)
To: 74619
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
^ permalink raw reply [flat|nested] 18+ messages in thread* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-11-30 7:40 bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw Yoichi Nakayama @ 2024-12-02 14:09 ` Robert Pluim 2024-12-02 14:49 ` Gerd Möllmann 2024-12-04 13:53 ` Yoichi Nakayama 0 siblings, 2 replies; 18+ messages in thread From: Robert Pluim @ 2024-12-02 14:09 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: Gerd Möllmann, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-02 14:09 ` Robert Pluim @ 2024-12-02 14:49 ` Gerd Möllmann 2024-12-04 13:53 ` Yoichi Nakayama 1 sibling, 0 replies; 18+ messages in thread From: Gerd Möllmann @ 2024-12-02 14:49 UTC (permalink / raw) To: Robert Pluim; +Cc: Yoichi Nakayama, 74619 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-02 14:09 ` Robert Pluim 2024-12-02 14:49 ` Gerd Möllmann @ 2024-12-04 13:53 ` Yoichi Nakayama 2024-12-04 14:38 ` Robert Pluim 1 sibling, 1 reply; 18+ messages in thread From: Yoichi Nakayama @ 2024-12-04 13:53 UTC (permalink / raw) To: Robert Pluim; +Cc: Gerd Möllmann, 74619 > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-04 13:53 ` Yoichi Nakayama @ 2024-12-04 14:38 ` Robert Pluim 2024-12-06 13:46 ` Yoichi Nakayama 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2024-12-04 14:38 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: Gerd Möllmann, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-04 14:38 ` Robert Pluim @ 2024-12-06 13:46 ` Yoichi Nakayama 2024-12-06 15:16 ` Robert Pluim 0 siblings, 1 reply; 18+ messages in thread From: Yoichi Nakayama @ 2024-12-06 13:46 UTC (permalink / raw) To: Robert Pluim; +Cc: Gerd Möllmann, 74619 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 13:46 ` Yoichi Nakayama @ 2024-12-06 15:16 ` Robert Pluim 2024-12-06 16:22 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2024-12-06 15:16 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: Gerd Möllmann, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 15:16 ` Robert Pluim @ 2024-12-06 16:22 ` Eli Zaretskii 2024-12-06 16:53 ` Robert Pluim 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-12-06 16:22 UTC (permalink / raw) To: Robert Pluim; +Cc: yoichi.nakayama, gerd.moellmann, 74619 > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 16:22 ` Eli Zaretskii @ 2024-12-06 16:53 ` Robert Pluim 2024-12-06 16:59 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Robert Pluim @ 2024-12-06 16:53 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yoichi.nakayama, gerd.moellmann, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 16:53 ` Robert Pluim @ 2024-12-06 16:59 ` Eli Zaretskii 2024-12-06 17:11 ` Gerd Möllmann 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-12-06 16:59 UTC (permalink / raw) To: Robert Pluim; +Cc: yoichi.nakayama, gerd.moellmann, 74619 > 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)? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 16:59 ` Eli Zaretskii @ 2024-12-06 17:11 ` Gerd Möllmann 2024-12-06 17:24 ` Robert Pluim 2024-12-06 20:20 ` Yoichi Nakayama 0 siblings, 2 replies; 18+ messages in thread From: Gerd Möllmann @ 2024-12-06 17:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: yoichi.nakayama, Robert Pluim, 74619 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 17:11 ` Gerd Möllmann @ 2024-12-06 17:24 ` Robert Pluim 2024-12-06 18:24 ` Eli Zaretskii 2024-12-06 20:20 ` Yoichi Nakayama 1 sibling, 1 reply; 18+ messages in thread From: Robert Pluim @ 2024-12-06 17:24 UTC (permalink / raw) To: Gerd Möllmann; +Cc: yoichi.nakayama, Eli Zaretskii, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 17:24 ` Robert Pluim @ 2024-12-06 18:24 ` Eli Zaretskii 2024-12-09 8:38 ` Robert Pluim 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-12-06 18:24 UTC (permalink / raw) To: Robert Pluim; +Cc: gerd.moellmann, yoichi.nakayama, 74619 > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 18:24 ` Eli Zaretskii @ 2024-12-09 8:38 ` Robert Pluim 0 siblings, 0 replies; 18+ messages in thread From: Robert Pluim @ 2024-12-09 8:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gerd.moellmann, yoichi.nakayama, 74619 >>>>> 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 -- ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 17:11 ` Gerd Möllmann 2024-12-06 17:24 ` Robert Pluim @ 2024-12-06 20:20 ` Yoichi Nakayama 2024-12-07 7:32 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: Yoichi Nakayama @ 2024-12-06 20:20 UTC (permalink / raw) To: Gerd Möllmann; +Cc: Eli Zaretskii, 74619, Robert Pluim > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-06 20:20 ` Yoichi Nakayama @ 2024-12-07 7:32 ` Eli Zaretskii 2024-12-08 1:01 ` Yoichi Nakayama 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2024-12-07 7:32 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: gerd.moellmann, rpluim, 74619 > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-07 7:32 ` Eli Zaretskii @ 2024-12-08 1:01 ` Yoichi Nakayama 2024-12-08 6:09 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Yoichi Nakayama @ 2024-12-08 1:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gerd.moellmann, rpluim, 74619 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw 2024-12-08 1:01 ` Yoichi Nakayama @ 2024-12-08 6:09 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2024-12-08 6:09 UTC (permalink / raw) To: Yoichi Nakayama; +Cc: gerd.moellmann, rpluim, 74619 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2024-12-09 8:38 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-11-30 7:40 bug#74619: macOS: <ns-show-prefs> displayed as keybinding for \\[customize] on emacs -nw Yoichi Nakayama 2024-12-02 14:09 ` Robert Pluim 2024-12-02 14:49 ` Gerd Möllmann 2024-12-04 13:53 ` Yoichi Nakayama 2024-12-04 14:38 ` Robert Pluim 2024-12-06 13:46 ` Yoichi Nakayama 2024-12-06 15:16 ` Robert Pluim 2024-12-06 16:22 ` Eli Zaretskii 2024-12-06 16:53 ` Robert Pluim 2024-12-06 16:59 ` Eli Zaretskii 2024-12-06 17:11 ` Gerd Möllmann 2024-12-06 17:24 ` Robert Pluim 2024-12-06 18:24 ` Eli Zaretskii 2024-12-09 8:38 ` Robert Pluim 2024-12-06 20:20 ` Yoichi Nakayama 2024-12-07 7:32 ` Eli Zaretskii 2024-12-08 1:01 ` Yoichi Nakayama 2024-12-08 6:09 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).