Re: use of graphics characters recently disabled in xterm

2017-09-12 Thread Theodore Kilgore


Thomas,

Thank you very much. I was not aware uxterm and I will look into it.

However, to compound the ironies of this situation, I live in Auburn, 
Alabama. Hurricane Irma blew into town yesterday afternoon. By then, it 
was not much of a storm any more. My original suspicion was almost right, 
that it would miss us altogether and get pushed to the east because we had 
been in a high pressure area with coolish temperatures. But, I suspect, 
the previous high pressure and cool weather are what did in the hurricane 
so quickly.


But Irma did turn my power off for four hours yesterday by dropping a tree 
somewhere in the neighborhood, leaving the street without electricity. The 
computer was on when this happened. And four hours later when it was 
re-started, the problem we have been discussing had gone away. I do not 
know how this could be the case because to reboot after an upgrade is 
supposed to be a Windows thing, not required in Linux except to replace 
the kernel.


With due acknowledgement of the human suffering caused by Irma, it seems 
that an old saying is justified again. It's an ill wind indeed that blows 
no one any good.


So, let's close this thread for now, and reopen it only if the problem 
comes back.


Cheers,

Theodore Kilgore


On Tue, 12 Sep 2017, Thomas Dickey wrote:


On Mon, Sep 11, 2017 at 11:03:23AM -0500, Theodore Kilgore wrote:


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=
---


Those settings should work (the important ones are LC_ALL and LC_CTYPE, LANG).


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


Line-Drawing is normally turned off because a well-designed font will
look better than xterm's built-in equivalent (since it may use thick
lines for large characters).

UTF-8 Fonts would be turned on if you used the "uxterm" shell script
to setup xterm, which gives better coverage of Unicode.

UTF-8 Encoding isn't on either because there's some problem with the locale
_tables_ or due to a resource setting.  If you have "appres" installed,
you may see the problem in the output of "appres XTerm".


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.


I'd try using the "uxterm" script (it's supposed to do most of the
fixes you need).

--
Thomas E. Dickey 
http://invisible-island.net
ftp://ftp.invisible-island.net


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


Re: use of graphics characters recently disabled in xterm

2017-09-12 Thread Thomas Dickey
On Mon, Sep 11, 2017 at 11:03:23AM -0500, Theodore Kilgore wrote:
> 
> 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=
> ---

Those settings should work (the important ones are LC_ALL and LC_CTYPE, LANG).
 
> 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

Line-Drawing is normally turned off because a well-designed font will
look better than xterm's built-in equivalent (since it may use thick
lines for large characters).

UTF-8 Fonts would be turned on if you used the "uxterm" shell script
to setup xterm, which gives better coverage of Unicode.

UTF-8 Encoding isn't on either because there's some problem with the locale
_tables_ or due to a resource setting.  If you have "appres" installed,
you may see the problem in the output of "appres XTerm".

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

I'd try using the "uxterm" script (it's supposed to do most of the
fixes you need).

-- 
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: use of graphics characters recently disabled in xterm

2017-09-11 Thread Joerg Thuemmler

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\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

Re: use of graphics characters recently disabled in xterm

2017-09-11 Thread 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\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, 

Re: use of graphics characters recently disabled in xterm

2017-09-10 Thread 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

2017-09-10 Thread 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: use of graphics characters recently disabled in xterm

2017-09-09 Thread William
I had this (or something similar) happen some years back probably with 
Konsole on an Kubuntu installation. Probably AMD cpu also.


I cannot remember now what I did to fix. Possibly put the characters 
into mc.ini.


Will


On 09/09/17 10:57, 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 
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.


Oh, I should also say that this happens only on my home machine which 
has an AMD processor and on-board ATI video. It does not happen on the 
machine at my office, which is an Intel CPU with on-board Intel 
graphics. The two machines both run slackware-64-current and as far as 
I know the two machines have exactly the same list of distro packages 
installed.


The only thing I can think of is that something in the options for 
xterm needs to be changed, but I have no clue about what that magic 
option might be. Or, it could possibly be some library which deals 
with graphics and is somehow broken on an AMD-based machine.


I am pretty much guessing, of course, but to fix the problem would be 
nice. Anyone have an idea?


Theodore Kilgore
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc


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


Re: use of graphics characters recently disabled in xterm

2017-09-09 Thread Adam Pribyl

On Fri, 8 Sep 2017, Theodore Kilgore wrote:



The only thing I can think of is that something in the options for xterm 
needs to be changed, but I have no clue about what that magic option might 
be. Or, it could possibly be some library which deals with graphics and is 
somehow broken on an AMD-based machine.


I am pretty much guessing, of course, but to fix the problem would be nice. 
Anyone have an idea?


Check your TERM (echo $TERM) variable in xterm. Most probably the 
slackware switched to xterm-256color or something. Also check the output 
of "locale" and check the Ctrl-right click menu in xterm for some font 
settings.




Theodore Kilgore



Adam Pribyl

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


Re: use of graphics characters recently disabled in xterm

2017-09-09 Thread Yury V. Zaytsev

On Fri, 8 Sep 2017, Theodore Kilgore wrote:

The only thing I can think of is that something in the options for xterm 
needs to be changed, but I have no clue about what that magic option might 
be. Or, it could possibly be some library which deals with graphics and is 
somehow broken on an AMD-based machine.


This must have something to do either with your locale settings, or with 
fonts that are used by xterm, but certainly not with the graphics 
libraries or hardware, way too low-level.


In any case, the next debugging step that I would recommend is to create a 
brand new user on your machine, log in as this user in the graphical mode, 
start xterm and try mc. Depending on the results, decide on what to do 
next. The new user can be deleted afterwards with no traces left.


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