Bug 143415 - Big "Midnight" word (in the top of the F1 help) is spoiled in utf8 mode
Big "Midnight" word (in the top of the F1 help) is spoiled in utf8 mode
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mc (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Jindrich Novy
:
Depends On:
Blocks: 147559
  Show dependency treegraph
 
Reported: 2004-12-20 11:37 EST by Dmitry Butskoy
Modified: 2013-07-02 19:04 EDT (History)
3 users (show)

See Also:
Fixed In Version: 4.6.1a-0.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-30 07:47:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple work-around for this (452 bytes, patch)
2004-12-20 11:38 EST, Dmitry Butskoy
no flags Details | Diff
This patch fixes mc compilation failure with --with-screen=mcslang (490 bytes, patch)
2004-12-30 07:42 EST, Jindrich Novy
no flags Details | Diff

  None (edit)
Description Dmitry Butskoy 2004-12-20 11:37:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040923

Description of problem:

  Under UTF8, the F1`s help header (big "Midnight" word at the top) is
spoiled.

Version-Release number of selected component (if applicable):
mc-4.6.1a-0.1

How reproducible:
Always

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

Additional info:

  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
*.hlp files.
Comment 1 Dmitry Butskoy 2004-12-20 11:38:51 EST
Created attachment 108905 [details]
Simple work-around for this

  It works for both utf/non-utf environment.
Comment 2 Leonard den Ottolander 2004-12-20 15:42:49 EST
This is the same as Egmont Koblingers
00-80-utf8-help-line-drawing-art.patch.

Dmitry, please be so kind to mention the origin of your patches.
Comment 3 Dmitry Butskoy 2004-12-21 07:54:32 EST
  Leonard, 

  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? ;-)
Comment 4 Dmitry Butskoy 2004-12-21 08:17:30 EST
  Note: There is a prior work: see
http://www.ottolander.nl/mc-patches/UTF-8/00-80-utf8-help-line-drawing-art.patch
Comment 6 Jindrich Novy 2004-12-21 10:14:22 EST
Dmitry, the earlier patch for this is from Egmont Knoblinger's mc
patches located at:

https://svn.uhulinux.hu/packages/dev/mc/

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

Thanks,
Jindrich
Comment 7 Leonard den Ottolander 2004-12-21 12:03:20 EST
Dmitry,

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
comparing patches).

But I understand you created this patch independently, so you couldn't
have pointed out the other author.
Comment 8 Leonard den Ottolander 2004-12-27 17:21:35 EST
This patch is bad. The ncurses function acs_map() should not be used
#ifdef HAVE_SLANG.

Compiling --with-screen=mcslang on CentOS 3.3 fails for this reason.
Comment 9 Leonard den Ottolander 2004-12-27 17:40:52 EST
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
--with-screen=mcslang.
Comment 10 Egmont Koblinger 2004-12-28 04:06:31 EST
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.
Comment 11 Dmitry Butskoy 2004-12-28 07:04:41 EST
  Leonard,

  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" :-)
Comment 12 Leonard den Ottolander 2004-12-28 16:30:32 EST
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
slang issue.

(Egmont, this patch is exactly like your patch. Why do you speak of
Dmitry's patch then?)
Comment 13 Dmitry Butskoy 2004-12-29 07:03:51 EST
  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.
Comment 14 Leonard den Ottolander 2004-12-29 12:31:35 EST
Ok. So mc's internal slang should also be patched with the slang UTF-8
patches that are used by RH and others then.
Comment 15 Jindrich Novy 2004-12-30 07:42:23 EST
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)
Comment 16 Jindrich Novy 2004-12-30 07:47:26 EST
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.

Note You need to log in before you can comment on or make changes to this bug.