Re: Midnight Commander within console in UTF-8 mode

[Pavel Roskin <proski gnu org>]

Hello, Timur!

> I guess it's not an urgent problem and with upcoming glib 1.4 we'll
> get nice unicode module, so we can be independent from platform
> and have a better framework to deal with different charsets.

Thank you for information!

> I should mention, that MC wasn't(and still not completly) 8-bit
> clean quite recently - I've commited patches to work with russian
> filenames and strings in the input less than year ago.

Yes, a lot of cleanup is still needed.

> And noone complained before :) So, I hope, we can wait a bit untill
> new version of glib will be released.

Just to set the record straight.  There are several reasons why the
problems are not reported to the list, and neighter of them excuses bad
programming "because nobody complains":

1) MC has changed the mailing list address twice in the last year.  
Considering the fact that many people are still using mc-4.5.54 and even
mc-4.5.51 (RedHat 7.2 is released with mc-4.5.51), many users may have
difficulties finding the new mailing lists.

2) Versions between 4.5 and 4.5.51 were released with so subtle changes
between versions, that some users forget to mention the version, assuming
that all versions have the same bugs, in other words, assuming that MC is
not actively developed.

3) The introduction of the GNOME frontend made some users think that only
the GNOME frontend is under development (see for example
http://mail.gnome.org/archives/mc-devel/2001-September/msg00001.html).  
The result is the same - the problems in the text edition are not
reported.

4) Many users don't know what is supposed to work.  Bugs are often 
considered limitations.  For example, MC supports associating more than 
one key sequence with the same key, but nobody submitted additional 
sequences for TERM=xterm assuming that it's not supported.

5) Regarding the bugs in the i18n and 8-bit support, many people affected
by them don't speak English sufficiently to ask in this list.

> Also, I don't remember claims that Slang is UTF8 or UCS16 safe..

That may be the real problem.  S-Lang keeps a table representing the
contents of the screen.  The version included with MC uses "unsigned
short" to keep the character and the attribute, which is not sufficient 
for Unicode.

S-Lang 1.4.4 uses type SLsmg_Char_Type, which is defined to "unsigned 
short" but can be changed (in theory).

On the other hand, ncurses 5.2 comes with "experimental wide-character 
code":

    --enable-widec
        Compile with experimental wide-character code.  This makes a different
        version of the libraries (e.g., libncursesw.so), which stores
        characters in 16-bits.  We provide a simple UTF-8 driver and test
        program to use this feature with terminals that can display UTF-8.
    
        NOTE: applications compiled with this configuration are not compatible
        with those built for 8-bit characters.  You cannot simply make a
        symbolic link to equate libncurses.so with libncursesw.so

-- 
Regards,
Pavel Roskin