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. (I hope this is the right place to attack this problem; I discussed it with Thomas Dickey at some length to clarify my understanding of what's going on.)
Hi, Reuben Thomas wrote: Could you give a pointer or elaborate on the ramifications (perhaps an example)? Mostly I am curious. Probably in response to your request, at some point between xterm 204 and 208 it learned an alt-sends-esc menu item to toggle this at will.
xterm(1) has the details. I'd much rather have this as the default. I note that urxvt also defaults to Meta+key sending an escape (it calls the resource "meta8", and defaults to false). I have not come across any negative ramifications (obviously, it is no longer possible to produce certain characters with Meta, but there are better ways to produce most non-ASCII printing characters).
Reuben Thomas wrote: Well, no, it doesn't. What I was looking for was: "emacs -nw" and similar apps do not recognize Meta+key without this setting. and: and: Sven Joachim wrote: | Now after reading #574396 I see that with the xterm resources | | xterm*metaSendsEscape: false | xterm*eightBitInput: false | | and bash as shell meta-key combinations yield non-ASCII characters, I guess we can rely on people to keep the default of metaSendsEscape? Or perhaps a note in README.Debian would be needed to warn people. If you know what to do, please provide a patch. :) Otherwise, thoughts welcome. Thanks. Jonathan
On 5 November 2010 18:30, Jonathan Nieder <jrnieder@gmail.com> wrote: [Sorry for not understanding what you were after.] This I do not understand. "metaSendsEscape" defaults to false, and it is precisely to obtain ASCII characters (e.g. Meta-p is sent as ESC P) that one sets eightBitInput to false. With these two settings false, only 7-bit ASCII characters are sent! (Setting either metaSendsEscape to true or eightBitInput to false has the result that only 7-bit ASCII is sent.) Well, if they don't, they will have read the docs. What is wrong with patching xterm so that it defaults to eightBitInput being false rather than true, as other terminals do? I would like to see what Thomas Dickey thinks, in any case (Thomas, I hope you don't mind the Cc:; see http://bugs.debian.org/326200 for the rest of this thread.).
Reuben Thomas wrote: worth making the change anyway, but I will leave that to the emacs users. Re interaction with metaSendsEscape: of course it would not confuse new users, but would existing configurations might start to misbehave? I readily admit I do not understand the details. Bug#574396 does not look resolved and I am too ignorant to figure out the current state of things. Thanks again for reporting this --- I had been wondering why Meta+key did not work in emacs. Jonathan
probably. It's configurable at runtime (menu and escape sequence) because this is an area where half the users want it one way, the other half the other way.
Why do some users want it the other way? I'm still looking for a reason (other than the one than Jonathan quoted about bash, which seems to have things the wrong way round). This is precisely the sort of thing that would be good to add to some documentation so that it's obvious that both ways have pros and cons, and hence, not only will users be able to understand which setting they are likely to want, but also stop complaining about the default (as I am doing!). I'm also interested to know why this is the default in xterm, but not in gnome-terminal, konsole or unicode-rxvt. Is it the default in any other modern terminal?
It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc.
None of those are "modern" in the sense that you'd like to imply. In each case, the design dates back at least ten years (longer in the case of rxvt-unicode, which uses the convention from rxvt in the mid 1990s). Likewise, the "modern" issue we're discussing is emacs's use of a feature older than that.
I think that was a bad choice of word. By "modern", I meant "actively maintained at present".
In that case, gnome-terminal is debatable (it's being changed, but not maintained except in the loosest sense of the term). In either case, gnome-terminal and konsole haven't changed that part of the design for a decade.
Under what conditions? If I set my keyboard to Greek, for example, so that I'm entering only non-ASCII characters with most keystrokes, uxterm faithfully shows Greek characters (with eightBitInput: false). Sorry if I'm being obtuse, but I'd like to home in at the very least on an extremely clear explanation for the docs.
It's in the manpage (though not pointing out explicitly that the conversion is done at a point where it's useful for UTF-8).
trying to answer the question: "when is having eightBitInput: false a problem?". You answered "[when you want to get] ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc.". But when I have eightBitInput: false, I can quite happily enter non-ASCII characters (i.e. "ISO-8859-1 (or equivalents in UTF-8)"). I have tried reading the man page again, and I can't find anything that sheds light on this question. So, once more: under what conditions does setting eightBitInput: false prevent the straightforward input of non-ASCII characters?
I was referring to this paragraph, above:
eightBitInput (class EightBitInput)
If "true", Meta characters (a single-byte character combined
with the Meta modifier key) input from the keyboard are pre-
sented as a single character with the eighth bit turned on.
The terminal is put into 8-bit mode. If "false", Meta charac-
ters are converted into a two-character sequence with the char-
acter itself preceded by ESC. On startup, xterm tries to put
the terminal into 7-bit mode. The metaSendsEscape and altSend-
sEscape resources may override this. The default is "true."
which in context refers to this chunk of code in input.c
if (eightbit && (kd.nbytes == 1) && screen->input_eight_bits) {
IChar ch = CharOf(kd.strbuf[0]);
if (ch < 128) {
kd.strbuf[0] |= (char) 0x80;
TRACE(("...input shift from %d to %d (%#x to %#x)\n",
ch, CharOf(kd.strbuf[0]),
ch, CharOf(kd.strbuf[0])));
#if OPT_WIDE_CHARS
if (screen->utf8_mode) {
/*
* We could interpret the incoming code as "in the
* current locale", but it's simpler to treat it as
* a Unicode value to translate to UTF-8.
*/
ch = CharOf(kd.strbuf[0]);
kd.nbytes = 2;
kd.strbuf[0] = (char) (0xc0 | ((ch >> 6) & 0x3));
kd.strbuf[1] = (char) (0x80 | (ch & 0x3f));
TRACE(("...encoded %#x in UTF-8 as %#x,%#x\n",
ch, CharOf(kd.strbuf[0]), CharOf(kd.strbuf[1])));
}
#endif
}
eightbit = False;
}
I suppose as long as the only users you're considering are using gnome or
KDE, then that's true. (There's nothing for setting keyboard here, using
fvwm).
yes - but Similarly - I use the backarrow-key menu entry often, since Linux happens to be the only platform using DEL rather than BS. It's really up to Debian to decide what they want to do in their packages, and why. xterm's the only terminal mentioned which actually _implements_ meta mode, which seems to be confused with sending escape characters. Since sending escape characters seems to be the only validly-expressed goal, that's done better by the metaSendsEscape resource. I made that a menu entry, so it could be changed back and forth.
(I'm just a long-time xterm user who follows the Debian bug reports every now and then...) Reuben Thomas <rrt@sc3d.org> writes: [about "*eightBitInput: true" being the default] I first learned it: If I type Alt-0, I get the DEGREE SIGN character '°'. However, if I run xterm -xrm '*eightBitInput: false' then Alt-0 gives me ^[0 (i.e. ESC + 0) instead. Same with, e.g., Alt-7 to get the MIDDLE DOT '·' or Alt-w to get the DIVISION SIGN '÷' or Alt-Shift-w to get the MULTIPLICATION SIGN '×'. I can of course (as I learned later) get the degree sign character also using "Compose ^ 0" (presuming that I have a Compose key configured and, of course, that I know about this). But Alt-0 is quicker to type and (it seems to me) easier to remember. Of course, the downside is that Alt-0 in Emacs gives the ° character instead of the Emacs command M-0 (e.g., Alt-7 * gives me either '*******' or '·*' depending on the eightBitInput setting). In Emacs running in its own X window (instead of under xterm): Alt-7 * gives '*******' which would suggest using *eightBitInput: false to be consistent. However, it is not really completely consistent using either value of eightBitInput: C-q Alt-7 gives '·' in Emacs running under an X window C-q Alt-7 gives '·' in Emacs under xterm with *eightBitInput: true C-q Alt-7 gives '^[*' in Emacs under xterm with *eightBitInput: false So the behaviour of C-q Alt-7 would suggest *eightBitInput: true (especially since there are fewer ways of getting '·' with eightBitInput: false). I guess C-q Alt-7 giving '·' in an X window is a decision made by Emacs developers sometime in the past (in an Emacs X window, it is of course more useful to get '·' than '^[*' from this special command). So both *eightBitInput: false and *eightBitInput: true are useful in their own ways. This probably really is a user preference (for power users, at least), so I guess both *eightBitInput: true and *eightBitInput: false are going to annoy some users. However, I guess it would be useful for Debian to be consistent about this in all the terminals it ships (including the Linux and kFreeBSD text consoles as well as X terminal emulators). I'm personally not really sure which option I prefer: I'm used to the Debian default of *eightBitInput: true, and use it every now and then (as I described above), but it's also annoying that I have to use ESC in Emacs so much... Maybe *eightBitInput: false would be less surprising for new users of Emacs under xterm (since Alt-x would work as M-x, and not many people seem to know that, e.g., Alt-0 could be the degree sign). I suppose this clearly is not something that should be changed while in a freeze, especially since xterm in Debian has had the current behaviour for so many years. But perhaps it would be possible to coordinate a consistent behaviour for all the terminals in the next Debian release after this frozen one?
Hi again,
Riku Saikkonen wrote:
That sounded sensible to my innocent bystander ears. :) Reuben, would
you be willing to coordinate this (or do you know anyone who would be)?
That means:
1. Finding out what the major terminals in Debian currently do. If
xterm is not the odd man out, finding a consensus, for example by
reporting a bug against the debian-policy package with
X-Debbugs-Cc pointing to the relevant maintainers.
2. Proposing a patch for xterm bug#326200.
3. Proposing a patch for bash bug#574396.
4. Being ready to help people respond to bugs that arise from the
above.
If one wants to make this change and find relevant bugs in time for
wheezy, now's probably the time.
Thanks and hope that helps,
Jonathan
I don't actually use Debian at present; I use Ubuntu. That may limit my usefulness. However, at the very least, I'd be happy to try doing this: What counts as "the major terminals"? Obviously xterm, uxterm, gnome-terminal, konsole, and which others? Should I use popcon to find out (how?)? Or can we draw up an arbitrary list? Basic use of apt-cache search and grep suggests the following: gnome-terminal xterm eterm evilvte guake kterm lxterminal mlterm mlterm-tiny mrxvt mrxvt-cjk mrxvt-mini pterm roxterm rxvt rxvt-beta rxvt-ml rxvt-unicode rxvt-unicode-256color rxvt-unicode-lite sakura terminal.app terminator vala-terminal wterm wterm-ml xfce4-terminal xvt konsole I'd be quite happy to whip through that lot and see what the defaults are.
Reuben Thomas wrote: Thanks. Unless the Ubuntu maintainers want to make this change as a differentiating feature instead of pushing it in Debian (and I can't see the point to that), I think you are still affected by what happens in Debian anyway. [...] Yep, that seems like a sensible list. Great. It might even be possible to automate that with some ncurses magic, but don't ask me how. :)
Of course, and that is why I filed the bug in Debian. The point I'm making is that I've tested Ubuntu packages on an Ubuntu oneiric system, not Debian packages on a Debian system. Here are the results of my tests: Xterm & friends: xterm: true (eightBitInput resource) kterm: true (eightBitInput resource) mlterm: true (--meta=esc command line option) xvt: true (-7 command line option) GNUStep (I imagine that GNUStep standards mean you wouldn't want to change the default): terminal.app: true (no option, but can remap keys) rxvt & friends: rxvt: false (meta8 resource) rxvt-unicode: false (meta8 resource) mrxvt: false (-m8/+m8 command line option) wterm: false (-meta8 command line option) aterm: false (-meta8 command line option) libvte-based emulators (for at least some of these may need to select preference “Keyboard→Disable other menu shortcut keys”, otherwise Alt+some letters opens menu; again, this default probably shouldn't change): gnome-terminal: false (no option) evilvte: false (no option) guake: false (no option) lxterminal: false (no option) roxterm: false (no option) sakura: false (no option) terminator: false (no option) vala-terminal: false (no option) xfce4-terminal: false (no option) konsole: false (no option) Others: eterm: false (--meta8 command line option) pterm: false (no option) In other words, only xterm, kterm, mlterm and xvt would require a patch, and in all cases it would be simply to reverse an existing default setting.
For xterm, kterm and xvt, the simplest thing to do would seem to be to add a suitable default resource to the various /etc/X11/app-defaults files. (xvt doesn't install such a file, but since it respects resources it presumably could.) For mlterm a simple patch to reverse the default would be required. How does this sound?
Reuben Thomas wrote: Sounds sensible to me. I think the first step is to file a bug against debian-policy with X-Debbugs-Cc pointing to the relevant maintainers, so the new Right Thing To Do™ can be documented to avoid future regressions. It feels awkward to give advice like this without doing anything myself. Please don't take it as authoritative --- what the people actually working on these packages are happy with is more important. Many thanks, Jonathan
really have the mental space to do something delicate like that which I've never done before. I think the advice is simple enough: add an eightBitInput: true resource to each term's default resources file, plus a default-negating patch to mlterm.
Reuben Thomas wrote:
Reuben Thomas <rrt@sc3d.org> writes: behaviors: the text consoles of the kernels supported by Debian. Linux text console: false (That is, by default Alt+w sends ^[w and not the DIVISION SIGN character, at least on my i386 system. This appears to be changeable via setmetamode(1), which uses the KDSKBMETA ioctl documented in console_ioctl(4). I did not find the smm or rmm terminfo entries for linux, nor code that would implement such escape sequences to change the meta mode. I think the default is set in #define KBD_DEFMODE in linux/drivers/char/keyboard.c (search in the file for the two occurrences of "VC_META").) I don't have a Debian GNU/kFreeBSD system to test on, nor Debian GNU/Hurd. Maybe someone else could test those for completeness?
unimplemented (as are most of the cases mentioned)
man terminfo(5):
If the terminal has a ``meta key'' which acts as a shift key, setting
the 8th bit of any character transmitted, this fact can be indicated
with km. Otherwise, software will assume that the 8th bit is parity
and it will usually be cleared. If strings exist to turn this ``meta
mode'' on and off, they can be given as smm and rmm.
unimplemented (as are most of the cases mentioned)
man terminfo(5):
If the terminal has a ``meta key'' which acts as a shift key, setting
the 8th bit of any character transmitted, this fact can be indicated
with km. Otherwise, software will assume that the 8th bit is parity
and it will usually be cleared. If strings exist to turn this ``meta
mode'' on and off, they can be given as smm and rmm.
There are two relevant issues:
(a) how to configure a terminal to send an escape character as
a prefix.
(b) how to configure a terminal to handle meta-key processing.
Notwithstanding the confusion arising from bash, they're different.
Even if all of the terminals are (for the ones that handle this),
configured to support (a), there are still functional differences
in (a), which are well-known, having been the subject of other bug
reports.
For (b), it appears that xterm (and some others such as kterm which
derive from the same source) are the only ones that implement the
meta key feature as documented in terminfo(5). Specifically, the
features is not implemented in any source based on rxvt, vte, putty,
or kde.
In xterm #277, I've addressed (b):
eightBitMeta (class EightBitMeta)
This controls the way xterm modifies the eighth bit of a sin-
gle-byte key when the eightBitInput resource is set. The
default is "locale".
The resource value is a string, evaluated as a boolean after
startup.
false
The key is sent unmodified.
locale
The key is modified only if the locale uses eight-bit
encoding.
true The key is sent modified.
never
The key is always sent unmodified.
Except for the never choice, xterm honors the terminfo capabil-
ities smm (set meta mode) and rmm (reset meta mode), allowing
the feature to be turned on or off dynamically.
If eightBitMeta is enabled when the locale uses UTF-8, xterm
encodes the value as UTF-8 (since patch #183 in 2003).
There are two relevant issues:
(a) how to configure a terminal to send an escape character as
a prefix.
(b) how to configure a terminal to handle meta-key processing.
Notwithstanding the confusion arising from bash, they're different.
Even if all of the terminals are (for the ones that handle this),
configured to support (a), there are still functional differences
in (a), which are well-known, having been the subject of other bug
reports.
For (b), it appears that xterm (and some others such as kterm which
derive from the same source) are the only ones that implement the
meta key feature as documented in terminfo(5). Specifically, the
features is not implemented in any source based on rxvt, vte, putty,
or kde.
In xterm #277, I've addressed (b):
eightBitMeta (class EightBitMeta)
This controls the way xterm modifies the eighth bit of a sin-
gle-byte key when the eightBitInput resource is set. The
default is "locale".
The resource value is a string, evaluated as a boolean after
startup.
false
The key is sent unmodified.
locale
The key is modified only if the locale uses eight-bit
encoding.
true The key is sent modified.
never
The key is always sent unmodified.
Except for the never choice, xterm honors the terminfo capabil-
ities smm (set meta mode) and rmm (reset meta mode), allowing
the feature to be turned on or off dynamically.
If eightBitMeta is enabled when the locale uses UTF-8, xterm
encodes the value as UTF-8 (since patch #183 in 2003).
Hi, FWIW: the BSD wscons(4) text console does the same, and it always annoys me that Linux’ doesn’t… bye, //mirabilos