From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19865: tar-untar-buffer: should honor default-directory Date: Tue, 17 Feb 2015 17:46:16 +0200 Message-ID: <83egpo7d87.fsf@gnu.org> References: <87a90gd91b.fsf@violet.siamics.net> <83sie8wn8z.fsf@gnu.org> <831tlpvp35.fsf@gnu.org> <83twyltz5x.fsf@gnu.org> <87sie585yc.fsf@violet.siamics.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1424188091 18994 80.91.229.3 (17 Feb 2015 15:48:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 15:48:11 +0000 (UTC) Cc: 19865@debbugs.gnu.org To: Ivan Shmakov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 17 16:48:00 2015 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 1YNkNT-0004Sh-Io for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Feb 2015 16:47:59 +0100 Original-Received: from localhost ([::1]:45971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNkNT-0004h6-2H for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Feb 2015 10:47:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNkNN-0004gY-RK for bug-gnu-emacs@gnu.org; Tue, 17 Feb 2015 10:47:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNkNK-0001j7-Eq for bug-gnu-emacs@gnu.org; Tue, 17 Feb 2015 10:47:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNkMY-0001Yz-II for bug-gnu-emacs@gnu.org; Tue, 17 Feb 2015 10:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YNkMY-0004lw-Cj for bug-gnu-emacs@gnu.org; Tue, 17 Feb 2015 10:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Feb 2015 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19865 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 19865-submit@debbugs.gnu.org id=B19865.142418797818279 (code B ref 19865); Tue, 17 Feb 2015 15:47:02 +0000 Original-Received: (at 19865) by debbugs.gnu.org; 17 Feb 2015 15:46:18 +0000 Original-Received: from localhost ([127.0.0.1]:46441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNkLp-0004kk-Eb for submit@debbugs.gnu.org; Tue, 17 Feb 2015 10:46:17 -0500 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:58804) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNkLm-0004kM-60 for 19865@debbugs.gnu.org; Tue, 17 Feb 2015 10:46:15 -0500 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NJX00K00A571A00@mtaout28.012.net.il> for 19865@debbugs.gnu.org; Tue, 17 Feb 2015 17:44:29 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJX00BRKAE5J690@mtaout28.012.net.il>; Tue, 17 Feb 2015 17:44:29 +0200 (IST) In-reply-to: <87sie585yc.fsf@violet.siamics.net> X-012-Sender: halo1@inter.net.il 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:99493 Archived-At: > From: Ivan Shmakov > Date: Tue, 17 Feb 2015 05:25:47 +0000 > > >> I agree that having to be careful in which buffer we are when we > >> read a given variable because it might be buffer-local is a source > >> of maintenance headaches, but we have that all over the place in > >> Elisp, and we don't really have any "better solution". > > > I don't really see a problem here that needs a solution. > > Yet at least two other Emacs users do. That doesn't make the use case any less marginal, IMO. You are both power users who can easily get yourself out of this trouble. Emacs maintenance shouldn't pay a price for marginal use cases for which simple workarounds (like "M-x cd BACK") are available. > > A year from now no one will remember or understand why we use > > with-current-buffer in that place. Doing so for such a weak reason > > is unwise, and no amount of cruft we have elsewhere can justify > > adding to that. > > We’re using with-current-buffer there for the sole reason that > write-region operates strictly on the current buffer. It is so > without this change, and it remains so with it; the change > maintains this status quo just perfectly. And as long as such > use /is/ acceptable in the current code, I fail to see why it > wouldn’t be in the replacement being discussed. I already explained that, more than once: the change is obscure, and is made for the sake of a marginal use case, where the user should have returned to the original directory from which she cd'ed, to avoid the problem. > What /is/ changed is that with-current-buffer will now go > immediately before write-region: > > (with-current-buffer data-buffer > (write-region …)) > > Cf. the former: > > (with-current-buffer data-buffer > … lots of code to make sure the reader’s lost… > (write-region …)) > > And at the same time: > > (let ((name (expand-file-name (the-name-of-the-archive-member)))) > …) > > Versus the current: > > (let ((name (the-name-of-the-archive-member))) > …) Now put yourself in the shoes of someone who needs to review this change many moons from now, and try to imagine how "easy" it will be for them to understand what the heck was that all about. > Please also note that the use of expand-file-name will still be > necessary if we decide to add an extra optional target-directory > argument to the function later, – and the /new/ code could > easily be changed to that effect, like: > > (unless target-directory > (setq target-directory default-directory)) > (let ((name (expand-file-name (the-name-of-the-archive-member) > target-directory))) > …) When we have an explicit directory as an argument, expanding a file name against that directory is something that is crystal-clear and doesn't require any explanations.