[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

(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
  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?

-=- Rjs -=- rjs@cs.hut.fi, Riku.Saikkonen@hut.fi

Reply to: