mc and utf-8 again but different

[Rostislav Beneš]

On Tue, 20 Nov 2007 21:31:39 +0100, Michail Vidiassov <master at 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.