Miles Bader <[EMAIL PROTECTED]> 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.] _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
