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

Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such



On Sun, 7 Nov 2010, Riku Saikkonen wrote:

(I'm just a long-time xterm user who follows the Debian bug reports
every now and then...)

Reuben Thomas <rrt@sc3d.org> writes:
On 6 November 2010 17:00, Thomas Dickey <dickey@his.com> wrote:
[about "*eightBitInput: true" being the default]
It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered
without dead-keys, etc.
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).

Here is a concrete example that I've been using for years, ever since
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).

yes - but

Similarly - I use the backarrow-key menu entry often, since Linux happens to be the only platform using DEL rather than BS.

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?

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.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Reply to: