From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#18141: 24.4.50; saving .gz file breaks file coding Date: Wed, 06 Aug 2014 20:45:59 -0400 Message-ID: References: <9pzjfrwvsl.fsf@fencepost.gnu.org> <83iom5ptwv.fsf@gnu.org> <83tx5po5eo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1407372449 25124 80.91.229.3 (7 Aug 2014 00:47:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Aug 2014 00:47:29 +0000 (UTC) Cc: 18141@debbugs.gnu.org, vincent@vinc17.net, yamaoka@jpl.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 07 02:47:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XFBrV-0001Om-B0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Aug 2014 02:47:21 +0200 Original-Received: from localhost ([::1]:42569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBrU-00019g-R9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2014 20:47:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBrK-00018j-F1 for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:47:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFBrC-0000mn-TK for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:47:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBrC-0000mj-QA for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XFBrC-00028T-Au for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Aug 2014 00:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18141 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18141-submit@debbugs.gnu.org id=B18141.14073723708136 (code B ref 18141); Thu, 07 Aug 2014 00:47:02 +0000 Original-Received: (at 18141) by debbugs.gnu.org; 7 Aug 2014 00:46:10 +0000 Original-Received: from localhost ([127.0.0.1]:60966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XFBqL-000279-TZ for submit@debbugs.gnu.org; Wed, 06 Aug 2014 20:46:10 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:15037) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XFBqH-00026Z-QM for 18141@debbugs.gnu.org; Wed, 06 Aug 2014 20:46:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAIDvNVPAqyKr/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJC6HVgjSGReOD2sHhDgEqwODTCE X-IPAS-Result: ArYGAIDvNVPAqyKr/2dsb2JhbABZgwaDSr0vgw6BFxd0giUBAQEBAgFWIwULCzQSFBgNJC6HVgjSGReOD2sHhDgEqwODTCE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="82340578" Original-Received: from 192-171-34-171.cpe.pppoe.ca (HELO ceviche.home) ([192.171.34.171]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2014 20:45:59 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 6F95D660E0; Wed, 6 Aug 2014 20:45:59 -0400 (EDT) In-Reply-To: <83tx5po5eo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 06 Aug 2014 21:10:39 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92232 Archived-At: >> > - (let ((coding-system-for-write writecoding) >> > - (coding-system-require-warning nil)) >> > + (let ((coding-system-for-write >> > + (if filename-is-magic coding-system-for-write writecoding)) >> > + (coding-system-require-warning >> > + (if filename-is-magic coding-system-require-warning))) >> > (write-region nil nil >> > buffer-file-name nil t buffer-file-truename) >> > (setq success t)) >> I can vaguely guess why that avoids the problem > The problem is the binding of coding-system-for-write based on > incorrect interpretation of buffer-file-name. Why that causes the bug > was explained in the text you elided. The code avoids the binding, > and thus fixes its adverse effects. Actually, the code doesn't really avoid the binding: there's still a let-binding. So the variable's value is still restored when we finish. Also, while I understand that the binding is wrong, I don't understand why the "non-binding" is right. >> but I'm having a hard time seeing why the above is "right". > Do you see why the binding is "wrong"? The other problem I see is with the filename-is-magic condition which seems overly general. > I agree that reverting the original change, which introduced this > binding, is a better solution. Again, the text you elided said > precisely that. I wonder why you didn't comment on that at all. Because you said it very well, so I had nothing further to add. > As for unintended consequences, I don't see how can any come out of > that, since this just restores the code that was working for years. Hmm... so you're saying this reverts part of the change? [ I'm not very familiar with this code, in case you haven't noticed yet. ] > Of course, if you have a better suggestion that would be safe enough > for the release branch, I'm all ears. Don't know yet what to do for the release branch, but I suspect reverting is the better option since this problem has been with us for many many years already. As for the right fix: move the backup-generation to a later point. This means either to split write-region into several sub-elements that basic-save-buffer-2 can call separately. Or to add some kind of hook to write-region so basic-save-buffer-2 can use it to create the backup at the right time. I'd prefer the "split" direction since write-region is much too large for my taste. Stefan