Re: Strange behaviour with dired and UTF8

[Kenichi Handa]

In article <address@hidden>, "Jan D." <address@hidden> writes:
>>  How about this?
>> 
>>  (1) Make a customizable variable
>>      file-name-coding-system-alist; the format is the same as
>>      file-coding-system-alist.
>> 
>>  (2) Make the macro ENCODE_FILE and DECODE_FILE to check that
>>      variable before using file-name-coding-system and
>>      default-file-name-coding-system.
>> 
>>  (3) Enhance the function dired-revert to update
>>      file-name-coding-system-alist automatically if it is
>>      called with coding-system-for-read being bound to
>>      non-nil.  In that case, it may also have to ask a user
>>      to save that modification for the future session (via
>>      customize).
>> 
>>  What do people think?  Aren't there any better idea?

> This sounds very complicated.  As I understand it, dired first gets
> the file name from ls (original representation), then converts that to
> whatever encoding it shall use to show it in the buffer (view
> representation).  When dired operates on the file (opening for example),
> it converts back from the view representation, hoping to get the
> original representation.  But this may fail, since conversion
> from view back to original is not one-to-one.

It is sure that there's a possibility that encoding a
filename can't get the original filename.  But, Emacs anyway
can't handle such a filename.

> This work (original representation -> view representation -> original
> representation) should not be needed, IMHO.  Why just not keep the
> original representation around (some kind of text property on the file
> name?) and always use that when operating on the file?  That change 
> would be transparent to users.

A user may type C-x C-f FILENAME in the dired buffer.  With
the above method, we don't know how to encode FILENAME.

And, even if one types `f' to visit a file, in that file
buffer, we loose the information of the original
representation.

---
Ken'ichi HANDA
address@hidden