From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Strange behaviour with dired and UTF8 Date: Fri, 2 May 2003 20:22:08 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305021122.UAA16717@etlken.m17n.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1051874705 5049 80.91.224.249 (2 May 2003 11:25:05 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 2 May 2003 11:25:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri May 02 13:25:00 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 19BYey-0001Iv-00 for ; Fri, 02 May 2003 13:25:00 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19BYgU-00022b-00 for ; Fri, 02 May 2003 13:26:34 +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 19BYce-0006cS-01 for emacs-devel@quimby.gnus.org; Fri, 02 May 2003 07:22:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19BYcK-0006as-00 for emacs-devel@gnu.org; Fri, 02 May 2003 07:22:16 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19BYcI-0006Zv-00 for emacs-devel@gnu.org; Fri, 02 May 2003 07:22:15 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19BYcI-0006ZR-00 for emacs-devel@gnu.org; Fri, 02 May 2003 07:22:14 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h42BM9o17948; Fri, 2 May 2003 20:22:09 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h42BM8A12354; Fri, 2 May 2003 20:22:08 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id UAA16717; Fri, 2 May 2003 20:22:08 +0900 (JST) Original-To: jan.h.d@swipnet.se In-reply-to: (jan.h.d@swipnet.se) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:13620 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13620 In article , "Jan D." writes: >> 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. > Why not if it has the original filename? I'm talking about the general situation, not restricted to dired. I think this problem must be fixed in general cases, not only for dired. And, always carrying around the original filename with a filename is one means. But that requires huge change to Emacs. In addition, there are many cases that modify a filename as a string. >>> 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. > Why would this change? I am only talking about file names that dired > reads from a directory. No need to change C-x C-f. Typing `f' works fine but C-x C-f doesn't, which is not a good behaviour. >> And, even if one types `f' to visit a file, in that file >> buffer, we loose the information of the original >> representation. > Then Emacs as a whole should change. Yes, my proposal is to change Emacs' behavior as to filename handing as a whole in a fairly low cost. > If I open a file from dired, modify it and save it, I > expect it to save to the same file name. Are you saying > there are situations where Emacs fails to do this? No. As far as I know, there's no system that allows stateful encoding on filenames. And if Emacs decodes a filename by one of stateless coding systems (despite that it is the correct one or not), it can be encoded back correctly by the same coding system. For instance, I think you can open and save a file of utf-8 name in latin-1 lang. env. in dired correctly (although the filename is not shown correctly). By the way, I've just thought of this weird situation. One has a file of utf-8 name in a directly of latin-1 name. :-( I think we can say sorry in such a case. --- Ken'ichi HANDA handa@m17n.org