Re: Dired doesn't decode UTF-8 file names (was: Dired confused by filenames starting with date-like strings)

[Peter Dyballa <Peter_Dyballa@Web.DE>]

Am 24.08.2006 um 18:12 schrieb Kevin Rodgers:

> Peter Dyballa wrote:
>> Am 24.08.2006 um 16:27 schrieb Kevin Rodgers:
>>> There is no reason to set dired-use-ls-dired to anything but t or  
>>> nil.
>>> In particular, it does not determine which ls program is run.  Try:
>>>
>>> (setq insert-directory-program "/sw/bin/ls"
>>>       dired-use-ls-dired t)
>> Am 24.08.2006 um 16:35 schrieb Miles Bader:
>>> So I guess the following should work:
>>>
>>>    (setq dired-use-ls-dired t)
>>>    (setq insert-directory-program "/sw/bin/gls")
>> Oh, yes, these work! Thank you! There isn't much difference  
>> compared to using Apple's ls; in GNU Emacs 22.0.50 UTF-8  
>> characters are still displayed as a series of UTF-8 octets, and in  
>> GNU Emacs 23.0.0 I still cannot search for file names with German  
>> umlauts etc.
>
> That is the first mention of UTF-8 in this thread.  Mile suggested  
> using
> GNU ls --dired to solve the OP's problem with date-like filenames.

I remember Miles Bader mentioned some time before that GNU ls could  
solve UTF-8 problems. Then it did not work, for me, so I thought,  
hoped, that now, with 'dired extra switches' it could work better. I  
have problems with non-7 bit US-ASCII characters in the file name and  
in the abbreviated month name (Mär, for March) – at least this one  
*is* solved (3 Mär 13:39 => 2006-03-03 13:39).

>
> Is file-name-coding-system (or default-file-name-coding-system) set
> to utf-8?

No, it is iso-latin-1! Although my language environment in shell is  
set to UTF-8, as it is for GNU Emacs 23.

File-name-coding-system is nil, so default-file-name-coding-system  
should be used, according to the documentation. But – it's still iso- 
latin-1! Ah, here is a difference: it *came* from  '(current-language- 
environment "UTF-8") in the customisation section! (I warned about  
its use, but had it myself still set! Arghh!!!)

>   Should it be?

Yes, it should! The abbreviated month's name is now correctly  
displayed! GNU Emacs 22.0.50 still has problems: German umlauts in  
file names are displayed as [AOUaou]¨ and because ¨ is not found in  
the fontset I see after each vowel an empty box. The same is true for  
other accented characters in file names. GNU ls and Apple ls show no  
difference.

Launching GNU Emacs 22.0.50 in Terminal with no windows the de- 
composed UTF-8 characters are composed correctly!

>
> Is there an entry in process-coding-system-alist for ls?  Should there
> be?

Not directly ...

	(("\\*shell\\*\\'" utf-8 . utf-8)
	 ("\\*.* output\\*\\'" iso-8859-15-unix . iso-8859-15-unix))

The second line is meant for AUCTeX output buffers (although not  
really working, probably I have to find some hook). Is there really  
more needed?

--
Greetings

   Pete

"Let's face it; we don't want a free market economy either."
         James Farley, president, Coca-Cola Export Corp., 1959