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

[Dave Love <d.love@dl.ac.uk>]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Is it worth the trouble?

I'm confused by what's being discussed here, but it is surely worth
the trouble to have dired working properly in multibyte locales.

> As far as I know the problem only occurs with
> newlines in filenames,

No.  In locale en_GB.UTF-8 in Debian Woody, create a file with
arbitrary Latin-1 characters in the name and observe that dired
positioning screws up after that filename occurs.

It works in 21.2 (using my utf-8 language definition) and worked in
the development code as it was before Christmas.  It no longer does in
the development code.  [I made some other changes to dired, unrelated
to encoding and not installed, and thought I'd broken it somehow.]

> Why is it more useful to count in characters?

Because that makes it easier for Emacs, which is --dired's stated
intention.

> Of course that makes things a bit simpler for emacs, but counting in
> bytes has the advantage that a tool doesn't have to be support the
> coding system ls does in order to grab the filenames.

That's exactly what I said, but if you don't support the encoding, you
lose anyhow.

[None of this actually helps people with an ls which doesn't support
--dired, of course.  I still think you should consider using a
specified LC_TIME.  If it's a real problem that users won't get the
date in the format they expect, run ls twice, first to find the names
with LC_TIME=C and then to display the results.]