bug-coreutils
[Top][All Lists]
Advanced

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

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


From: Dave Love
Subject: Re: dired doesn't work properly with a multibyte locale
Date: 03 Feb 2003 17:44:08 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Miles Bader <address@hidden> 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.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]