all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ergus <spacibba@aol.com>
To: tomas@tuxteam.de
Cc: emacs-devel@gnu.org
Subject: Re: xterm [menu] key definition
Date: Wed, 25 Aug 2021 11:32:12 +0200	[thread overview]
Message-ID: <20210825093212.jliurmm3j2x7yvyk@Ergus> (raw)
In-Reply-To: <20210825070640.GB11313@tuxteam.de>

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





  reply	other threads:[~2021-08-25  9:32 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
2021-08-19  2:47 ` xterm [menu] key definition Ergus
2021-08-23 17:53   ` Ergus
2021-08-24  6:37   ` Juri Linkov
2021-08-24  8:19     ` Ergus
2021-08-24  8:34       ` tomas
2021-08-24  9:17         ` Ergus
2021-08-24 10:03           ` Andreas Schwab
2021-08-24 11:00           ` tomas
2021-08-24 15:30             ` Ergus
2021-08-25  7:06               ` tomas
2021-08-25  9:32                 ` Ergus [this message]
2021-08-25 10:47                   ` tomas
2021-08-25 11:31                     ` Ergus
2021-08-26  5:47                     ` chad
2021-08-26  7:14                       ` tomas
2021-08-26  8:16                       ` Andreas Schwab
2021-08-24  8:34       ` Andreas Schwab
2021-08-24  9:07         ` Ergus
2021-08-24 22:05       ` Stefan Monnier
2021-08-25  6:38         ` tomas
2021-08-25  9:04           ` Ergus
2021-08-24 16:40     ` Ergus via Emacs development discussions.
2021-08-24 17:28       ` Eli Zaretskii
2021-08-24 18:09         ` Juri Linkov
2021-08-24 20:23         ` Ergus
2021-08-25 11:27           ` Eli Zaretskii
2021-08-25 11:53             ` Ergus
2021-08-24 22:16       ` Stefan Monnier
2021-08-24 23:20         ` Ergus
2021-08-25  2:53           ` Stefan Monnier
2021-08-25  8:58             ` Ergus
2021-08-25 14:13               ` Stefan Monnier
2021-08-25 11:34             ` Eli Zaretskii
2021-08-25 22:41               ` Stefan Monnier
2021-08-26  6:55                 ` Eli Zaretskii
2021-08-26  7:17                   ` Ergus
2021-08-26  7:23                     ` Eli Zaretskii
2021-08-26 12:52                   ` Ergus
2021-08-26 13:48                     ` Eli Zaretskii
2021-08-26 13:59                   ` Stefan Monnier
2021-08-26 14:51                     ` Andreas Schwab
2021-08-26 15:52                     ` Eli Zaretskii
2021-08-25  7:10           ` tomas
2021-08-25  8:02           ` Andreas Schwab
2021-08-25  6:36         ` Yuri Khan
2021-08-25  7:17           ` tomas
2021-08-25  9:00           ` Ergus
2021-08-25 14:01         ` Olaf Rogalsky
     [not found]   ` <87k0kcovp4.fsf@no.workgroup>
2021-08-25 12:09     ` Gregor Zattler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210825093212.jliurmm3j2x7yvyk@Ergus \
    --to=spacibba@aol.com \
    --cc=emacs-devel@gnu.org \
    --cc=tomas@tuxteam.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.