Red Hat Bugzilla – Bug 174662
mc looks horrible in xterm, bad in other terminals
Last modified: 2013-07-02 19:11:46 EDT
Try starting the current devel/rawhide mc in an xterm and you'll know what I
mean. The scrollbars also are wrong in konsole, gnome-terminal and on the
console, but less wrong then in the one and only real xterm.
I've rebuild mc using the system installed slang-2.x instead of the one included
with mc and things are much better now, the scroll bar still isnot completly
right (arrowds and locacation are drawn as spaces), and thus no way as pretty as
it used to be the last few releases, but much better!
I've also reenabled the gpm/console mouse, works fine why is/was that disabled?
The gpm/console mouse support was disabled because it hangs mc randomly and
there's no will to fix it very soon on the gpm side. For more info read bug
168076 or bug 163061.
Switching to the external slang-2 is planned in the next build as we have slang
updated to 2.0.5 since the last week. The mc doesn't look so bad in xterm for
me, except the "squares" instead of arrows in scrollbars because the default
xterm font isn't very much UTF-8 aware. In gnome-terminal and konsole it looks
just fine if you set inproportional font such as console8x16 or Luxi Mono. Some
other fonts render the UTF-8 characters too wide or has other problems. This is
not a fault of mc anyway.
I'll reenable the gpm support on the compile time, but disable it in wrapper
scripts so that users won't need to recompile mc when they want gpm support.
Unfortunatelly it's not possible as the -d option in mc-wrapper only allows to
disable mouse support completely what we don't want because the xterm mouse
support would be disabled by it as well.
Leaving gpm support disabled on compile time.
Created attachment 121685 [details]
screenshot of mc on my xterm
I've attached a screenshot of the way mc looks in my xterm. My xterm and system
is pretty plain, except that I've configured my xterm to use MiscFixed, which
is a UTF-8 capable font. Before the moving to internal slang (with slang 1.x)
this exact same setup worked fine.
Also it works fine with the new system installed slang 2. The spacec as arrows
are gone now too, dunno why after an mc restart they just disappeared, maybe a
I've done some looking into the gpm mouse problem and I believe that has been
fixed by either upstream mc or gpm, see my comments in bug 168076
The new mc with the external slang dependecy should occur in rawhide tomorrow.
The screenshot looks pretty bad, I don't see it either on my FC4 or rawhide box
even when I use the internal mcslang.
I've the following two lines in my /etc/X11/Xresources:
You can do an xrdb -merge /etc/X11/Xresources after putting this in to get this
applied without killing the X-server.
This causes xterm to use the MiscFixed font which supports a very wide variety
of languages, which in turn probably puts xterm in utf8 mode by default (I
think). Which I believe is the cause of this.
Jindrich, how is this "fixed in Rawhide"?
I can't reproduce this with a fairly recent CVS tarball with UTF-8 patch and
build against internal slang(2) with xterm and the fonts you mention.
Hans, sadly you fail to mention any version of the used components. Could it be
you are using devel components on a FC4 system? I assume you have an issue with
mc-4.6.1a-3 as -4 needs slang2 libs, so I can't test it ;) .
Anyway, please supply more details next time so we can actually look into this.
Hans wrote in the bug description that the bug is worked around by rebuilding mc
against system slang. Since we have slang-2.0.5 as the system one, the latest
rawhide mc is now built against system slang.
Sticking to mcslang was a temporary solution of the fact we had only slang-1.4.9
as the system one up to a recent time.
Point I made is I do not have this problem with a CVS tarball from 2 weeks ago
built with mcslang(v2.0.5). So I don't see how building against external slang
is a solution to anything. Not even sure what the problem is. Is it something
with mc (then why can't I reproduce it? nothing much changed in CVS in 2 weeks),
a certain version of xterm, or with a certain version of the charset?
Hence my question: How is this (not even knowing exactly what "this" is) fixed
in rawhide? Sure, it obviously doesn't occur, but what is "it"?
I understand you wat to reproduce this, I was able to reproduce it on 2
-fully uptodate i386 rawhide, with modular X and mc-4.6.1a-0.23,
-x86_64 last fully updated to rawhide shortly before modular X landed, then
I did a "yum -y upgrade slang" to see if I could reproduce the problem here
(it wasn't there at the time). Because the older mc on this system depended on
slang-1 which was being upgraded yum decided to also upgrade mc, to the newer
version which uses the internal mcslang. After this upgrade mc had the same
bug as system 1. Looking at the dependencies I can state that the only part of
the system changed at this moment was going from external slang 1 to internal
Both systems have nothing special except that I use xterm instead of one from
kde/gnome and that my xterm is configured to use a different font as described
above. I believe the problem is in the font but haven't actually tried this.
The bug might be caused by the additional patches used by redhat on top of mc
CVS, have you tried using these to reproduce?
jnovy, mc-4.6.1a-4 fixes this as expected, thanks.
Where can I find a mc-4.6.1a-0.23 SRPM? So I can rebuild on FC4 and see if I can
reproduce this problem.
Also, what are the differences between mc-4.6.1a-0.23 and mc-4.6.1a-4? Only that
one has been built against mcslang and the other against external slang? If so
please see if you can reproduce the bug by rebuilding -4 with mcslang.
Further you speak of modular X. Quite possible that still has some bugs. Have
there been other updates in the mean time or did you just update mc? In case you
have done other updates please revert mc to -0.23 and see if the problem persists.
As I said before I wouldn't see why building against mcslang or external slang
could have anything to do with this bug as both use the same version and at
least the internal version has not been patched except for the removal of a
reference to an internal glibc integer. Modular X is a far likelier candidate.
you can temporarily dowload mc-4.6.1a-0.23 from:
The differences between mc-4.6.1a-0.23 and mc-4.6.1a-4 are noted in %changelog.
The only changes being something minor to the utf8 look and feel patch and the
use of external slang.
Anyway, I've rebuilt 0.23 and do not see the problem described here on FC4 (tried
xterm [-u8] -fg white -bg black -fa \
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 -fb \
). Hence I believe there was something else in rawhide that broke mc...
Hans, please revert mc to 0.23 and see if the problem is still there. That way
we know if the issue was fixed by another update. Thanks.
I understand that you want to reproduce this, but please read my previous
comments. As already said I've been able to reproduce this on a system with a
fine working mc by just upgrading slang+mc, so nothing else has changed on my
system excpet for slang and mc, and since slang was no longer used by the new
mc, nothing has changed except for mc.
Both systems you describe are rawhide. Are you telling me both systems haven't
seen any other updates than mc?
I had a fully uptodate rawhide with a broken mc and a less the fully uptodata
rawhide with a working one, so I did a "yum -y update slang" to just update
slang since I thought that was the culprit and I wanted to be sure that that was
the culprit this also sucked in the new mc wich uses it own slang, so the only
differences between a rawhide with working mc and one with a broken mc are a
nerwe (unused) slang and a newer mc.