Re: use of graphics characters recently disabled in xterm

Am 11.09.2017 um 18:03 schrieb Theodore Kilgore:


The output of locale (invoked without arguments) is as follows, between
the two lines.

kilgota@khayyam:/etc/X11/app-defaults$ locale |less

Now, what is also interesting is that after reading closely the man page
for xterm and trying to make sense of it, I discovered that there are
two things which one can do in order to make the settings in an xterm to
be visible. There are two things called "menu" and one can get to them
by holding down a control key and clicking either the left or the right
mouse button while the pointer is in the window. The right button click
displays a window called "VT fonts" and it contains relevant
information. Unfortunately, I do not know if it is possible to
mouse-copy its contents because it goes away immediately as soon as one
lets go of that button. This VT Font menu depicts the current settings
by a check mark in front of whichever setting is highlighted. One can
scroll down that menu and change a setting by hand, by leaving the
highlighting on top of that particular setting and then closing the
menu. Also, the settings in this menu are specific to the xterm which
has been opened. They remain as they previously were if one opens
another xterm next to the one in which the settings have already been
set by hand. And in the same manner those settings cannot be saved for
another X session. A further description of possibly relevant settings
in this window follows.

There is a line called "line-drawing characters" which is *not* turned
on. It is unclear to me what this does (see the xterm man page for an
explanation, which is not totally clear). What it might be doing is
turning on the line-drawing characters from X itself, to replace the
ones which are provided by the font, or alternatively what it might be
doing is enabling the line-drawing characters which are already provided
by the font. As I said, the explanation in the man page is not very
clear and these two meanings are obviously opposite to each other. In
any event, to toggle this setting on and off all by itself, when other
settings are not changed, seems to have no effect.

There are also lines in that menu for UTF-8 Encoding, UTF-8 Fonts, and
UTF-8 Titles. These are also apparently not turned on (no check marks in

Setting UTF-Encoding *and* UTF-8 Fonts *and* Line-Drawing Characters all
to be on seems to solve the problem. But by default all three of them
are turned off.

Why are all three of these settings turned off by default? I have no
idea. In particular, this is even more amazing because it seems to be in
conflict with the locale settings displayed above. So, in order to get
back to the bottom of this problem it seems to me that what needs to be
done is to set up a way to turn all three of these settings on. However,
I do not know what I am supposed to do in order to carry that out.
Change some configuration file, I suppose, or else do a local override.
But I suspect that the settings are already set correctly in some file
somewhere and that somehow the settings in that file are being ignored.

Theodore Kilgore

On Sun, 10 Sep 2017, Thomas Dickey wrote:

On Sun, Sep 10, 2017 at 01:58:38PM -0500, Theodore Kilgore wrote:

On Sun, 10 Sep 2017, Thomas Dickey wrote:

On Fri, Sep 08, 2017 at 05:57:33PM -0500, Theodore Kilgore wrote:

I have recently done some upgrades, keeping current with
slackware-64-current. And what has happened is that suddenly MC
started to print funny characters around the panels instead of

a screenshot would help:

In the screenshot, I see a single character, which is always the same
226 (octal 342).

That happens to be the first byte of the UTF-8 encoding for the various
line-drawing characters which is odd, since they are all 3-bytes:

    \342\224\214    0x250c    /* upper left corner */
    \342\224\224    0x2514    /* lower left corner */
    \342\224\220    0x2510    /* upper right corner */
    \342\224\230    0x2518    /* lower right corner */
    \342\224\234    0x251c    /* tee pointing left */
    \342\224\244    0x2524    /* tee pointing right */
    \342\224\264    0x2534    /* tee pointing up */
    \342\224\254    0x252c    /* tee pointing down */
    \342\224\200    0x2500    /* horizontal line */
    \342\224\202    0x2502    /* vertical line */
    \342\224\274    0x253c    /* large plus or crossover */

Those 22x's are mostly in the C1 control range (200 to 237 octal),
so it's possible that xterm is not using UTF-8 encoding, and simply
discarding the control characters (with an occasional glitch for
the tee's and plus signs).


+ If it's 2-3 characters rather than a single character, that
indicates that
xterm's not using UTF-8 (a resource problem perhaps).  You would set in
the right-menu-mouse menu that "UTF-8 Encoding" is not checked.

This could be the problem, even though X is completely up to date
and the file /etc/X11/app-defaults/XTerm does contain the following

*fontMenu*utf8-mode*Label:      UTF-8 Encoding
*fontMenu*utf8-fonts*Label:     UTF-8 Fonts
*fontMenu*utf8-title*Label:     UTF-8 Titles

What is interesting about this is the following. Yesterday evening I
did some experimenting. The xterm man page contains the following

       -lc     Turn on support of various encodings according to the
               locale setting, i.e., LC_ALL, LC_CTYPE, or LANG
               variables.  This is achieved by turning on UTF-8 mode
and by
               invoking luit for conversion between locale encodings and
               UTF-8.  (luit is not invoked in UTF-8 locales.)  This
               corresponds to the locale resource.

               The actual list of encodings which are supported is
               by luit.  Consult the luit manual page for further

               See also the discussion of the -u8 option which
supports UTF-8

       +lc     Turn off support of automatic selection of locale
               Conventional 8bit mode or, in UTF-8 locales or with
-u8 option,
               UTF-8 mode will be used.

Both of the above options restore MC to sane behavior.

That's saying that turning the switch on or off has the same effect :-(

Aksi there is the -u8 option.

       -u8     This option sets the utf8 resource.  When utf8 is
set, xterm
               interprets incoming data as UTF-8.  This sets the
               resource as a side-effect, but the UTF-8 mode set by this
               option prevents it from being turned off.  If you must
               UTF-8 encoding on and off, use the -wc option or the
               corresponding wideChars resource, rather than the -u8

               This option and the utf8 resource are overridden by
the -lc and
               -en options and locale resource.  That is, if xterm
has been
               compiled to support luit, and the locale resource is not
               false this option is ignored.  We recommend using the -lc
               option or the locale: true resource in UTF-8 locales when
               your operating system supports locale, or -en UTF-8
option or
               the locale: UTF-8 resource when your operating system
               not support locale.

The option xterm -en UTF-8 works, too, as it is supposed to. I also
tried I tested each one of the above options by opening an xterm and
then typing the command. When I hit "enter" it created a new window
beside the old one, and then opened MC in the new window.

The option xterm -en UTF-8 works, too, as it is supposed to. I also
using "luit" as the sterm man page suggests to do, but that option
to be superfluous.

So, what I could do about this is to associate one of these options
with the command to fire up an xterm in my configuration file for my
manager, which is fvwm2. But, alas, I just now tried all of them and
none of them work when they are put into the $HOME/.fvwm/.fvwmrc
file. So, now I am really puzzled. They all work as stated if I fire
them up from another xterm, but none of them work when put into the
fvwm configuration file. And using the same configuration file with
the same window manager on my office machine (which has the Intel
video in it) I do not have these problems. Mystery.

What does "locale" tell you?

It's also possible that locale variables are set, but the locale tables
are not installed.  When that happens, some applications (and shells)
will complain about it.  If you're running everything from a desktop,
it's easy to overlook those warning messages.

Morever, what I still cannot figure out in the first place is why
this started to happen. It appears to me that UTF-8 is the default
in the XTerm app defaults file, and clearly it is also set so in the
console because in the console there is not any problem. So, I
cannot help but to wonder where exactly the problem is.

It's the default if your locale uses UTF-8 encoding.  Otherwise,
it may turn on UTF-8 encoding if it is able to use luit to convert
between your locale's encoding and UTF-8.

Theodore Kilgore

+ If it's a single character, then that could be a problem with the
driver (or fontconfig, etc).  For this, you could try using xterm's
built-in line-drawing using the "Line-Drawing Characters" menu option.

printing vertical and horizontal lines. This happens only in an
xterm, not in the console terminal where all remains OK. The command
mc -a replaces the straight lines with vertical and horizontal
dashes, but that does not look nearly so nice.

Thomas E. Dickey <dickey invisible-island net>

mc mailing list


is there a must using xterm?

I myself use urxvt (unicode-rxvt), there you can easily give a -fn <font> argument according to your locale (I use an ISO one, no unicode and so a non-unicode font. but should be no problem to do it vice versa).

I always found xterm somehow special to customize, although a lot of cmdline args are the same for both xterm and urxvt. (funnny: urvt has the same kind of tiny menu pressing ctrl and klicking middle mouse key).




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