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#19865: tar-untar-buffer: should honor default-directory Date: Mon, 16 Feb 2015 14:34:02 -0500 Message-ID: References: <87a90gd91b.fsf@violet.siamics.net> <83sie8wn8z.fsf@gnu.org> <831tlpvp35.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1424115326 368 80.91.229.3 (16 Feb 2015 19:35:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 19:35:26 +0000 (UTC) Cc: ivan@siamics.net, 19865@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 16 20:35:15 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 1YNRRp-0003MM-2E for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Feb 2015 20:35:13 +0100 Original-Received: from localhost ([::1]:41626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRRo-0007EE-7X for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Feb 2015 14:35:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRRj-0007An-3W for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 14:35:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNRRf-00059Y-8m for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 14:35:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNRRf-00059L-54 for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 14:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YNRRe-0003Bm-J4 for bug-gnu-emacs@gnu.org; Mon, 16 Feb 2015 14:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Feb 2015 19:35: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.142411526412203 (code B ref 19865); Mon, 16 Feb 2015 19:35:02 +0000 Original-Received: (at 19865) by debbugs.gnu.org; 16 Feb 2015 19:34:24 +0000 Original-Received: from localhost ([127.0.0.1]:45628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNRR1-0003Aj-7o for submit@debbugs.gnu.org; Mon, 16 Feb 2015 14:34:23 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:44776) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YNRQy-0003Aa-4u for 19865@debbugs.gnu.org; Mon, 16 Feb 2015 14:34:21 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t1GJYEnj021896; Mon, 16 Feb 2015 14:34:14 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 73289F86; Mon, 16 Feb 2015 14:34:02 -0500 (EST) In-Reply-To: <831tlpvp35.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Feb 2015 17:43:58 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5219=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5219> : inlines <2191> : streams <1391347> : uri <1856840> 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:99477 Archived-At: > I can only re-iterate what I already said: we shouldn't cater to > marginal use cases like that with code that is "tricky" (a.k.a. > "maintenance headache"). People who change directories of their > buffers should (and do) know what they are doing. If doing that > causes them annoyances, they will know better next time. Hmm... so you're considering `M-x cd' as harmful? I'm surprised, it looks like a perfectly normal command to me. If we don't want normal users to use, we should at least `disable-command' and/or rename it to something more verbose and less attractive. >> the command is executed by the user in one buffer, and it just so >> happens that its implementation switches to some internal auxiliary >> buffer. The value of `default-directory' that should be used is the >> one that the user knows about, not the one kept by the hidden buffer, >> over which the user has no control. > Are we still talking about the situation where a user did "M-x cd"? Actually, no, I'm talking about how the code *should* behave from a simple semantic correctness point of view. This then appears in cases such as `M-x cd' indeed, but it might appear in other cases I haven't thought about. > If the former, then is there still a problem if the user refrains from > "M-x cd"? Until we decide to deprecate `M-x cd' I think this question is not really relevant. > Understood, but unintended results do not necessarily need fixes, just > because they are unintended. The important question is: what, if any, > real problems are caused as unintended results? We are discussing > those problems, so the fact that they are unintended results doesn't > seem important to me. The patch he provides fixes the immediate problem, which in my book is a plain bug (maybe for a "corner case", but still a plain bug), but in terms of "disagrees with the docstring" and "disagrees with my mental model of what is right". Also the fix doesn't make the code more obscure or more complex. Hence I still fail to see why you're opposing it. 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". Stefan