From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: EOL conversion of files in .tar archives Date: Tue, 22 May 2007 14:19:14 +0300 Message-ID: References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1179832760 5940 80.91.229.12 (22 May 2007 11:19:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 May 2007 11:19:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 22 13:19:18 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HqSOb-0007TS-Ru for ged-emacs-devel@m.gmane.org; Tue, 22 May 2007 13:19:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqSOc-00039A-Et for ged-emacs-devel@m.gmane.org; Tue, 22 May 2007 07:19:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HqSOZ-000395-7t for emacs-devel@gnu.org; Tue, 22 May 2007 07:19:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HqSOX-00038d-Qx for emacs-devel@gnu.org; Tue, 22 May 2007 07:19:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqSOX-00038a-LV for emacs-devel@gnu.org; Tue, 22 May 2007 07:19:13 -0400 Original-Received: from romy.inter.net.il ([213.8.233.24]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HqSOX-0003n2-7r for emacs-devel@gnu.org; Tue, 22 May 2007 07:19:13 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-229-252-153.inter.net.il [84.229.252.153]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id HWX65215 (AUTH halo1); Tue, 22 May 2007 14:19:11 +0300 (IDT) In-reply-to: (message from Kenichi Handa on Mon, 21 May 2007 13:48:20 +0900) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:71592 Archived-At: > From: Kenichi Handa > CC: emacs-devel@gnu.org > Date: Mon, 21 May 2007 13:48:20 +0900 > > In article , Eli Zaretskii writes: > > > Lately I noticed that, in the Windows port of Emacs, visiting files in > > .tar archives shows them as if they had DOS EOLs, even though the > > files have Unix EOLs. (This is not due to some recent change: it > > looks like Emacs behaved like that since before the pretest.) > > > Is this intentional, or should I debug it? If the former, can someone > > explain the rationale? > > I think it is a bug of find-buffer-file-type-coding-system > (dos-w32.el). If TARGET is (FILENAME . BUFFER), it should > assume that the file contents is available. Could you > verify that the attached patch is correct? I'm uneasy about patching find-buffer-file-type-coding-system at this stage, since it is so widely used. For example, decode-coding-inserted-region also invokes find-operation-coding-system with second argument a cons cell, and it is not clear to me that your change will DTRT in that case. I'd like to suggest an alternative change that is local to tar-mode.el, see below. It mimics what arc-mode.el does. This solves the problem with the EOL decoding, but reveals a very strange phenomenon: dos-w32.el and dos-w32.elc behave differently. The latter is preloaded into Emacs on Windows, and if I visit a file inside a tarball (after applying the patch below), plain text files with Unix EOLs get latin-1-unix buffer-file-coding-system, instead of the expected undecided-unix. But if I manually load dos-w32.el and visit the same file again, its buffer-file-coding-system is now undecided-unix, as expected! Is this some problem with the byte compiler? Index: lisp/tar-mode.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/tar-mode.el,v retrieving revision 1.108 diff -u -r1.108 tar-mode.el --- lisp/tar-mode.el 21 Jan 2007 03:53:10 -0000 1.108 +++ lisp/tar-mode.el 22 May 2007 11:18:19 -0000 @@ -681,6 +681,12 @@ (goto-char (posn-point (event-end event))) (tar-extract)) +(defun tar-file-name-handler (op &rest args) + "Helper function for `tar-extract'." + (or (eq op 'file-exists-p) + (let ((file-name-handler-alist nil)) + (apply op args)))) + (defun tar-extract (&optional other-window-p) "In Tar mode, extract this entry of the tar file into its own buffer." (interactive) @@ -735,9 +741,17 @@ (save-excursion (funcall set-auto-coding-function name (- (point-max) (point))))) - (car (find-operation-coding-system - 'insert-file-contents - (cons name (current-buffer)) t)))) + ;; The following binding causes + ;; find-buffer-file-type-coding-system + ;; (defined on dos-w32.el) to act as if + ;; the file being extracted existed, so + ;; that the file's contents' encoding is + ;; auto-detected. + (let ((file-name-handler-alist + '(("" . tar-file-name-handler)))) + (car (find-operation-coding-system + 'insert-file-contents + (cons name (current-buffer)) t))))) (multibyte enable-multibyte-characters) (detected (detect-coding-region (point-min)