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#7291: 24.0.50; `non-essential' is incomprehensible Date: Fri, 29 Oct 2010 12:20:36 -0400 Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1288372310 5485 80.91.229.12 (29 Oct 2010 17:11:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2010 17:11:50 +0000 (UTC) Cc: 7291@debbugs.gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 29 19:11:49 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PBsUQ-00043Q-A6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Oct 2010 19:11:47 +0200 Original-Received: from localhost ([127.0.0.1]:49806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBsUN-0003lZ-CE for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Oct 2010 13:11:39 -0400 Original-Received: from [140.186.70.92] (port=44184 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBsUA-0003QB-Ib for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 13:11:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBs2n-0002sU-MZ for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 12:43:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBs2n-0002sQ-JZ for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 12:43:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PBrdV-0004gc-N7; Fri, 29 Oct 2010 12:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Oct 2010 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7291 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7291-submit@debbugs.gnu.org id=B7291.128836900218001 (code B ref 7291); Fri, 29 Oct 2010 16:17:01 +0000 Original-Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 16:16:42 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBrdB-0004gI-J0 for submit@debbugs.gnu.org; Fri, 29 Oct 2010 12:16:41 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBrd9-0004gB-6C for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 12:16:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwKAMiRykzO+Krc/2dsb2JhbACgVn1yvzCFSASSKg X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="81045179" Original-Received: from 206-248-170-220.dsl.teksavvy.com (HELO ceviche.home) ([206.248.170.220]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 29 Oct 2010 12:20:37 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id C5677660F5; Fri, 29 Oct 2010 12:20:36 -0400 (EDT) In-Reply-To: (Drew Adams's message of "Thu, 28 Oct 2010 14:58:34 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 29 Oct 2010 12:17:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41231 Archived-At: >> That's because you have it backwards: >> It means that the task being performed is so UNimportant that >> the user should NOT be interrupted for it. > And there's the potential confusion. Which task is the "currently executing > code" whose task gets characterized as essential or non-essential? Elisp is single-threaded, so there is never more than one task at any given time. So I don't understand the question. > It is quite possible to read the doc and think that the "currently > executing code" refers to the code that binds this var to non-nil in > order to prevent it's own interruption. No, the docstring of a variable always describes the meaning of that variable, i.e. "what does it mean for the variable to be set to a particular value". So the code that sets the non-essential variable states that "the code is non-essential" and the code that reads it checks whether it (itself) is non-essential. > Now you are suggesting that the "task being performed" is the task > that would be _doing_ the interrupting, not the task that would be > interrupted. Again, Elisp is single-threaded, so the current code can't interrupt some other. > That comes across because you say "interrupted _for_ it" > (for the task being performed). That one word makes all the > difference - the difference between interrupted "by" some task and > interrupted "for" (i.e. to perform) some task. The docstring says: Whether the currently executing code is performing an essential task. This variable should be non-nil only when running code which should not disturb the user. ... do you also see such a potential confusion there? > The doc as written allows an interpretation of the "currently > performing task" as the task that would (not) be interrupted. It is > very easy to think that by "the currently performing task" As you can see the doc has no such "the currently performing task". >> > One could easily suppose that a non-essential task is one that it is >> > NOT IMPORTANT enough to protect against interruption. >> Yes, I thought it was so easy to suppose that, that the docstring >> was understandable. > And yet you just said above that "the task being performed is so UNimportant > that the user should NOT be interrupted for it". Yes, sorry I didn't read your sentence carefully until the end. > In one case we're talking about the nonimportance of the task that might be > interrupted (so no need to prevent interruption). In the other case we're > talking about the nonimportance of the interrupting task. But the only place where the docstring refers to the word "task" it very clearly refers to "what the currently executing code is doing". And it never uses the word "interrupt" but instead uses "disturb". > "Non-nil can prevent some tasks from interrupting the user. Some of your confusion comes from the word "interrupt", so I'd rather stick to "disturb". > Code that might perform a non-essential task can test this > variable and dispense with performing the task if the value > is non-nil. No, this is backwards: e.g. Tramp doesn't know that what it does is non-essential, which is why it needs to look up non-essential to figure that out. The only reason it does such a look up is not because it suspects this is non-essential, but because it is about to do something that may disturb the user, so it first wants to make sure it is really necessary to do it. Stefan