Re: use of graphics characters recently disabled in xterm

[Thomas Dickey]

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\2140x250c  /* upper left corner */
\342\224\2240x2514  /* lower left corner */
\342\224\2200x2510  /* upper right corner */
\342\224\2300x2518  /* lower right corner */
\342\224\2340x251c  /* tee pointing left */
\342\224\2440x2524  /* tee pointing right */
\342\224\2640x2534  /* tee pointing up */
\342\224\2540x252c  /* tee pointing down */
\342\224\2000x2500  /* horizontal line */
\342\224\2020x2502  /* vertical line */
\342\224\2740x253c  /* 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 

Re: use of graphics characters recently disabled in xterm

[Thomas Dickey]

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:

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

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


signature.asc
Description: Digital signature
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mcedit: undo warning

[Yury V. Zaytsev]

On Sun, 10 Sep 2017, Dmitry L. wrote:

It looks like a bug for me. In mcedit I have next warning when remove 
block of text (when length is large than 16384): "Block is large, you 
may not be able to undo this action"


But actually I can undo only when remove block of text with length less 
than 8190.


So, when I remove block of text where 8190 <= length <=16384 I don't get 
any warning and can't undo this action.


That's correct, the condition in question is

(end_mark - start_mark) > option_max_undo / 2

where

int option_max_undo = 32768

It looks like it should be option_max_undo / 4, according to your 
observation, but I have no idea why and how come...


In any case, please report this bug on the Trac, because otherwise this 
will get lost on the list.


--
Sincerely yours,
Yury V. Zaytsev
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

mcedit: undo warning

[Dmitry L.]

Hello!

It looks like a bug for me.
In mcedit I have next warning when remove block of text (when length
is large than 16384): "Block is large, you may not be able to undo
this action"

But actually I can undo only when remove block of text with length
less than 8190.

So, when I remove block of text where 8190 <= length <=16384 I don't
get any warning and can't undo this action.

PS: I'm using MCEdit 4.8.19 from Arch Linux repos

-- 
//wbr, Dmitry L.
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc