Re: use of graphics characters recently disabled in xterm

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 <[email protected]>
>> 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
_______________________________________________
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc