Re: use of graphics characters recently disabled in xterm

[Joerg Thuemmler <listen vordruckleitverlag de>]

Am 11.09.2017 um 18:03 schrieb Theodore Kilgore:
> Thomas,
>
> The output of locale (invoked without arguments) is as follows, between
> the two lines.
>
> --------------------------------------------------------------------
> kilgota@khayyam:/etc/X11/app-defaults$ locale |less
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE=C
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
> -------------------------------------------------------------------
>
> 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
> front).
>
> 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
> > value:
> > 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).
> >
> > > Attached.
> > >
> > > > + 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
> > > lines:
> > >
> > > *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
> > > options
> > >
> > >
> > >        -lc     Turn on support of various encodings according to the
> > > users'
> > >                locale setting, i.e., LC_ALL, LC_CTYPE, or LANG
> > > environment
> > >                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
> > > determined
> > >                by luit.  Consult the luit manual page for further
> > > details.
> > >
> > >                See also the discussion of the -u8 option which
> > > supports UTF-8
> > >                locales.
> > >
> > >        +lc     Turn off support of automatic selection of locale
> > > encodings.
> > >                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
> > > wideChars
> > >                resource as a side-effect, but the UTF-8 mode set by this
> > >                option prevents it from being turned off.  If you must
> > > turn
> > >                UTF-8 encoding on and off, use the -wc option or the
> > >                corresponding wideChars resource, rather than the -u8
> > > option.
> > >
> > >                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
> > > does
> > >                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
> > > tried
> > > using "luit" as the sterm man page suggests to do, but that option
> > > appears
> > > 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
> > > window
> > > 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
> > > > video
> > > > 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>
> > http://invisible-island.net
> > ftp://ftp.invisible-island.net
> _______________________________________________
> mc mailing list
> https://mail.gnome.org/mailman/listinfo/mc

Hi,

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

cu

jth

--
www.teddylinx.de