[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, Reuben Thomas wrote:

On 7 November 2010 16:52, Thomas Dickey <dickey@his.com> wrote:
On Sun, 7 Nov 2010, Reuben Thomas wrote:

On 6 November 2010 17:00, Thomas Dickey <dickey@his.com> wrote:

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).
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).

Sorry, I must be being stupid, but can you please be explicit? I am

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;
            }

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 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).

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



Reply to: