From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: po file charset via auto-coding-functions Date: Fri, 11 Nov 2005 02:42:20 -0500 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> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1131695628 28471 80.91.229.2 (11 Nov 2005 07:53:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2005 07:53:48 +0000 (UTC) Cc: emacs-devel@gnu.org, user42@zip.com.au, handa@m17n.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 11 08:53:46 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EaTiu-0007kB-U0 for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 08:53:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaTit-0007Um-QQ for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2005 02:53:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EaTYO-00037a-Ro for emacs-devel@gnu.org; Fri, 11 Nov 2005 02:42:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EaTYM-00036k-Dh for emacs-devel@gnu.org; Fri, 11 Nov 2005 02:42:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EaTYK-00036Y-WA for emacs-devel@gnu.org; Fri, 11 Nov 2005 02:42:29 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EaTYL-0004ec-7H for emacs-devel@gnu.org; Fri, 11 Nov 2005 02:42:29 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1EaTYC-0001cx-Rn; Fri, 11 Nov 2005 02:42:21 -0500 Original-To: Stefan Monnier In-reply-to: <87psp8qrz9.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Thu, 10 Nov 2005 13:33:24 -0500) 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:45724 Archived-At: > 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. 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? 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. ;; We need to mimic the parts of insert-file-contents ;; which determine the coding-system and decode the text. (let ((coding (or coding-system-for-read (and set-auto-coding-function (save-excursion (funcall set-auto-coding-function name (- (point-max) (point))))) (car (find-operation-coding-system 'insert-file-contents name t)))) But since that isn't a true valid file name, it needs a comment to explain why calling find-operation-coding-system in a way contrary to its rules nonetheless gives correct results. And maybe we need to document this also in the place that defines find-operation-coding-system and the functions it calls, so that people will not change them in a way that breaks this code.