Re: dired doesn't work properly with a multibyte locale

[Kenichi Handa <handa@m17n.org>]

In article <buobs1urtm3.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
>>  This statement reads that any character encoded by multiple bytes in a
>>  filename causes a trouble, for instance any CJK characters in CJK
>>  locales or any non-ASCII chars in UTF-8 locale.  As you can use
>>  ja_JP.eucJP locale, could you please try some Japanese file name?

> They work fine for me.

> My impression was that the bug only occured with newlines, and looking
> at Andrea's patch seems to confirm this.  I think that when Andreas
> mentioned byte vs character counts it was merely to clarify the issue
> (as earlier there was some confusion about that in this thread).

I read his mail again, and found that the bug is not in
chars vs bytes, but columns vs bytes.

So, ja_JP.eucJP was not a good example because, in that
locale, column numbers and bytes are equal.

Please try some UTF-8 locale (e.g. en_US.UTF-8) with Latin-1
filenames.  I believe that the current dired will be
confused.

>>  >      This package is the union of the following:
>>  >      textutils-2.1, fileutils-4.1.11, sh-utils-2.0.15.
>>  
>>  Hmmm, then, it's strange that "ls (fileutils) 4.1" works,
>>  but "ls (coreutils) 4.5" doesn't.

> Why?  I think it just means that the bug was introduced after fileutils-4.1.

Ah, sure.  I blindly thought that the last digits "11" was
not important.

---
Ken'ichi HANDA
handa@m17n.org