xterm [menu] key definition

xterm [menu] key definition

[Ergus]

Hi:

Due to the recent context-menu feature I was trying to bind the [menu]
key to the context-menu and just noticed that on xterm emacs detects the
menu key as [print]; so it does not trigger the execute-extended-command
(which is bound to <execute>, <menu> and M-x by default).

cat+xterm shows that the menu key sends "\e[29~"

Grepping in the term directory there is.

lk201.el:35:    (define-key map "\e[29~" [menu])
rxvt.el:67:    (define-key map "\e[29~" [S-f6])
xterm.el:353:    (define-key map "\e[29~" [print])

And xev says that "\e[29~" is actually [Menu] and detects it properly so
there is a mismatch here.

I don't know if this is an issue or some design choice made long time
ago (in 2007), but it makes that the menu button does not behave the
same in xterm, gui or rxvt. The user can go around this binding [Print]
to whatever, but if there is not a reason, then maybe it worth doing.

(define-key map "\e[29~" [menu]) in xterm.el too?

I don't actually know about any keyboard with a print button... But I
suppose there should be some. If someone has it; please could you check
with xev and cat+xterm what it sends?

Thanks in advance,
Ergus

Re: xterm [menu] key definition

[Ergus]

Hi:

I will insist on this. The change is very simple, but I don't know if
there will be any consequence.

On Thu, Aug 19, 2021 at 04:47:28AM +0200, Ergus wrote:
>Hi:
>
>Due to the recent context-menu feature I was trying to bind the [menu]
>key to the context-menu and just noticed that on xterm emacs detects the
>menu key as [print]; so it does not trigger the execute-extended-command
>(which is bound to <execute>, <menu> and M-x by default).
>
>cat+xterm shows that the menu key sends "\e[29~"
>
>Grepping in the term directory there is.
>
>lk201.el:35:    (define-key map "\e[29~" [menu])
>rxvt.el:67:    (define-key map "\e[29~" [S-f6])
>xterm.el:353:    (define-key map "\e[29~" [print])
>
>And xev says that "\e[29~" is actually [Menu] and detects it properly so
>there is a mismatch here.
>
>I don't know if this is an issue or some design choice made long time
>ago (in 2007), but it makes that the menu button does not behave the
>same in xterm, gui or rxvt. The user can go around this binding [Print]
>to whatever, but if there is not a reason, then maybe it worth doing.
>
>(define-key map "\e[29~" [menu]) in xterm.el too?
>
>I don't actually know about any keyboard with a print button... But I
>suppose there should be some. If someone has it; please could you check
>with xev and cat+xterm what it sends?
>
>Thanks in advance,
>Ergus
>

Re: xterm [menu] key definition

[Juri Linkov]

* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.
>
> on debian buster, that is.

I have the PrtSc key that prints the screen,
but no Menu key, so can't confirm, sorry.

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 09:37:23AM +0300, Juri Linkov wrote:
>* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
>>> I don't actually know about any keyboard with a print
>>> button...
>>
>> wouldn't that be the PrtSc key which is on every standard PC
>> keyboard right of F12 and above of Insert?
>>
>>> But I suppose there should be some. If someone has it;
>>> please could you check with xev and cat+xterm what it
>>> sends?
>>
>> Said key gives via cat on xterm:
>>
>> ^[[2~
>>
>> and xev says the same.
>>
>> on debian buster, that is.
>
>I have the PrtSc key that prints the screen,
>but no Menu key, so can't confirm, sorry.
>
I don't think there is a [print] key anymore anywhere... "PrtSc" is
something else and in general never should reach emacs because it is
intended to take screenshots; so the desktop or window manager should
intercept it before.

I think that definitively "\e[29~" may be bound to [menu] in
xterm. Somehow confirmed by the xterm maintainer in an email:

"in a quick check the key which I guessed is "menu" (between the Windows
key and the Ctrl key on the right-side of my keyboard) does send ^[[29~
and xev says that's "Menu""

As this may potentially break the universe for some reason I am not
aware of, I will wait for Eli's, Stefan's or Lars' authorization on
this.

Re: xterm [menu] key definition

[tomas]

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

On Tue, Aug 24, 2021 at 10:19:06AM +0200, Ergus wrote:
> On Tue, Aug 24, 2021 at 09:37:23AM +0300, Juri Linkov wrote:
> >* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> >>>I don't actually know about any keyboard with a print
> >>>button...
> >>
> >>wouldn't that be the PrtSc key which is on every standard PC
> >>keyboard right of F12 and above of Insert?
> >>
> >>>But I suppose there should be some. If someone has it;
> >>>please could you check with xev and cat+xterm what it
> >>>sends?
> >>
> >>Said key gives via cat on xterm:
> >>
> >>^[[2~
> >>
> >>and xev says the same.
> >>
> >>on debian buster, that is.
> >
> >I have the PrtSc key that prints the screen,
> >but no Menu key, so can't confirm, sorry.
> >
> I don't think there is a [print] key anymore anywhere... "PrtSc" is
> something else and in general never should reach emacs because it is
> intended to take screenshots; so the desktop or window manager should
> intercept it before.

It's a key as any other key too. For those using refurbished hardware
it's not as uncommon as you might think.

I remap it to whatever seems useful (but then, I remap also caps lock,
because I deem it useless, so I'm weird ;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[Andreas Schwab]

On Aug 24 2021, Ergus wrote:

> I don't think there is a [print] key anymore anywhere... "PrtSc" is
> something else

I don't think so.  The X keysym for this key is Print.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 10:34:50AM +0200, Andreas Schwab wrote:
>On Aug 24 2021, Ergus wrote:
>
>> I don't think there is a [print] key anymore anywhere... "PrtSc" is
>> something else
>
>I don't think so.  The X keysym for this key is Print.
>
Xterm does not send anything to emacs with PrtSc even when it is not
intercepted. But in X it is true that it is called Print (according to
xev).

In any case the escape sequence it sends is different than the one from
the [menu] key (the key between <alt> and <control> in the right side if
my keyboard).

So I think that binding "\e[29~" to Print in Xterm is just an error.

>Andreas.
>
>-- 
>Andreas Schwab, schwab@linux-m68k.org
>GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
>"And now for something completely different."
>

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 10:34:33AM +0200, tomas@tuxteam.de wrote:
>On Tue, Aug 24, 2021 at 10:19:06AM +0200, Ergus wrote:
>> On Tue, Aug 24, 2021 at 09:37:23AM +0300, Juri Linkov wrote:
>> >* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
>> >>>I don't actually know about any keyboard with a print
>> >>>button...
>> >>
>> >>wouldn't that be the PrtSc key which is on every standard PC
>> >>keyboard right of F12 and above of Insert?
>> >>
>> >>>But I suppose there should be some. If someone has it;
>> >>>please could you check with xev and cat+xterm what it
>> >>>sends?
>> >>
>> >>Said key gives via cat on xterm:
>> >>
>> >>^[[2~
>> >>
>> >>and xev says the same.
>> >>
>> >>on debian buster, that is.
>> >
>> >I have the PrtSc key that prints the screen,
>> >but no Menu key, so can't confirm, sorry.
>> >
>> I don't think there is a [print] key anymore anywhere... "PrtSc" is
>> something else and in general never should reach emacs because it is
>> intended to take screenshots; so the desktop or window manager should
>> intercept it before.
>
>It's a key as any other key too. For those using refurbished hardware
>it's not as uncommon as you might think.
>
>I remap it to whatever seems useful (but then, I remap also caps lock,
>because I deem it useless, so I'm weird ;-)
>
>Cheers
> - t

Then if you have it, could you tell what escape sequence it sends throw
Xterm by default? If you could do the same with urxvt will be very nice
;)

So we could rebind "\e[29~" to [menu] as it should; and whatever
sequence Print sends to [print].

Someone mentioned that PrtSc sends "\e[2~" is it different from the
sequence sent by your Print key?

Thanks in advance,
Ergus.

Re: xterm [menu] key definition

[Andreas Schwab]

On Aug 24 2021, Ergus wrote:

> Someone mentioned that PrtSc sends "\e[2~" is it different from the
> sequence sent by your Print key?

CSI 2 ~ is the Insert key.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: xterm [menu] key definition

[tomas]

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

On Tue, Aug 24, 2021 at 11:17:41AM +0200, Ergus wrote:

[...]

> Then if you have it, could you tell what escape sequence it sends throw
> Xterm by default? If you could do the same with urxvt will be very nice
> ;)

Sure :)

I tried both. My methodology is to run 'cat | hexdump -C' in each of
xterm and urxvt and to terminate input with CTRL-D.

I tested the methodology itself by trying some keys where I more or
less knew what to expect ("a", <ENTER>, but also <F2>).

The result is... nothing.

This may sound disappointing, but then, xterm tries to pretend being
a VT220, and those had no "print" key.

OTOH, it would be subestimating the folks at MIT Project Athena to
assume that would not be configurable. Hard-coding this wouldn't
have made sense to them.

So yes, for xterm at least (but I think for urxvt, too), you can
configure that with X Resources. This one [1] looks as if there
were hope as long as there is a keysym. No time to try it out
at the moment, though.

Whether the application (Emacs) running "in" the xterm can change
that dynamically (or has to tell the user to do that for it ;)
is the next interesting question :-)

Cheers
[1] http://www.fifi.org/doc/xterm/xterm.faq.html#how2_fkeys
   which is, BTW, a wonderful resource in things xterm.
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 01:00:14PM +0200, tomas@tuxteam.de wrote:
>On Tue, Aug 24, 2021 at 11:17:41AM +0200, Ergus wrote:
>
>[...]
>
>> Then if you have it, could you tell what escape sequence it sends throw
>> Xterm by default? If you could do the same with urxvt will be very nice
>> ;)
>
>Sure :)
>
>I tried both. My methodology is to run 'cat | hexdump -C' in each of
>xterm and urxvt and to terminate input with CTRL-D.
>
>I tested the methodology itself by trying some keys where I more or
>less knew what to expect ("a", <ENTER>, but also <F2>).
>
>The result is... nothing.
>
>This may sound disappointing, but then, xterm tries to pretend being
>a VT220, and those had no "print" key.
>
>OTOH, it would be subestimating the folks at MIT Project Athena to
>assume that would not be configurable. Hard-coding this wouldn't
>have made sense to them.
>
>So yes, for xterm at least (but I think for urxvt, too), you can
>configure that with X Resources. This one [1] looks as if there
>were hope as long as there is a keysym. No time to try it out
>at the moment, though.
>
>Whether the application (Emacs) running "in" the xterm can change
>that dynamically (or has to tell the user to do that for it ;)
>is the next interesting question :-)
>
>Cheers
>[1] http://www.fifi.org/doc/xterm/xterm.faq.html#how2_fkeys
>   which is, BTW, a wonderful resource in things xterm.
> - t


Hi!

Thanks for the link! Of course we can emulate anything in xterm. The
question is what xterm does by default? and why we bound the menu
sequence to [print] instead of [menu] if emacs internally uses [menu]
for execute-extended-command?

If xterm assumes it is a VT220; then we must assume the same when using
it by default (until we implement a more complex API to ask
xterm... (but that may be inefficient and probably don't worth it for
such a detail).

Sometimes emacs assumes there is a [menu] key but then in xterm the same
key is interpreted as [print] by emacs. So a very comfortable key (for
those who have it) that we can't use consistently.

Part of my intention is to minimize the "special" customization required
when using xterm+emacs (either in Xdefaults or in init.el); any fancy
more specific customization can be made latter by the user when he gets
familiar with the rest of the environment (GNU/Linux, xterm, emacs,
Elisp, the command line interface, the OS configuration system...) for
new users it is like getting into Narnia the fist week/month.

I expect that most of the emacs features work and behave as similar as
possible when using the xterm, tty or gui without customization,
everything out of the box.

Re: xterm [menu] key definition

[Ergus via Emacs development discussions.]

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

On Tue, Aug 24, 2021 at 09:37:23AM +0300, Juri Linkov wrote:
>* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
>>> I don't actually know about any keyboard with a print
>>> button...
>>
>> wouldn't that be the PrtSc key which is on every standard PC
>> keyboard right of F12 and above of Insert?
>>
>>> But I suppose there should be some. If someone has it;
>>> please could you check with xev and cat+xterm what it
>>> sends?
>>
>> Said key gives via cat on xterm:
>>
>> ^[[2~
>>
>> and xev says the same.
>>
>> on debian buster, that is.
>
>I have the PrtSc key that prints the screen,
>but no Menu key, so can't confirm, sorry.
>
Just to clarify.

What I am proposing is as simple as the attached patch.

I won't expect any complain about the change, but if so we then may
decide to do something like an alias between [menu] and [print]:

BTW: Juri, may we add a binding that toggles the menu when we repeat the
S-<f6> or the [menu] key (or whatever key the user pressed to activate
it)? Because a single ESC hides the menu only on gui not in term.

We can do that with C-g or ESC ESC ESC; but repeating to toggle is a
very common behavior right? and now it is free, it is better to take it
before some more fancy behavior comes for it in a while ;p.

[-- Attachment #2: menu.patch --]
[-- Type: text/plain, Size: 1858 bytes --]

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 9d86681384..9e37527e70 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -452,10 +452,20 @@ context-menu-entry
   `(menu-item ,(purecopy "Context Menu") ignore
               :filter (lambda (_) (context-menu-map))))
 
+(defun context-menu-open ()
+  "Start key navigation of the context menu.
+This is the keyboard interface to \\[context-menu-map]."
+  (interactive)
+  (let ((inhibit-mouse-event-check t))
+    (popup-menu (context-menu-map) (point))))
+
+(global-set-key [S-f6] #'context-menu-open)
+
 (defvar context-menu-mode-map
   (let ((map (make-sparse-keymap)))
     (define-key map [mouse-3] nil)
     (define-key map [down-mouse-3] context-menu-entry)
+    (define-key map [menu] #'context-menu-open)
     (when (featurep 'ns)
       (define-key map [C-mouse-1] nil)
       (define-key map [C-down-mouse-1] context-menu-entry))
@@ -468,16 +478,6 @@ context-menu-mode
 When Context Menu mode is enabled, clicking the mouse button down-mouse-3
 activates the menu whose contents depends on its surrounding context."
   :global t :group 'mouse)
-
-(defun context-menu-open ()
-  "Start key navigation of the context menu.
-This is the keyboard interface to \\[context-menu-map]."
-  (interactive)
-  (let ((inhibit-mouse-event-check t))
-    (popup-menu (context-menu-map) (point))))
-
-(global-set-key [S-f10] 'context-menu-open)
-
 \f
 ;; Commands that operate on windows.
 
diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index e63bf36cc3..d37206e018 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -350,7 +350,7 @@ xterm-function-map
     (define-key map "\e[5;3~" [M-prior])
     (define-key map "\e[6;3~" [M-next])
 
-    (define-key map "\e[29~" [print])
+    (define-key map "\e[29~" [menu])
 
     (define-key map "\eOj" [kp-multiply])
     (define-key map "\eOk" [kp-add])

Re: xterm [menu] key definition

[Eli Zaretskii]

> Date: Tue, 24 Aug 2021 18:40:36 +0200
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel <emacs-devel@gnu.org>
> From:  Ergus via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> Just to clarify.
> 
> What I am proposing is as simple as the attached patch.
> 
> I won't expect any complain about the change, but if so we then may
> decide to do something like an alias between [menu] and [print]:

Look, we need some kind of evidence that this is TRT, some document
that describes that key, or explains why urxvt and xterm behave
differently, or who and why made the current code as it is.  We cannot
make this change in xterm.el just because you think it's right and it
suits your personal system configuration.  The code we have wins by
default, unless you can come up with a clear reason explaining why it
is wrong.

The rest of the change, i.e. binding the menu to the <menu> key, is
fine by me.  But not the change in xterm.el, not without a very good
explanation.

Okay?

Re: xterm [menu] key definition

[Juri Linkov]

> The rest of the change, i.e. binding the menu to the <menu> key, is
> fine by me.  But not the change in xterm.el, not without a very good
> explanation.

So now pushed only the part of the patch that binds the <menu> key.

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 08:28:22PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 24 Aug 2021 18:40:36 +0200
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>>  emacs-devel <emacs-devel@gnu.org>
>> From:  Ergus via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> Just to clarify.
>>
>> What I am proposing is as simple as the attached patch.
>>
>> I won't expect any complain about the change, but if so we then may
>> decide to do something like an alias between [menu] and [print]:

Hi Eli:

It is fine for me. Actually I didn't add the [PATCH] flag to the Subject
of the message because the patch was only to illustrate the proposal
with specific code, not more and more words and explications.

>
>Look, we need some kind of evidence that this is TRT, some document
>that describes that key, or explains why urxvt and xterm behave
>differently, or who and why made the current code as it is.  We cannot
>make this change in xterm.el just because you think it's right and it
>suits your personal system configuration.  The code we have wins by
>default, unless you can come up with a clear reason explaining why it
>is wrong.
>

I am not saying the current code is wrong. Just that the so called
[print] key does not exist while the same key is seen as [menu] in gui.

I expect that emacs user gets the similar behavior when they press the
menu key. Either in tty, tui or gui... or at least as consistent as
possible. (either redefining ^[[29~ as [menu] or binding the context
menu to [print]... I have already this on my config... obviously I
prefer the first alternative)

I already wrote to Thomas Dickey (xterm maintainer) some days ago about
this:

=================================

On Wed, Aug 18, 2021 at 08:38:44PM -0400, Thomas Dickey wrote:
>On Wed, Aug 18, 2021 at 09:46:53PM +0200, Ergus wrote:
>> Hi:
>>
>> I use emacs and I have noticed that when using xterm and I press the
>> menu key, emacs is detecting <print> instead. (emacs just added a
>> context menu and it could be probably bind to the menu key)
>>
>> cat shows that xterm sends ^[[29~ But I can't find information if this
>> is the right one or how to debug this.
>
>hmm - I didn't notice, but in a quick check the key which I guessed is
>"menu" (between the Windows key and the Ctrl key on the right-side of
>my keyboard) does send ^[[29~ and xev says that's "Menu":
>
>--------------------------------------------------------------------------------
>KeyPress event, serial 34, synthetic NO, window 0xc00001,
>    root 0x111, subw 0xc00002, time 60750193, (37,34), root:(37,57),
>    state 0x0, keycode 118 (keysym 0xff67, Menu), same_screen YES,
>    XLookupString gives 0 bytes:
>    XmbLookupString gives 0 bytes:
>    XFilterEvent returns: False
>
>KeyRelease event, serial 34, synthetic NO, window 0xc00001,
>    root 0x111, subw 0xc00002, time 60750321, (37,34), root:(37,57),
>    state 0x0, keycode 118 (keysym 0xff67, Menu), same_screen YES,
>    XLookupString gives 0 bytes:
>    XFilterEvent returns: False
>
>KeyPress event, serial 34, synthetic NO, window 0xc00001,
>    root 0x111, subw 0xc00002, time 60750537, (37,34), root:(37,57),
>    state 0x0, keycode 118 (keysym 0xff67, Menu), same_screen YES,
>    XLookupString gives 0 bytes:
>    XmbLookupString gives 0 bytes:
>    XFilterEvent returns: False
>--------------------------------------------------------------------------------
>
>But in the terminal description, I'd not assigned anything to that.
>It's not a numbered function key, and terminfo doesn't have a standard
>"menu" key (I could add one, but had overlooked this :-).
>
>Emacs does.  Someone was telling me recently about something related
>to xterm, so I've a current source.  In that, I see this, with grep:
>
>lisp/term/lk201.el:35:    (define-key map "\e[29~" [menu])
>lisp/term/xterm.el:353:    (define-key map "\e[29~" [print])
>lisp/term/rxvt.el:67:    (define-key map "\e[29~" [S-f6])
>
>which is kind of old (git blame tells me):
>
>0ba6bcb1d6e (Stefan Monnier    2007-09-07 19:47:46 +0000  353)
>
>but the first match shows the binding that you'd like to have.
>
>I don't use emacs, but suppose that you can add that definition
>to your custom settings, and get the menu that you expect.
>
>-- 
>Thomas E. Dickey <dickey@invisible-island.net>
>https://invisible-island.net
>ftp://ftp.invisible-island.net

=================================

>The rest of the change, i.e. binding the menu to the <menu> key, is
>fine by me.  But not the change in xterm.el, not without a very good
>explanation.
>
>Okay?

The other change I propose is the S-<f6> instead of S-<f10> and for that
we have all the evidence that urxvt binds the same escape sequence to
S-<f6> (since we do:

lisp/term/rxvt.el:67:    (define-key map "\e[29~" [S-f6])

and "\e[29~" is what the menu key sends by default)

Otherwise we will need to request to all the compatible terminals around
to update their terminfo.. a very long process that will delay for years
until all the systems in all the servers will be updated.

Best,
Ergus

Re: xterm [menu] key definition

[Stefan Monnier]

> I think that definitively "\e[29~" may be bound to [menu] in
> xterm. Somehow confirmed by the xterm maintainer in an email:
>
> "in a quick check the key which I guessed is "menu" (between the Windows
> key and the Ctrl key on the right-side of my keyboard) does send ^[[29~
> and xev says that's "Menu""

I'm sorry but I don't understand this.  Maybe I'm just missing some of
the context in your email exchange, but the way it's written above gives
the impression that something external to xterm decides which byte
sequence to send when the `menu` or `print` key are used, whereas this
decision is made by xterm (partly influenced by things like
X resource settings).

FWIW, in my environment, I have a key labeled `PrtSc` which `xev` says
sends a `Print` event to X11, which `emacs` says sends a `print` event,
and which `emacs --nw` running inside `xterm` doesn't receive at all
(i.e. my `xterm` doesn't send any bytes in response to it).


        Stefan

Re: xterm [menu] key definition

[Stefan Monnier]

> -    (define-key map "\e[29~" [print])
> +    (define-key map "\e[29~" [menu])

This might be right, but we need some more concrete evidence that indeed
`xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
mapped to `\e[29~` by default, or something like that.

That info should be available in `xterm`s source code or something like
that (I hoped that it would be visible in the `app-defaults/XTerm` file
but no).


        Stefan

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 06:16:01PM -0400, Stefan Monnier wrote:
>> -    (define-key map "\e[29~" [print])
>> +    (define-key map "\e[29~" [menu])
>
>This might be right, but we need some more concrete evidence that indeed
>`xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
>mapped to `\e[29~` by default, or something like that.
>
>That info should be available in `xterm`s source code or something like
>that (I hoped that it would be visible in the `app-defaults/XTerm` file
>but no).
>
>
>        Stefan
>
Hi Stefan:

Please give a look to my last email to Eli. I attached an answer from
the xterm maintainer respecting to that. That included a xev output and
his comment about this.

xterm does not map either [print] or [menu] in terminfo but maps
kf16=\E[29~ (that's why urxvt mapped S-<f6> == <f16> == [menu] according
to their convention)

In xterm that mapping (S-<fX> == <f10+X>) depends of the variable
modifyFunctionKeys. But in any case this does not affect the [menu] key
that is not translated.

The real question is why emacs mapped \E[29~ to [print] in xterm;
because the Print key is normally intercepted by the windows manager.

Best,
Ergus

Re: xterm [menu] key definition

[Stefan Monnier]

> Please give a look to my last email to Eli. I attached an answer from
> the xterm maintainer respecting to that. That included a xev output and
> his comment about this.
[...]
> xterm does not map either [print] or [menu] in terminfo but maps
> kf16=\E[29~ (that's why urxvt mapped S-<f6> == <f16> == [menu] according
> to their convention)

So, IIUC he's saying that xterm emits `\E[29~` not for `Print` nor for
`Menu` but for `F16`, right?  So maybe we should have

    (define-key map "\e[29~" [f16])

and then remap `f16` to `menu` maybe even via `S-f6`, but we already
have a remapping of `f16` to `S-f4`, so it looks like a big pile of mess.

> The real question is why emacs mapped \E[29~ to [print] in xterm;

This dates back to:

    commit 92abb02b9b65b95807fd8fdccad10feed0dd3a96
    Author: Karl Heuer <kwzh@gnu.org>
    Date:   Fri Jun 9 02:31:33 1995 +0000
    
        Initial revision

so maybe some kind of xterms back then did that?

FWIW, the f16 => S-f4 mapping dates back to:

    commit 35b1b8abe3d3833ecb4b4cee75b7340ffb707d65
    Author: Dan Nicolaescu <dann@ics.uci.edu>
    Date:   Tue Apr 26 05:56:22 2005 +0000
    
        * NEWS: Mention xterm key bindings.
        
        * term/xterm.el (function-key-map): Fix strings for
        {C,S,A,C-S}-f[1-4]. Use substitute-key-definition to bind
        {C,S,A,C-S}-{f1-f12}.

Do you have a "menu" key which emits the `Menu` X11 event and for which
your terminal emits `\E[29~`?  If so, which terminal is that (details
like the version may be relevant and maybe the OS or environment)?


        Stefan

Re: xterm [menu] key definition

[Yuri Khan]

On Wed, 25 Aug 2021 at 05:16, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > -    (define-key map "\e[29~" [print])
> > +    (define-key map "\e[29~" [menu])
>
> This might be right, but we need some more concrete evidence that indeed
> `xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
> mapped to `\e[29~` by default, or something like that.

Here is your evidence if you don’t mind a github mirror of xterm sources:

https://github.com/Maximus5/xterm/blob/master/src/input.c#L1460

> That info should be available in `xterm`s source code or something like
> that (I hoped that it would be visible in the `app-defaults/XTerm` file
> but no).

Re: xterm [menu] key definition

[tomas]

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

On Tue, Aug 24, 2021 at 06:05:46PM -0400, Stefan Monnier wrote:
> > I think that definitively "\e[29~" may be bound to [menu] in
> > xterm. Somehow confirmed by the xterm maintainer in an email:
> >
> > "in a quick check the key which I guessed is "menu" (between the Windows
> > key and the Ctrl key on the right-side of my keyboard) does send ^[[29~
> > and xev says that's "Menu""
> 
> I'm sorry but I don't understand this.  Maybe I'm just missing some of
> the context in your email exchange, but the way it's written above gives
> the impression that something external to xterm decides which byte
> sequence to send when the `menu` or `print` key are used, whereas this
> decision is made by xterm (partly influenced by things like
> X resource settings).

The latter was my point: it's exactly xterm (or whatever X terminal
application you are using) which (possibly) converts X events to
escape sequences.

In the case of xterm this can be configured via X resources.

> FWIW, in my environment, I have a key labeled `PrtSc` which `xev` says
> sends a `Print` event to X11, which `emacs` says sends a `print` event,
> and which `emacs --nw` running inside `xterm` doesn't receive at all
> (i.e. my `xterm` doesn't send any bytes in response to it).

Yes, that corresponds to my findings. I guess the "Print" key was not
a thing whenever the X resources for xterm were set up and nobody has
bothered to change them in the mean time.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[tomas]

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

On Tue, Aug 24, 2021 at 05:30:03PM +0200, Ergus wrote:

[...]

> Hi!
> 
> Thanks for the link! Of course we can emulate anything in xterm. The
> question is what xterm does by default? and why we bound the menu
> sequence to [print] instead of [menu] if emacs internally uses [menu]
> for execute-extended-command?

[...]

> If xterm assumes it is a VT220; then we must assume the same when using
> it by default (until we implement a more complex API to ask
> xterm... (but that may be inefficient and probably don't worth it for
> such a detail).

I wouldn't expect an "xterm API". The "API" are the escape sequences :)

The best one can do, I guess, is try to convince each one of the
pseudo terminal implementors to use the same escape sequence for
each of the non-standard keys. Perhaps there already /are/ ANSI
(or some other standards body!) escape sequences. Perhaps not.

> Sometimes emacs assumes there is a [menu] key but then in xterm the same
> key is interpreted as [print] by emacs. So a very comfortable key (for
> those who have it) that we can't use consistently.

When you say "emacs assumes" you are referring to some "GUI guts"?

> Part of my intention is to minimize the "special" customization required
> when using xterm+emacs (either in Xdefaults or in init.el); any fancy
> more specific customization can be made latter by the user when he gets
> familiar with the rest of the environment (GNU/Linux, xterm, emacs,
> Elisp, the command line interface, the OS configuration system...) for
> new users it is like getting into Narnia the fist week/month.

The lowest common denominator would be to assume that there is no
"print" (aka PrintSc) key, same for "menu", more so for "windows".

> I expect that most of the emacs features work and behave as similar as
> possible when using the xterm, tty or gui without customization,
> everything out of the box.

That's because you have only seen one keyboard [2] :)

BTW, just out of kicks, I tried the same experiment with the Linux
terminal (no need for the cat, just hexdump will do, btw), and it
also doesn't translate "print" into any escape sequence. So this
isn't limited to X terminal emulators.

If you want consistency across the terminal emulators *and*  you
want print (and/or menu...) *and* you want it out of the box, you
better start sending config [1] patches to all the term emulators
out there :-)

Cheers

[1] https://en.wikipedia.org/wiki/ANSI_escape_code
[2] not meant personally: we are just witnessing a curious "inversion".
   At the time those terminal emulators were designed, there was a
   *huge* variety of keyboards and few emulators, these days it's
   the other way around. PC has won, and if Microsoft says "we wanna
   have one key, because Apple also haz one", then everyone has a
   Windows key. Actually they got two, because Apple had two).
[3] if the implementors were as wise as xterm's and put those tidbits
   into some config, that is

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[tomas]

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

On Wed, Aug 25, 2021 at 01:20:33AM +0200, Ergus wrote:

[...]

> The real question is why emacs mapped \E[29~ to [print] in xterm;
> because the Print key is normally intercepted by the windows manager.

This is almost certainly wrong. Terminal emulators haven't a binding
for that key would be more right.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[tomas]

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

On Wed, Aug 25, 2021 at 01:36:47PM +0700, Yuri Khan wrote:
> On Wed, 25 Aug 2021 at 05:16, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >
> > > -    (define-key map "\e[29~" [print])
> > > +    (define-key map "\e[29~" [menu])
> >
> > This might be right, but we need some more concrete evidence that indeed
> > `xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
> > mapped to `\e[29~` by default, or something like that.
> 
> Here is your evidence if you don’t mind a github mirror of xterm sources:
> 
> https://github.com/Maximus5/xterm/blob/master/src/input.c#L1460

Alternatively, for those who detest github and like browsing source
code in the browser (?), there's sources.debian.org:

  https://sources.debian.org/src/xterm/366-1/

I may have a look at this later, but that might take me a while.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[Andreas Schwab]

On Aug 25 2021, Ergus wrote:

> because the Print key is normally intercepted by the windows manager.

This is irrelevant.  What matters is what the terminal emulator does
with it when it sees the key.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: xterm [menu] key definition

[Ergus]

On Tue, Aug 24, 2021 at 10:53:55PM -0400, Stefan Monnier wrote:
>> Please give a look to my last email to Eli. I attached an answer from
>> the xterm maintainer respecting to that. That included a xev output and
>> his comment about this.
>[...]
>> xterm does not map either [print] or [menu] in terminfo but maps
>> kf16=\E[29~ (that's why urxvt mapped S-<f6> == <f16> == [menu] according
>> to their convention)
>
>So, IIUC he's saying that xterm emits `\E[29~` not for `Print` nor for
>`Menu` but for `F16`, right?  So maybe we should have
>
>    (define-key map "\e[29~" [f16])
>
>and then remap `f16` to `menu` maybe even via `S-f6`, but we already
>have a remapping of `f16` to `S-f4`, so it looks like a big pile of mess.
>
in xterm normally `f16` == `S-f4` because the last fkey is 12 not
10. The one with the `wrong` (or less standard) convention here is
urxvt. So our current remapping is fine in this case

>> The real question is why emacs mapped \E[29~ to [print] in xterm;
>
>This dates back to:
>
>    commit 92abb02b9b65b95807fd8fdccad10feed0dd3a96
>    Author: Karl Heuer <kwzh@gnu.org>
>    Date:   Fri Jun 9 02:31:33 1995 +0000
>
>        Initial revision
>
>so maybe some kind of xterms back then did that?
>
>FWIW, the f16 => S-f4 mapping dates back to:
>
>    commit 35b1b8abe3d3833ecb4b4cee75b7340ffb707d65
>    Author: Dan Nicolaescu <dann@ics.uci.edu>
>    Date:   Tue Apr 26 05:56:22 2005 +0000
>
>        * NEWS: Mention xterm key bindings.
>
>        * term/xterm.el (function-key-map): Fix strings for
>        {C,S,A,C-S}-f[1-4]. Use substitute-key-definition to bind
>        {C,S,A,C-S}-{f1-f12}.
>
And it is actually fine ;)

>Do you have a "menu" key which emits the `Menu` X11 event and for which
>your terminal emits `\E[29~`?
Indeed. I have the same behavior the xterm maintainer described for his
system.

>If so, which terminal is that (details
>like the version may be relevant and maybe the OS or environment)?
>
>
>        Stefan
>
xterm: 368 (but very old versions have the same behavior), OS: Debian,
Arch Linux and Open Suse different versions.

Re: xterm [menu] key definition

[Ergus]

On Wed, Aug 25, 2021 at 01:36:47PM +0700, Yuri Khan wrote:
>On Wed, 25 Aug 2021 at 05:16, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>
>> > -    (define-key map "\e[29~" [print])
>> > +    (define-key map "\e[29~" [menu])
>>
>> This might be right, but we need some more concrete evidence that indeed
>> `xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
>> mapped to `\e[29~` by default, or something like that.
>
>Here is your evidence if you don’t mind a github mirror of xterm sources:
>
>https://github.com/Maximus5/xterm/blob/master/src/input.c#L1460
>
Also line 1429.

>> That info should be available in `xterm`s source code or something like
>> that (I hoped that it would be visible in the `app-defaults/XTerm` file
>> but no).

Re: xterm [menu] key definition

[Ergus]

On Wed, Aug 25, 2021 at 08:38:46AM +0200, tomas@tuxteam.de wrote:
>On Tue, Aug 24, 2021 at 06:05:46PM -0400, Stefan Monnier wrote:
>> > I think that definitively "\e[29~" may be bound to [menu] in
>> > xterm. Somehow confirmed by the xterm maintainer in an email:
>> >
>> > "in a quick check the key which I guessed is "menu" (between the Windows
>> > key and the Ctrl key on the right-side of my keyboard) does send ^[[29~
>> > and xev says that's "Menu""
>>
>> I'm sorry but I don't understand this.  Maybe I'm just missing some of
>> the context in your email exchange, but the way it's written above gives
>> the impression that something external to xterm decides which byte
>> sequence to send when the `menu` or `print` key are used, whereas this
>> decision is made by xterm (partly influenced by things like
>> X resource settings).
>
>The latter was my point: it's exactly xterm (or whatever X terminal
>application you are using) which (possibly) converts X events to
>escape sequences.
>
>In the case of xterm this can be configured via X resources.
>
The idea is to be compatible with whatever xterm does by default right?
When there is not configuration either in xresources or in init.el.

>> FWIW, in my environment, I have a key labeled `PrtSc` which `xev` says
>> sends a `Print` event to X11, which `emacs` says sends a `print` event,
>> and which `emacs --nw` running inside `xterm` doesn't receive at all
>> (i.e. my `xterm` doesn't send any bytes in response to it).
>
>Yes, that corresponds to my findings. I guess the "Print" key was not
>a thing whenever the X resources for xterm were set up and nobody has
>bothered to change them in the mean time.
>
>Cheers
> - t

Re: xterm [menu] key definition

[Ergus]

On Wed, Aug 25, 2021 at 09:06:40AM +0200, tomas@tuxteam.de wrote:
>On Tue, Aug 24, 2021 at 05:30:03PM +0200, Ergus wrote:
>
>[...]
>
>> Hi!
>>
>> Thanks for the link! Of course we can emulate anything in xterm. The
>> question is what xterm does by default? and why we bound the menu
>> sequence to [print] instead of [menu] if emacs internally uses [menu]
>> for execute-extended-command?
>
>[...]
>
>> If xterm assumes it is a VT220; then we must assume the same when using
>> it by default (until we implement a more complex API to ask
>> xterm... (but that may be inefficient and probably don't worth it for
>> such a detail).
>
>I wouldn't expect an "xterm API". The "API" are the escape sequences :)
>
I meant an api to ask xterm about modifyFunctionKeys value for a general
solution.

For this specific case kf16=\E[29~ unconditionally; so we don't care.

  But there are some more values we actually support in gui (C-S-M-<fX>),
but not in xterm in spite of we could (modifyFunctionKeys:2 has higher
values like kf63 for those cases)... but that's another topic. Please
don't start another discussion about this without finishing the previous
(and simpler) one.

>The best one can do, I guess, is try to convince each one of the
>pseudo terminal implementors to use the same escape sequence for
>each of the non-standard keys. Perhaps there already /are/ ANSI
>(or some other standards body!) escape sequences. Perhaps not.
>
There has been a lot of work on that for decades but not a
conclusion. Any way the de-facto standard for almost all the terminal
emulators around (except rxvt) is to support whatever xterm does and
follow xterm convention. That applies to "modern" non standard features
like mouse tracking events.

>> Sometimes emacs assumes there is a [menu] key but then in xterm the same
>> key is interpreted as [print] by emacs. So a very comfortable key (for
>> those who have it) that we can't use consistently.
>
>When you say "emacs assumes" you are referring to some "GUI guts"?
>
I am referring to what emacs understand for the same key on gui or xterm.

>> Part of my intention is to minimize the "special" customization required
>> when using xterm+emacs (either in Xdefaults or in init.el); any fancy
>> more specific customization can be made latter by the user when he gets
>> familiar with the rest of the environment (GNU/Linux, xterm, emacs,
>> Elisp, the command line interface, the OS configuration system...) for
>> new users it is like getting into Narnia the fist week/month.
>
>The lowest common denominator would be to assume that there is no
>"print" (aka PrintSc) key, same for "menu", more so for "windows".
>
I started the thread asking because now I understand that in general the
[menu] key seems to emit the same than <f16>. What I don't know is if
the PrintSc does the same with a another key.

The other think clear now is that \E[29~ is NOT [print]. It is either
<f16> (from xterm's source code and terminfo) or [menu] (as menu key
seems to emit the same X event in all the cases.)

So [menu] in general seems to be a shortcut for <f16>? Probably you know
better than me about this conventions or where can be found in some X
sources?

>> I expect that most of the emacs features work and behave as similar as
>> possible when using the xterm, tty or gui without customization,
>> everything out of the box.
>
>That's because you have only seen one keyboard [2] :)
>
>BTW, just out of kicks, I tried the same experiment with the Linux
>terminal (no need for the cat, just hexdump will do, btw), and it
>also doesn't translate "print" into any escape sequence. So this
>isn't limited to X terminal emulators.
>
>If you want consistency across the terminal emulators *and*  you
>want print (and/or menu...) *and* you want it out of the box, you
>better start sending config [1] patches to all the term emulators
>out there :-)
>
>Cheers
>
>[1] https://en.wikipedia.org/wiki/ANSI_escape_code
>[2] not meant personally: we are just witnessing a curious "inversion".
>   At the time those terminal emulators were designed, there was a
>   *huge* variety of keyboards and few emulators, these days it's
>   the other way around. PC has won, and if Microsoft says "we wanna
>   have one key, because Apple also haz one", then everyone has a
>   Windows key. Actually they got two, because Apple had two).
>[3] if the implementors were as wise as xterm's and put those tidbits
>   into some config, that is
>
> - t

Re: xterm [menu] key definition

[tomas]

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

On Wed, Aug 25, 2021 at 11:32:12AM +0200, Ergus wrote:
> On Wed, Aug 25, 2021 at 09:06:40AM +0200, tomas@tuxteam.de wrote:

[...]

> >I wouldn't expect an "xterm API". The "API" are the escape sequences :)
> >
> I meant an api to ask xterm about modifyFunctionKeys value for a general
> solution.

I see.

> For this specific case kf16=\E[29~ unconditionally; so we don't care.

FWIW, I am surprised about the correspondence "F16" to "menu". For
one, most (PC) keyboards only go up to 12 [1], for the other, CUA [2]
(the only "written" standard I can come up on those things) states
that "menu" is F10. Probably some popular application started with
it or something.

> >When you say "emacs assumes" you are referring to some "GUI guts"?
> >
> I am referring to what emacs understand for the same key on gui or xterm.

OK.

> >>Part of my intention is to minimize the "special" customization required
> >>when using xterm+emacs (either in Xdefaults or in init.el); any fancy
> >>more specific customization can be made latter by the user when he gets
> >>familiar with the rest of the environment (GNU/Linux, xterm, emacs,
> >>Elisp, the command line interface, the OS configuration system...) for
> >>new users it is like getting into Narnia the fist week/month.

The best, IMO, would be to agree upon whatever escape sequences for
those newer keys and convince terminal folks to implement that. Guessing
around (aka "F16" == "menu") is only going to make the tangle deeper.
It is deep already :)

> >The lowest common denominator would be to assume that there is no
> >"print" (aka PrintSc) key, same for "menu", more so for "windows".
> >
> I started the thread asking because now I understand that in general the
> [menu] key seems to emit the same than <f16>. What I don't know is if
> the PrintSc does the same with a another key.

See above.

> The other think clear now is that \E[29~ is NOT [print]. It is either
> <f16> (from xterm's source code and terminfo) or [menu] (as menu key
> seems to emit the same X event in all the cases.)
> 
> So [menu] in general seems to be a shortcut for <f16>? Probably you know
> better than me about this conventions or where can be found in some X
> sources?

See above. I didn't know that and I can't even find hints about who
has come up with it. If xterm maps both to the same escape sequence,
perhaps one avenue could be to research whence that commit comes and
ask the person whodunit. Perhaps she's still around :-)

Who knows... perhaps that was the labeling on one particularly venerated
workstation at some MIT lab ;-)

> >>I expect that most of the emacs features work and behave as similar as
> >>possible when using the xterm, tty or gui without customization,
> >>everything out of the box.

Don't get me wrong, I understand your goal and think it's a laudable
one, but the layers you are talking to didn't know a "menu" key (or
a "print" key, for that) exists when they were born. Some people
(me included) don't have yet a "menu" key on their keyboards (nor an
F16 key). So that kind of keyboards is around and will be with us
for the next, say, 5 to 10 years. By then, we'll have a new key,
this time it'll be Google's vanity key, say "search" [4].

Relying too much on a "menu" key being there doesn't look to me like
a smart move just yet.

But, of course, getting those exotic keys into the different terms
(I'd try to include the Linux console) seems a worthy goal in
itself.

Perhaps a smart move would be to get a Linux distro (e.g. Debian)
on board? They go to some lengths in making keyboard behaviour
uniform across worlds (e.g. xterm/Linux console).

Cheers

[1] https://xkcd.com/670/
[2] https://en.wikipedia.org/wiki/Common_User_Access
[3] It's a refurb Thinkpad X230, which was introduced around 2012.
   So it's not /quite yet/ a museum piece. The last ones in refurb
   shops seem to have been flushed out pretty recently, possibly
   accelerated by pandemics.
[4] I should set up a bet.

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[Eli Zaretskii]

> Date: Tue, 24 Aug 2021 22:23:40 +0200
> From: Ergus <spacibba@aol.com>
> Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> I am not saying the current code is wrong. Just that the so called
> [print] key does not exist while the same key is seen as [menu] in gui.

We need evidence for that, and we need evidence that would explain why
xterm.el does have a translation for that key.

> I already wrote to Thomas Dickey (xterm maintainer) some days ago about
> this:

AFAIU, Thomas just says that he doesn't know of any standard xterm
assignment to the Menu key.  I already knew that, because I looked
into the xterm sequences documentation when you first reported the
issue.  So what Thomas wrote doesn't tell me anything new.

> The other change I propose is the S-<f6> instead of S-<f10> and for that
> we have all the evidence that urxvt binds the same escape sequence to
> S-<f6> (since we do:
> 
> lisp/term/rxvt.el:67:    (define-key map "\e[29~" [S-f6])

I don't think using S-F6 for this is a good idea.  F10 is our key for
menus, so S-F10 sounds a lot better.

> Otherwise we will need to request to all the compatible terminals around
> to update their terminfo.. a very long process that will delay for years
> until all the systems in all the servers will be updated.

I don't understand why would we need to request anything.  If this is
for the Print key, then since it seems that no keyboard has it, we are
good.

Re: xterm [menu] key definition

[Ergus]

On Wed, Aug 25, 2021 at 12:47:17PM +0200, tomas@tuxteam.de wrote:
>On Wed, Aug 25, 2021 at 11:32:12AM +0200, Ergus wrote:
>> On Wed, Aug 25, 2021 at 09:06:40AM +0200, tomas@tuxteam.de wrote:
>
>[...]
>
>> >I wouldn't expect an "xterm API". The "API" are the escape sequences :)
>> >
>> I meant an api to ask xterm about modifyFunctionKeys value for a general
>> solution.
>
>I see.
>
>> For this specific case kf16=\E[29~ unconditionally; so we don't care.
>
>FWIW, I am surprised about the correspondence "F16" to "menu". For
>one, most (PC) keyboards only go up to 12 [1], for the other, CUA [2]
>(the only "written" standard I can come up on those things) states
>that "menu" is F10. Probably some popular application started with
>it or something.
>
There is a miss understanding here. What is normally called menu in
  <f10> refers to the menu-bar in all the applications (usually the File
  section in the menu-bar; something emacs gui already has and works fine
  BTW)

The [menu] key we are discussing here is a completely different
beast. Associated normally with right click action. You can try on any
editor, office or graphical application around.

>> >When you say "emacs assumes" you are referring to some "GUI guts"?
>> >
>> I am referring to what emacs understand for the same key on gui or xterm.
>
>OK.
>
>> >>Part of my intention is to minimize the "special" customization required
>> >>when using xterm+emacs (either in Xdefaults or in init.el); any fancy
>> >>more specific customization can be made latter by the user when he gets
>> >>familiar with the rest of the environment (GNU/Linux, xterm, emacs,
>> >>Elisp, the command line interface, the OS configuration system...) for
>> >>new users it is like getting into Narnia the fist week/month.
>
>The best, IMO, would be to agree upon whatever escape sequences for
>those newer keys and convince terminal folks to implement that.
>
This is already in xterm give a look to the Yuri Khan email:

https://github.com/Maximus5/xterm/blob/master/src/input.c#L1429
https://github.com/Maximus5/xterm/blob/master/src/input.c#L1460

>Guessing around (aka "F16" == "menu") is only going to make the tangle
>deeper.  It is deep already :)

>> >The lowest common denominator would be to assume that there is no
>> >"print" (aka PrintSc) key, same for "menu", more so for "windows".
>> >
>> I started the thread asking because now I understand that in general the
>> [menu] key seems to emit the same than <f16>. What I don't know is if
>> the PrintSc does the same with a another key.
>
>See above.
>
>> The other think clear now is that \E[29~ is NOT [print]. It is either
>> <f16> (from xterm's source code and terminfo) or [menu] (as menu key
>> seems to emit the same X event in all the cases.)
>>
>> So [menu] in general seems to be a shortcut for <f16>? Probably you know
>> better than me about this conventions or where can be found in some X
>> sources?
>
>See above. I didn't know that and I can't even find hints about who
>has come up with it. If xterm maps both to the same escape sequence,
>perhaps one avenue could be to research whence that commit comes and
>ask the person whodunit. Perhaps she's still around :-)
>
>Who knows... perhaps that was the labeling on one particularly venerated
>workstation at some MIT lab ;-)
>
xterm maintenance is currently a single man effort; the other emulators
try to keep compatibility with it; including applications like tmux.

>> >>I expect that most of the emacs features work and behave as similar as
>> >>possible when using the xterm, tty or gui without customization,
>> >>everything out of the box.
>
>Don't get me wrong, I understand your goal and think it's a laudable
>one, but the layers you are talking to didn't know a "menu" key (or
>a "print" key, for that) exists when they were born. Some people
>(me included) don't have yet a "menu" key on their keyboards (nor an
>F16 key). So that kind of keyboards is around and will be with us
>for the next, say, 5 to 10 years. By then, we'll have a new key,
>this time it'll be Google's vanity key, say "search" [4].
>
The probably google will make it's kay an alias for fX where X is any
vale > 12 not taken already.

>Relying too much on a "menu" key being there doesn't look to me like
>a smart move just yet.
>
>But, of course, getting those exotic keys into the different terms
>(I'd try to include the Linux console) seems a worthy goal in
>itself.
>
>Perhaps a smart move would be to get a Linux distro (e.g. Debian)
>on board? They go to some lengths in making keyboard behaviour
>uniform across worlds (e.g. xterm/Linux console).
>
look at the links above.

>Cheers
>
>[1] https://xkcd.com/670/
>[2] https://en.wikipedia.org/wiki/Common_User_Access
>[3] It's a refurb Thinkpad X230, which was introduced around 2012.
>   So it's not /quite yet/ a museum piece. The last ones in refurb
>   shops seem to have been flushed out pretty recently, possibly
>   accelerated by pandemics.
>[4] I should set up a bet.
>
> - t

Re: xterm [menu] key definition

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Juri Linkov <juri@linkov.net>,  emacs-devel <emacs-devel@gnu.org>
> Date: Tue, 24 Aug 2021 22:53:55 -0400
> 
> So, IIUC he's saying that xterm emits `\E[29~` not for `Print` nor for
> `Menu` but for `F16`, right?  So maybe we should have
> 
>     (define-key map "\e[29~" [f16])
> 
> and then remap `f16` to `menu` maybe even via `S-f6`, but we already
> have a remapping of `f16` to `S-f4`, so it looks like a big pile of mess.

Yes.  Which is why I wouldn't recommend touching it with a 3-mile
pole.

>     commit 92abb02b9b65b95807fd8fdccad10feed0dd3a96
>     Author: Karl Heuer <kwzh@gnu.org>
>     Date:   Fri Jun 9 02:31:33 1995 +0000
>     
>         Initial revision
> 
> so maybe some kind of xterms back then did that?

Or maybe someone had a private configuration.

Re: xterm [menu] key definition

[Ergus]

On Wed, Aug 25, 2021 at 02:27:21PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 24 Aug 2021 22:23:40 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
>> I am not saying the current code is wrong. Just that the so called
>> [print] key does not exist while the same key is seen as [menu] in gui.
>
>We need evidence for that, and we need evidence that would explain why
>xterm.el does have a translation for that key.
>
This was my very first question on this: why Print. And why I started
this thread. In the worst case we shouldn't have mapped the escape no
anything or in the best it should be bound to <f16> for what I have
learned here.

>> I already wrote to Thomas Dickey (xterm maintainer) some days ago about
>> this:
>
>AFAIU, Thomas just says that he doesn't know of any standard xterm
>assignment to the Menu key.  I already knew that, because I looked
>into the xterm sequences documentation when you first reported the
>issue.  So what Thomas wrote doesn't tell me anything new.
>
The maps are there as mentioned before by Yuri:

https://github.com/Maximus5/xterm/blob/master/src/input.c#L1460

>> The other change I propose is the S-<f6> instead of S-<f10> and for that
>> we have all the evidence that urxvt binds the same escape sequence to
>> S-<f6> (since we do:
>>
>> lisp/term/rxvt.el:67:    (define-key map "\e[29~" [S-f6])
>
>I don't think using S-F6 for this is a good idea.  F10 is our key for
>menus, so S-F10 sounds a lot better.
>
 From the code it looks like [menu] is an alias for <f16>. rxvt
convention makes <f 10+X> = S-<fX>. xterm used a similar approach but
with 12 instead of 10; now it is more complete and with many more
bindings emacs does not support for backward compatibility... (like
C-S-letter for example)

>> Otherwise we will need to request to all the compatible terminals around
>> to update their terminfo.. a very long process that will delay for years
>> until all the systems in all the servers will be updated.
>
>I don't understand why would we need to request anything.  If this is
>for the Print key, then since it seems that no keyboard has it, we are
>good.
>
Not for the print; but for the menu. When I wrote this I didn't know it
was generally an alias for <f16>. 

Re: xterm [menu] key definition

[Gregor Zattler]

* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> * Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.

arghs, Andreas is right (message from yesterday), I forgot I
xmodeapped   PrtScr   to   Insert   so this data point is
rubbish here.

Sorry, gregor

Re: xterm [menu] key definition

[Olaf Rogalsky]

As a heavy TUI emacs and xterm user I can add to this:

Stefan Monnier writes:

>> -    (define-key map "\e[29~" [print])
>> +    (define-key map "\e[29~" [menu])
>
> This might be right, but we need some more concrete evidence that indeed
> `xterm` maps `Menu` to `\e[29~` by default and/or that `Print` is not
> mapped to `\e[29~` by default, or something like that.
>
> That info should be available in `xterm`s source code or something like
> that (I hoped that it would be visible in the `app-defaults/XTerm` file
> but no).
>
>
>         Stefan
Nowhere in the xterm sources I can find a reference to the XK_Print key
symbol. This is consistent with the obeservation, that xterm does not
act upon a PrtScn keypress / release.

On the other side, in line 1465 of xterm-snapshot/input.c the XK_Menu
key is bound to "\e[29~"
-- snip--
     MAP(XK_Menu, 29);
-- snap --

In chapter 2 on page 6 of the "VT220 Technical Manual (EK-VT-220-TM-001)" 
it is explicitely mentioned, that the "Print Screen" key has a predetermined
function:
-- snip --
Most of the top-row function keys (Figure 2-7), have functions
assigned to them by the application software in use. The following
top-row function keys have predetermined values.

* HOLD SCREEN key -- ...

* PRINT SCREEN key -- sends the text on the screen to the
  printer (CTRL-PRINT SCREEN sets or resets auto print
  mode).

* SET-UP key -- ...
-- snap --

Further, the VT220 does not have a "Menu" key, but it has a "Do" key,
which sends "\e[29\" according to table 3-4 of the VT200 Programmer
Reference Manual".

To sum it up:
* Xterm ignores the "Print" key completely (except, if one defines an
  appropriate key translation).
* Xterm sends "\e[29~" after a "Menu" key press to the application.
* VT220 terminals immediately print the screen after a "Print" key press
  and do not report the key to the application.
* VT220 terminals do not have a menu key.
* VT200 terminals report "\e[29~" after a "Do" key press.


Olaf

Re: xterm [menu] key definition

[Stefan Monnier]

>>Do you have a "menu" key which emits the `Menu` X11 event and for which
>>your terminal emits `\E[29~`?
> Indeed. I have the same behavior the xterm maintainer described for his
> system.

Duh, silly me: not sure why I didn't think of it before, but I xmodmap'd
some of my keys so as to have a `Menu` key and a `F16` key, and indeed
I see here that the both emit `\E[29~` in my xterm.

So, I'd tend to agree that mapping that `\E[29~` sequence back to
[print] is probably worse than mapping it to either [f16] or [menu].
And I suspect that a menu key is a lot more common nowadays than an
f16 key.

        Stefan

Re: xterm [menu] key definition

[Stefan Monnier]

> Yes.  Which is why I wouldn't recommend touching it with a 3-mile pole.

I took it as a dare and thus pushed Ergus's proposed change (duly
decorated with a bit of the story behind it).

It's true that it may break someone's habits somewhere but I think the
new binding at least has the virtue of having a documented justification
for it, and it may prove beneficial to a few other users.

Given the amount of discussion it raised, it feels like it deserves
a NEWS entry, yet when I tried to write it I ended up with:

    ** The escape sequence '\e[29~' in xterm is now mapped to 'menu'
    Xterm sends this sequence for both 'F16' and 'Menu' keys.
    It used to be mapped to 'print' but we couldn't find a terminal
    that uses this sequence for any kind of 'Print' key.

which seems so obscure that I'm not sure it's more helpful than harmful.
Opinion?


        Stefan

Re: xterm [menu] key definition

[chad]

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

> By then, we'll have a new key,
> this time it'll be Google's vanity key, say "search" [4].


You should definitely set up that bet, but you shouldn't get many takers --
Google's Chromebooks replace the Caps Lock key with a dedicated "search"
key more than a decade ago. The internet is now telling me that they tried
to rename it "the Everything Button" late in 2020, but surely that's some
sort of pandemic-induced lunacy (possibly the sort that is
indistinguishable from other kinds of marketing speak).

Worth noting: these devices are quite popular in education, and they don't
have a Menu key.

~Chad

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

Re: xterm [menu] key definition

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: spacibba@aol.com,  juri@linkov.net,  emacs-devel@gnu.org
> Date: Wed, 25 Aug 2021 18:41:59 -0400
> 
> > Yes.  Which is why I wouldn't recommend touching it with a 3-mile pole.
> 
> I took it as a dare and thus pushed Ergus's proposed change (duly
> decorated with a bit of the story behind it).

It would be nicer if you asked first, FWIW.

> It's true that it may break someone's habits somewhere but I think the
> new binding at least has the virtue of having a documented justification
> for it, and it may prove beneficial to a few other users.
> 
> Given the amount of discussion it raised, it feels like it deserves
> a NEWS entry, yet when I tried to write it I ended up with:
> 
>     ** The escape sequence '\e[29~' in xterm is now mapped to 'menu'
>     Xterm sends this sequence for both 'F16' and 'Menu' keys.
>     It used to be mapped to 'print' but we couldn't find a terminal
>     that uses this sequence for any kind of 'Print' key.
> 
> which seems so obscure that I'm not sure it's more helpful than harmful.
> Opinion?

Always good to have that, but it keeps silent about the main part:
what and where is that "Menu" key on a modern keyboard?

Re: xterm [menu] key definition

[tomas]

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

On Wed, Aug 25, 2021 at 10:47:23PM -0700, chad wrote:
> > By then, we'll have a new key,
> > this time it'll be Google's vanity key, say "search" [4].
> 
> 
> You should definitely set up that bet, but you shouldn't get many takers --
> Google's Chromebooks replace the Caps Lock key with a dedicated "search"
> key more than a decade ago [...]

Blargh. See, once again reality overtakes satire. I must admit that I kind
of know what a Chromebook is (and know a couple of folks possessing one),
but haven't bothered to cast a look at their keyboards.

Should teach me to overcome my feeling of disgust towards things Google
before casting any bets :)

> Worth noting: these devices are quite popular in education, and they don't
> have a Menu key.

Who's next? Amazon? Uber's broke, more or less. Palantir? ;-P

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: xterm [menu] key definition

[Ergus]

On Thu, Aug 26, 2021 at 09:55:24AM +0300, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: spacibba@aol.com,  juri@linkov.net,  emacs-devel@gnu.org
>> Date: Wed, 25 Aug 2021 18:41:59 -0400
>>
>> > Yes.  Which is why I wouldn't recommend touching it with a 3-mile pole.
>>
>> I took it as a dare and thus pushed Ergus's proposed change (duly
>> decorated with a bit of the story behind it).
>
>It would be nicer if you asked first, FWIW.
>
>> It's true that it may break someone's habits somewhere but I think the
>> new binding at least has the virtue of having a documented justification
>> for it, and it may prove beneficial to a few other users.
>>
>> Given the amount of discussion it raised, it feels like it deserves
>> a NEWS entry, yet when I tried to write it I ended up with:
>>
>>     ** The escape sequence '\e[29~' in xterm is now mapped to 'menu'
>>     Xterm sends this sequence for both 'F16' and 'Menu' keys.
>>     It used to be mapped to 'print' but we couldn't find a terminal
>>     that uses this sequence for any kind of 'Print' key.
>>
>> which seems so obscure that I'm not sure it's more helpful than harmful.
>> Opinion?
>
>Always good to have that, but it keeps silent about the main part:
>what and where is that "Menu" key on a modern keyboard?

In the button right usually between the alt and control with a hamburger
menu picture.

Re: xterm [menu] key definition

[Eli Zaretskii]

> Date: Thu, 26 Aug 2021 09:17:28 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, juri@linkov.net,
> 	emacs-devel@gnu.org
> 
> >Always good to have that, but it keeps silent about the main part:
> >what and where is that "Menu" key on a modern keyboard?
> 
> In the button right usually between the alt and control with a hamburger
> menu picture.

Don't tell me: I already know.  Tell the users in the NEWS entry.

Re: xterm [menu] key definition

[Andreas Schwab]

On Aug 25 2021, chad wrote:

>> By then, we'll have a new key,
>> this time it'll be Google's vanity key, say "search" [4].
>
>
> You should definitely set up that bet, but you shouldn't get many takers --
> Google's Chromebooks replace the Caps Lock key with a dedicated "search"
> key more than a decade ago.

Keyboards with a search key are even older than that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: xterm [menu] key definition

[Ergus]

Hi Eli:

I saw your latest change in d54ffa25bd297f9bc5791 to bind the
context-menu to [apps] on windows. I am wondering because AFAIK it is
the same physical key right?

Should we do an if-else maybe?


On Thu, Aug 26, 2021 at 09:55:24AM +0300, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: spacibba@aol.com,  juri@linkov.net,  emacs-devel@gnu.org
>> Date: Wed, 25 Aug 2021 18:41:59 -0400
>>
>> > Yes.  Which is why I wouldn't recommend touching it with a 3-mile pole.
>>
>> I took it as a dare and thus pushed Ergus's proposed change (duly
>> decorated with a bit of the story behind it).
>
>It would be nicer if you asked first, FWIW.
>
>> It's true that it may break someone's habits somewhere but I think the
>> new binding at least has the virtue of having a documented justification
>> for it, and it may prove beneficial to a few other users.
>>
>> Given the amount of discussion it raised, it feels like it deserves
>> a NEWS entry, yet when I tried to write it I ended up with:
>>
>>     ** The escape sequence '\e[29~' in xterm is now mapped to 'menu'
>>     Xterm sends this sequence for both 'F16' and 'Menu' keys.
>>     It used to be mapped to 'print' but we couldn't find a terminal
>>     that uses this sequence for any kind of 'Print' key.
>>
>> which seems so obscure that I'm not sure it's more helpful than harmful.
>> Opinion?
>
>Always good to have that, but it keeps silent about the main part:
>what and where is that "Menu" key on a modern keyboard?
>

Re: xterm [menu] key definition

[Eli Zaretskii]

> Date: Thu, 26 Aug 2021 14:52:50 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org,
> 	juri@linkov.net
> 
> I saw your latest change in d54ffa25bd297f9bc5791 to bind the
> context-menu to [apps] on windows. I am wondering because AFAIK it is
> the same physical key right?
> 
> Should we do an if-else maybe?

I considered that, but decided against it: I don't know if someone out
there does have a <menu> key on their keyboard, and if they do, I see
no reason not to open a menu when they hit that key.

Having a function bound to a key that doesn't exist never does any
harm, we have quite a few of those in Emacs.

Re: xterm [menu] key definition

[Stefan Monnier]

>>     ** The escape sequence '\e[29~' in xterm is now mapped to 'menu'
>>     Xterm sends this sequence for both 'F16' and 'Menu' keys.
>>     It used to be mapped to 'print' but we couldn't find a terminal
>>     that uses this sequence for any kind of 'Print' key.
>>
>> which seems so obscure that I'm not sure it's more helpful than harmful.
>> Opinion?
> Always good to have that,

OK, I'll add it.

> but it keeps silent about the main part: what and where is that "Menu"
> key on a modern keyboard?

A few problems here:
- I'm not sure it's relevant to this change, actually.
- I don't know where such a key might be.
  I don't have one on any of my keywords, AFAICT.
  My best guess from souvenirs of seeing other keyboards is that it'd be
  the key that is labeled with something that looks like a drop
  down menu?  Wouldn't that description be kind of tautological?
- If the keyboard is properly configured, I'd expect the user reading
  the NEWS file is the person best positioned to know where the `Menu`
  key is.


        Stefan

Re: xterm [menu] key definition

[Andreas Schwab]

On Aug 26 2021, Stefan Monnier wrote:

> - I don't know where such a key might be.
>   I don't have one on any of my keywords, AFAICT.

It is either right of the right meta key, or replaces it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: xterm [menu] key definition

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: spacibba@aol.com,  juri@linkov.net,  emacs-devel@gnu.org
> Date: Thu, 26 Aug 2021 09:59:05 -0400
> 
> > but it keeps silent about the main part: what and where is that "Menu"
> > key on a modern keyboard?
> 
> A few problems here:
> - I'm not sure it's relevant to this change, actually.

The NEWS entry talks about a key that many users will have without
knowing where it is.  So IMO it's a Good Thing to tell that in
conjunction with this change, even if it's a note in parentheses.

> - I don't know where such a key might be.
>   I don't have one on any of my keywords, AFAICT.
>   My best guess from souvenirs of seeing other keyboards is that it'd be
>   the key that is labeled with something that looks like a drop
>   down menu?  Wouldn't that description be kind of tautological?

See this short article, I hope it provides enough info to understand
what is that key:

  https://en.wikipedia.org/wiki/Menu_key