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

Bug#651035: please decide how terminals should report Alt+letter combinations



Package: debian-policy
Version: 3.9.2.0
Severity: wishlist
X-Debbugs-Cc: Reuben Thomas <rrt@sc3d.org>, xterm@packages.debian.org, kterm@packages.debian.org, xvt@packages.debian.org, mlterm@packages.debian.org

Hi,

Reuben Thomas reported[1]:

> Please set eightBitInput: false by default so that, as in konsole and
> gnome-terminal, Alt+letter combinations work in, for example, bash,
> out of the box.

Then there was a lot of discussion.

I expect you understand the issues better than I do, but just to have
something to pick at, here's an xterm-centric summary.

"meta" and "alt" are typically the same key[2].  From now on, I will
assume that "meta" and "alt" are the same key, although I understand
that in some configurations they are not so.

There are two conventions for reporting that the meta modifier was
held: (a) precede the reported keypress with ESC, or (b) set the high
bit on the reported keypress.  The standard way to switch between
conventions is the eightBitInput resource[3].

Applications have some control of which convention is used: the
terminfo smm/rmm capabilities allow an application using the terminal
to toggle eightBitInput, overriding the user[4].

Unfortunately, applications have no standard way to discover the most
important thing, which is whether when the human operator pressed
"alt" she intended to get the "meta" behavior after all.  It is also a
common shortcut for typing alternate characters (e.g., alt+0 for the
a degree sign).

Proposal:

 i.   All terminals should send ESC for meta by default.

 ii.  The terminfo entries used for terminals provided in Debian
      should not advertise the smm/rmm capabilities.

 iii. When the smm/rmm capatibilities are not advertised, applications
      should understand that ESC means "meta" and if the user overrides
      the terminal behavior to set the high bit instead, it means that
      the input represents "alternate character", not "meta".

(ii) allows applications to play tricks with smm for the benefit of
inconsistently configured systems without breaking the behavior on
Debian.  According to this proposal, [5] is not a bug.

Reuben made a quick survey of the terminals that would have to be
patched (see [1]), and the terminals he said would need to be changed
are listed in X-Debbugs-Cc.

Thoughts?  Improvements?  Proposed wording?

Jonathan
sending this at Reuben's request.  I don't have a horse in this race
--- I use AltGr for those hard-to-type characters and have never found
much use for Meta+foo keybindings.  Comments and other help from
people affected would of course be welcome.

[1] http://bugs.debian.org/326200

[2] From xterm's control sequence reference:
    Many keyboards have keys labeled "Alt". Few have keys labeled
    "Meta". However, xterm’s default translations use the Meta
    modifier. Common keyboard configurations assign the Meta modifier
    to an "Alt" key.

[3] man xterm:
    metaSendsEscape (class MetaSendsEscape)
	If "true", Meta characters (a character combined with the Meta
	modifier key) are converted into a two-character sequence with
	the character itself preceded by ESC. This applies as well to
	function key control sequences, unless xterm sees that Meta is
	used in your key translations. If "false", Meta characters
	input from the keyboard are handled according to the
	eightBitInput resource. The default is "false."

[4] From http://bugs.debian.org/534192:
    xterm does in fact toggle the eightBitInput resource setting when
    the terminfo smm/rmm capabilities are sent.

[5] http://bugs.debian.org/574396



Reply to: