From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: po file charset via auto-coding-functions Date: Fri, 18 Nov 2005 22:08:34 +0900 Message-ID: References: <87zmp399ue.fsf@zip.com.au> <87ll0ma3ow.fsf@zip.com.au> <87fyqu9ung.fsf@zip.com.au> <877jbhrwox.fsf-monnier+emacs@gnu.org> <87psp8qrz9.fsf-monnier+emacs@gnu.org> 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: sea.gmane.org 1132319909 23196 80.91.229.2 (18 Nov 2005 13:18:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Nov 2005 13:18:29 +0000 (UTC) Cc: user42@zip.com.au, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 18 14:18:19 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ed67L-0000IN-SJ for ged-emacs-devel@m.gmane.org; Fri, 18 Nov 2005 14:17:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ed67L-00073N-9J for ged-emacs-devel@m.gmane.org; Fri, 18 Nov 2005 08:17:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ed5yx-0003RQ-BP for emacs-devel@gnu.org; Fri, 18 Nov 2005 08:08:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ed5yv-0003Pt-6E for emacs-devel@gnu.org; Fri, 18 Nov 2005 08:08:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ed5yt-0003Nt-7q for emacs-devel@gnu.org; Fri, 18 Nov 2005 08:08:43 -0500 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1Ed5yr-00068J-I0; Fri, 18 Nov 2005 08:08:42 -0500 Original-Received: from nfs.m17n.org (nfs.m17n.org [192.47.44.7]) by tsukuba.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id jAID8aYO032505; Fri, 18 Nov 2005 22:08:37 +0900 Original-Received: from etlken (etlken.m17n.org [192.47.44.125]) by nfs.m17n.org (8.13.4/8.13.4/Debian-3) with ESMTP id jAID8Zjv005524; Fri, 18 Nov 2005 22:08:35 +0900 Original-Received: from handa by etlken with local (Exim 3.36 #1 (Debian)) id 1Ed5yk-0003kQ-00; Fri, 18 Nov 2005 22:08:34 +0900 Original-To: rms@gnu.org In-reply-to: (rms@gnu.org) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:46220 Archived-At: Sorry for the late response on this matter. I was just back from Hanoi; Vietnamese foods were very good. :-) In article , "Richard M. Stallman" writes: >> As a matter of fact I think passing >> "/home/handa/x.tgz!vi.po" is more correct: if we assume that >> a suitable file-name-handler is installed it's perfectly correct. >> But I don't think we should install such a handler, because it would >> be an incompatible change in file name syntax. > Then maybe another syntax should be used, but currently that's the syntax > chosen: this is the value used for buffer-file-name. > Does that file name get used for anything except to appear in the C_x > C-b listing and be helpful for the user? I think it does not. I don't know exactly which command uses it, but it is used by any operations that call get-file-buffer. > The previous message said: > The correct operation in a handler for insert-file-contents > will be to find a buffer pretending to visit the file, and > insert that buffer contents. And, for that, we have to give > buffer-file-name (e.g. /home/handa/x.tgz!vi.po") not the > filename itself (e.g. vi.po) to > find-operation-coding-system. > Can you explain the context of this? Where is insert-file-contents > being called from, and with what file name argument? > How does it relate to this issue? Here the "handler" means a function registered in file-coding-system-alist (it's po-find-file-coding-system in the current case). > If it is simply a matter to call find-operation-coding-system here, > in tar-extract, then I agree it is ok to pass buffer-file-name. Yes, that is what the change I propsed for an archived file does. And, for a compressed file, I proposed this change. *** jka-compr.el 08 Aug 2005 10:13:24 +0900 1.87 --- jka-compr.el 24 Oct 2005 11:38:27 +0900 *************** *** 500,509 **** (delete-file local-copy))) (unless notfound (decode-coding-inserted-region (point) (+ (point) size) ! (jka-compr-byte-compiler-base-file-name file) ! visit beg end replace)) (and visit --- 500,513 ---- (delete-file local-copy))) (unless notfound + (let ((buffer-file-name + (concat file "!" + (jka-compr-byte-compiler-base-file-name file)))) + (decode-coding-inserted-region (point) (+ (point) size) ! buffer-file-name ! visit beg end replace))) (and visit As you see, this binds buffer-file-name temporarily to something like /home/handa/temp.po.gz!/home/handa/temp.po so that find-operation-coding-system (called in decode-coding-inserted-region) can surely find po-find-file-coding-system to be called, and it can surely find the current buffer by get-file-buffer. Do you agree with this change too (of course provided that more comments are added)? --- Kenichi Handa handa@m17n.org