Re: Strange behaviour with dired and UTF8

["Jan D." <jan.h.d@swipnet.se>]

> In article <6129D384-7FED-11D7-81D0-00039363E640@swipnet.se>, "Jan D." 
> <jan.h.d@swipnet.se> writes:
>>>>  I agree that this is bad, but I am not sure anything can be done
>>>>  about it.
>>>
>>>  How about my proposal?   Doesn't it solve this problem?
>
>> It depends on what the file-name-coding-system-alist looks like.  If 
>> it
>> contains full file name path, it could.  Maybe it is best to try it.
>
> It should contain a regular expression matching a directory
> or a file name.

Can you give an example?

> So, I think keeping the information about the original
> filename in an alist is the most reliable way.  In addition,
> we can use that information in the future emacs session,
> which is also an important point.

Here the danger of the two unrelated information sources to get out of
sync is apparent.


> I strongly oppose to that method.  Emacs should not work on
> undecoded raw bytes.  A filename is a kind of text, and thus
> a user should be able to handle it as a text (edit,
> copy&paste, etc).

It is more than that, it is an identifier to an entity that is external
to Emacs.  Normal text is not that.  When using it as an identifier it
should work on undecoded raw bytes (it tries to do that today, by
converting back from the display representation to the original
representation).  There is nothing that prevents edit of the text.

>>>>  I am not sure your case covers all cases.  If a file name was
>>>>  latin-1 and then converted to UTF8 (outside Emacs), Emacs would 
>>>> think
>>>>  it is
>>>>  still latin-1, no?
>>>>  It involves a bit of user interaction, making it intrusive.
>>>
>>>  Yes, but I think Emacs doesn't have to care about such a
>>>  case.
>
>> Why not?  I think this is about as bad as the failure of the
>> *Completion*  buffer.  Maybe worse, because you can not open the file
>> at all.
>
> If that filename is recoded as latin-1 in
> file-name-coding-system-alist, we can open that file by
> customizing file-name-coding-system-alist.  If that filename
> is not recoded in the alist, we can open that file by
> switching to utf-8 lang. env., or by setting
> file-name-coding-system to utf-8, or by customizing
> file-name-coding-system-alist.

Who is "we" that is doing all this?  The user, Emacs, someone else?
It seems as a lot of user interaction, but maybe you have another
mechanism in mind?

	Jan D.