Red Hat Bugzilla – Bug 143415
Big "Midnight" word (in the top of the F1 help) is spoiled in utf8 mode
Last modified: 2013-07-02 19:04:38 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
Under UTF8, the F1`s help header (big "Midnight" word at the top) is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. set "LANG=en_US.UTF-8" in /etc/sysconfig/i18n, run "setsysfont"
2. run "mc", then type F1
You can see a gabarge in the place of big "Midnight" word.
Expected Results: may be seen in non-utf8 mode:
1. set "LANG=C" in /etc/sysconfig/i18n, run "setsysfont"
2. run "mc", type F1
All is OK...
It is inspired by some utf-related changes in the system slang library.
SLsmg_draw_object() should receive SLSMG_* values now instead of
simple chars, but it is impossible to specify it immediately in the
Created attachment 108905 [details]
Simple work-around for this
It works for both utf/non-utf environment.
This is the same as Egmont Koblingers
Dmitry, please be so kind to mention the origin of your patches.
I have made this work independently.
Of couse, it is very appreciable issue, and the patch is very
simple. Therefore, somebody could offer the same decision earlier, but
I knew nothing about it.
Could you prompt me a source where you have found a similar patch?
Leonard, tone of your comment hints that I the thief. The
presumption of innocence is not valid in your environment? ;-)
Note: There is a prior work: see
Dmitry, the earlier patch for this is from Egmont Knoblinger's mc
patches located at:
The patch is trivial, so I do believe it was done by you
independently. Important is that you filed this bugreport, so I can
review the patch and apply it.
The patch is now commited and new mc with additional UTF-8 fixes is
I had no intention of accusing you of theft. It's just easier if one
uses patches from others to tell where they came from (for reference,
to save me (and possibly others) some time when looking up and
But I understand you created this patch independently, so you couldn't
have pointed out the other author.
This patch is bad. The ncurses function acs_map() should not be used
Compiling --with-screen=mcslang on CentOS 3.3 fails for this reason.
Makes me wonder if this is a slang bug? If you disable the patch and
build --with-screen=mcslang, does the issue persist? If so this is an
mc bug. If not this might well be a slang issue, like the extra '-' on
the bottom line of the main panel which disappears when build
Sorry if my and Dmitry's patch is wrong (not portable), I could only
test it on Linux i386 and found it was working there.
First, it is `acs_map', not `acs_map()' (i.e., not a function)
Second, according to /usr/include/slang/slang.h, acs_map is a macro
to SLcurses_Acs_Map array...
Yes, this patch may be not protable for upstream MC, but for
RedHat`s MC, with utf8-patches, with utf8-patched system slang, all
should be OK.
MC logo was garbled only with utf8 support, which currently is not
in upstream releases. Therefore, "Fedora has spoiled MC logo, Fedora
and has repaired it" :-)
These UTF-8 patches are supposed to be cross platform. This also means
that they should be correct when mc is build --with-screen=mcslang.
This might be the best solution for RHEL 3 (or CentOS 3.3) because
using the internal slang fixes some slang bugs (more recent version
(1.4.9) of slang).
Sadly upstream has nothing to do with this issue (yet)... FYI I am not
just upstream, I'm Fedora, upstream, SuSE, whatever. Trying to
accomplish that these patches can be used as widely as possible.
I asked before: Does an mc build --with-screen=mcslang (and without
the patch) still show this bug? I am trying to establish if this is a
(Egmont, this patch is exactly like your patch. Why do you speak of
Dmitry's patch then?)
When mc is build --with-screen=mcslang , it does not work under
utf8, irrespective of whether "logo" patch is used or not. (I checked
it on Linux console). IMHO, it is due to mcslang yet has no utf8 stuff.
Therefore we cannot check up this utf8-related bug under mcslang,
since it does not support utf8 for us.
Ok. So mc's internal slang should also be patched with the slang UTF-8
patches that are used by RH and others then.
Created attachment 109177 [details]
This patch fixes mc compilation failure with --with-screen=mcslang
The patch assumes you have a system slang with UTF-8 support. (with applied Red
Hat UTF-8 slang patch)
Leonard, it's not a good idea to reopen bugs like this when the bug is
actually fixed in the released Red Hat devel mc.
It's true the UTF-8 patches should be maintained in the way that they
are portable since we want them applied upstream, but in order to keep
cross-platformity you should inform me via email and not via bugzilla
since Fedora people are completely unaffected by failed compilation on
CentOS. The error has a very little to do with CentOS though.
The reason of the compilation failure is that acs_map is introduced by
the slang UTF-8 patch from Red Hat on top of the Debian UTF-8 slang
patch. So the compilation will fail on any non-Red Hat distribution,
(I mean a distribution without the Red Hat patch appied in system
slang) and will also fail with --with-screen=mcslang because mcslang
lacks UTF-8 support. I'll try to add the UTF-8 patches to the mcslang.
Dmitry, Egmont, thanks for the patches. Closing this rawhide again.