From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Strange behaviour with dired and UTF8 Date: Wed, 7 May 2003 17:43:20 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <200305070108.KAA22606@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1052322514 16426 80.91.224.249 (7 May 2003 15:48:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 7 May 2003 15:48:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 07 17:48:29 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19DR9h-0004Ga-00 for ; Wed, 07 May 2003 17:48:29 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19DRDj-0005ES-00 for ; Wed, 07 May 2003 17:52:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19DRAu-0005L5-02 for emacs-devel@quimby.gnus.org; Wed, 07 May 2003 11:49:44 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19DR7Z-00040T-00 for emacs-devel@gnu.org; Wed, 07 May 2003 11:46:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19DR6Z-00038T-00 for emacs-devel@gnu.org; Wed, 07 May 2003 11:45:39 -0400 Original-Received: from stubby.bodenonline.com ([193.201.16.94]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19DR5u-0002Rk-00 for emacs-devel@gnu.org; Wed, 07 May 2003 11:44:34 -0400 Original-Received: from accessno42.bodenonline.com (IDENT:root@accessno42.bodenonline.com [193.201.16.44]) h47GZ1S3022605; Wed, 7 May 2003 18:35:02 +0200 Original-To: Kenichi Handa In-Reply-To: <200305070108.KAA22606@etlken.m17n.org> X-Mailer: Apple Mail (2.552) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13747 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13747 > In article <6129D384-7FED-11D7-81D0-00039363E640@swipnet.se>, "Jan D." > 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.