Re: mc and utf-8 again but different



On Tue, 20 Nov 2007 21:31:39 +0100, Michail Vidiassov <master iaas msu ru> wrote:

I do not see the point in your ncursesw patch -
it gives an option to link against a wchar-enabled library,
but the wide API is not used.
For me only nursesw handles correct utf-8 strings. Only part of code, that use direct wchars (gunichars) is strutilutf8.c, but all wchars functions are taken from glib.

Other problem is that Mac OS X uses UTF-8 for text in files and Terminal,
but UTF-8-MAC (decomposed form) in filesystem.
Thus if I have a file with extended Latin in content and filename
then by default (or if I set Encoding to UTF-8) the panel display
is distorted, since mc counts the number of characters in the decomposed form, that is more than it really takes on screen A+macron =Amacron),
but internal viewer shows file OK,
Actual version of my patches does not distinguish between normal and combining characters. I'm trying to fix it now. http://www.fi.muni.cz/~xbenes5/projects/mc/mc-combining.tar.gz - this version shall work better. All combining characters are supposed to be zero width. If formatted string contains combining characters, mc display his composed form, if exists (It is more compatible with gnome-terminal for example). WInput a view should be fixed for combining characters, too.

If it solves the panels displaying, I will add this direct to my patches.

if Encoding is set to UTF-8-MAC panels come out OK, but
internal viewer shows only questions.
It is possible, that file names conversion between UTF-8-MAC and UTF-8 has made composition too. View takes default encoding from vfs encoding, but can be changed by ctrl+t.


BTW, how can I set the default fs encoding to UTF-8-MAC in mc?
I do not need that viewer too much, after all, it is not "the UNIX way"
to integrate things. ;)
I think, that this feature will be not needed in well working version, so it does not exist.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]