emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strange behaviour with dired and UTF8


From: Jan D.
Subject: Re: Strange behaviour with dired and UTF8
Date: Wed, 7 May 2003 17:43:20 +0200

In article <address@hidden>, "Jan D." <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]