[no subject]



> The right solution would be using mbswidth() (from gettext) instead
> of
> strlen() to calculate the lenth of the strings on the screen.
> 
> There are also places in MC where is splits strings at a certain
> point.  
> It should be ensured that the split is only done at the multibyte
> character boundaries.  Implementation of name_trunc() would be very
> non-trivial.  The worst thing is that it can affect the
> performance.
That's a real conversation! :) 
name_trunc() might get more complex but not hopeless. UTF-8 is stable
encoding, every byte which is not the beginning of the symbol has got
8th bit set. So if we break on it, just go couple of bytes back to
find the beginning.
As to performance, in the worst case average length of the panel is ~
300-400 files which would not be that hard for Pentium to make couple
more instructions. Escpecially if we take to account that visual part
is not more than 30-40 file names.

> Either you or somebody else fixes MC or you should make some
> workarounds.  
I just give the idea and some initial data, if there's nobody to get
involved with this now, in some time I'll get back and try to put my
hands on it (I'm afraid though that at that time computers won't be
something we see them now :)). 
I just thought that it'd be faster if someone with his hands on MC
already sees it helpful and implement it.
...
> This will help you "survive" until MC supports multibyte
> characters.
I can live with single-byte encoding locales now, it's just that we
have to move on...

Take care,
Andriy 

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com



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