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! p.s. I've also reenabled the gpm/console mouse, works fine why is/was that disabled?
Hello Hans, 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 configfile issue.
p.s. 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: XTerm*font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 XTerm*boldFont: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 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.
Hi Leonard, 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.
Hi Jindrich, 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"?
Leonard, I understand you wat to reproduce this, I was able to reproduce it on 2 different systems:. System1: -fully uptodate i386 rawhide, with modular X and mc-4.6.1a-0.23, System2: -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 slang. 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? p.s. jnovy, mc-4.6.1a-4 fixes this as expected, thanks.
Jindrich, Hans, 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.
Leonard, you can temporarily dowload mc-4.6.1a-0.23 from: http://people.redhat.com/jnovy/files/mc-4.6.1a-0.23.src.rpm The differences between mc-4.6.1a-0.23 and mc-4.6.1a-4 are noted in %changelog.
Thanks. 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 \ -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 ). 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.
Leonard, 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.
Hi Hans, Both systems you describe are rawhide. Are you telling me both systems haven't seen any other updates than mc?
Leonard, 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.