emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xterm [menu] key definition


From: tomas
Subject: Re: xterm [menu] key definition
Date: Wed, 25 Aug 2021 09:06:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]