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 <dic...@invisible-island.net>
http://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: Digital signature

_______________________________________________
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Reply via email to