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