From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 14:58:34 -0700 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; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1288304312 29785 80.91.229.12 (28 Oct 2010 22:18:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2010 22:18:32 +0000 (UTC) Cc: 7291@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 29 00:18:31 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 1PBanG-00053Z-2N for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Oct 2010 00:18:30 +0200 Original-Received: from localhost ([127.0.0.1]:42241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBakx-0000sD-Tb for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 18:15:35 -0400 Original-Received: from [140.186.70.92] (port=40138 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBakW-0000TM-JR for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 18:15:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBaiY-00044R-73 for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 18:13:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBaiY-00044M-1Q for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 18:13:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PBaSz-0004tX-UJ; Thu, 28 Oct 2010 17:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Oct 2010 21:57: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.128830298518806 (code B ref 7291); Thu, 28 Oct 2010 21:57:01 +0000 Original-Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 21:56:25 +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 1PBaSO-0004tH-Hk for submit@debbugs.gnu.org; Thu, 28 Oct 2010 17:56:24 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBaSL-0004tC-9K for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 17:56:22 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9SM0Rtd022513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 22:00:29 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RNirEx019584; Thu, 28 Oct 2010 22:00:24 GMT Original-Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 732359981288303114; Thu, 28 Oct 2010 14:58:34 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 14:58:34 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act23GzGSW3SAiywSdaAq//uR2mekAAAd6ow X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 28 Oct 2010 17:57: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:41209 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? 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. 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. 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 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" you mean the currently running Ido or Icomplete code that binds the variable, and not the Tramp task of interrupting and reading the password. But either interpretation is possible; the result is confusion. > > 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". 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. The doc string is understandable by some and misunderstandable by others. It is not clear. > > You seem to be defending the doc as it is only because you wrote it. > > It doesn't matter that a user points out that it can be confusing? > > No, I don't actually defend it. It sucks because I'm bad at it, and > I know it. Your bug-report just rubbed me the wrong way: I > know I'm bad at it, no need to rub my face in it. ... you should be > able to provide more constructive criticism, and > not only after the Nth email exchange. No one rubbed your face in it. Please don't be so defensive - it's not about you. If you feel I offended you then I am sorry for that. I did not at first know it was you who wrote this doc, and I really don't care who wrote it. I criticized the doc, not its writer. If I had had to guess, I would have guessed that Michael A. had written the doc string (only because he works on the Tramp code). My only intention was to help so that this doc string gets clarified a bit. That should not be a big deal. You immediately resisted, however, claiming in effect that it was already clear and only an idiot would misunderstand it. As to constructive criticism, my original report suggested that we say explicitly which value (nil or non-nil) means that the code is performing a non-essential task. You resisted that suggestion, for some reason (not given). By my third reply I gave an example in case my meaning wasn't clear: "Non-nil means the currently executing code is performing a non-essential task". Likewise, I pointed out from the beginning the possible confusion over what "non-essential" means and which task was non-essential, and the need to clarify this. > >> Yes, they perform operations which are non-essential, i.e. > >> during which we don't want to pester the user. > > > > Do you see how backward that sounds? > > No I don't. Here, you refer to the Ido and Icomplete code as performing the operations that we don't want to interrupt. ("They" refers to the Ido etc. code, _not_ to the potentially interrupting Tramp code - see the passage you replied to.) So which is it? Is it the Tramp password-reading task that is "so UNimportant that the user should NOT be interrupted for it" (i.e. to perform it). Or is it the Ido and Icomplete code that "performs operations which are non-essential, i.e. during which we don't want to pester the user"? Once you decide that, you can tell the story clearly and easily. What it really comes down to, besides a choice of words, is that both sections of code determine, together, where and whether a task should be skipped, the one by binding the var to non-nil, the other by checking its value and skipping some task if non-nil. I suggest something like the following, if you feel it agrees with the behavior. "Non-nil can prevent some tasks from interrupting the user. Code that might perform a non-essential task can test this variable and dispense with performing the task if the value is non-nil. E.g., Icomplete code binds this to non-nil while gathering a collection of file names. While it is non-nil, Tramp will not read a password to check for any of files that might be remote." HTH.