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 _______________________________________________ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel