Re: Strange behaviour with dired and UTF8

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

>> 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.

I think it is bad to hawe multiple information sources that has to
be consulted to figure out the original file name (the display file
name, the buffer encoding, file system encoding, and the new alist).
At some point Emacs must have had the original file name.  It is a
shame to throw away that knowledge and then try to reconstruct it.

>> Both KDE and GNOME file managers and file dialogs fail to open
>> the right file in certain cases.  I think it is worse if dired fails 
>> on
>> 'f' since in that case the file name is supplied by dired, not the 
>> user.
>> For C-x C-f there is always TAB to see what Emacs thinks the file is 
>> called.
>
> But, *Completion* buffer doesn't show correct file names
> because there are names encoded by latin-1.  How one can
> choose what he want?  In addtion, TAB says "[no match]" if
> one has already typed some non-ASCII characters.

An other approach would be to always keep file names as is (i.e.
the original file name) and put some sort of property on it that is the
encoding.  This would require that the display engine can display these
with right encoding.  That way the manipulations is always done on and
with the original file name.

This is of course some work.

>> 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.

	Jan D.