From unknown Fri Jun 20 07:17:13 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#7291 <7291@debbugs.gnu.org> To: bug#7291 <7291@debbugs.gnu.org> Subject: Status: 24.0.50; `non-essential' is incomprehensible Reply-To: bug#7291 <7291@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:17:13 +0000 retitle 7291 24.0.50; `non-essential' is incomprehensible reassign 7291 emacs submitter 7291 "Drew Adams" severity 7291 minor tag 7291 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 27 18:28:05 2010 Received: (at submit) by debbugs.gnu.org; 27 Oct 2010 22:28:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBETS-0000XY-Ag for submit@debbugs.gnu.org; Wed, 27 Oct 2010 18:28:05 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBETQ-0000XM-7g for submit@debbugs.gnu.org; Wed, 27 Oct 2010 18:28:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBEXO-00063g-SA for submit@debbugs.gnu.org; Wed, 27 Oct 2010 18:32:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:38061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBEXF-00061V-KN for submit@debbugs.gnu.org; Wed, 27 Oct 2010 18:32:06 -0400 Received: from [140.186.70.92] (port=33888 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBEWm-0006Hb-Ue for bug-gnu-emacs@gnu.org; Wed, 27 Oct 2010 18:31:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBEWc-0005wX-Ox for bug-gnu-emacs@gnu.org; Wed, 27 Oct 2010 18:31:20 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:51127) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBEWc-0005wN-IX for bug-gnu-emacs@gnu.org; Wed, 27 Oct 2010 18:31:18 -0400 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 o9RMVCHx020371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Oct 2010 22:31:15 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9RMGons021984 for ; Wed, 27 Oct 2010 22:31:12 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 724118931288218629; Wed, 27 Oct 2010 15:30:29 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Oct 2010 15:30:28 -0700 From: "Drew Adams" To: Subject: 24.0.50; `non-essential' is incomprehensible Date: Wed, 27 Oct 2010 15:30:30 -0700 Message-ID: <9499566E643B466092A98013C6826011@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Act2Jo9Qe4AnPn5UT5Ob2KvCdXUU1w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) Variable `non-essential' was introduced in Emacs 24. The name is bad - doesn't say anything. Non-essential wrt what? The doc is bad: "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. E.g. it can be used to prevent Tramp from prompting the user for a password when we are simply scanning a set of files in the background or displaying possible completions before the user even asked for it." So does nil mean the code is performing an essential task? Or does non-nil mean that? What's an "essential task"? A task that should disturb the user (because it is important) or a task that should not disturb the user? What does "code which should not disturb the user" even mean? Sounds like this var should almost always be non-nil. But in fact it is almost always nil. So does that mean that almost all Emacs code SHOULD disturb the user? Is the doc backwards maybe? If not, then maybe the variable is named backwards: should it be `essential'? I cannot understand this. What does it really mean? Grepping the source code shows that this varis used only in `tramp-completion-mode-p' (so why isn't it called `tramp-non-essential...'?). If this is non-nil, that predicate returns non-nil, which indicates what? It supposedly indicates "whether method / user name / host name completion is active". Huh? How is anyone supposed to understand this? So let's look at where this is bound to non-nil... In icomplete.el, during `icomplete-completions'. No comment in the code. No clue as to why this code should be considered "non-essential" for Tramp. Why would icompleting necessarily indicate that "method / user name / host name completion is active" (whatever that might mean)? The only other place this is bound is in ido.el. Same questions apply. Please clean this up. It's incomprehensible. Presumably, this variable needs to be known to users who write Lisp code. If it is needed in `icomplete-completions' and for ido file-name completion then why wouldn't it also be needed in user code that does something similar (for some unknown meaning of "similar"). There are lots of 3rd-party libraries that define completion code. Why wouldn't they need to do something similar to what icomplete and ido do? How would a Lisp library writer know whether to do anything or what to do? If this variable is this important and global (no `tramp-' prefix) then it should be documented in the Elisp manual. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-10-25 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.4) --no-opt --cflags -Ic:/imagesupport/include' From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 27 20:48:28 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 00:48:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBGfL-0001cC-KP for submit@debbugs.gnu.org; Wed, 27 Oct 2010 20:48:27 -0400 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 1PBGfI-0001c6-UR for 7291@debbugs.gnu.org; Wed, 27 Oct 2010 20:48:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQJAEtmyExFxL/T/2dsb2JhbACgSHxywCyFSASSKg X-IronPort-AV: E=Sophos;i="4.58,248,1286164800"; d="scan'208";a="80869548" Received: from 69-196-191-211.dsl.teksavvy.com (HELO pastel.home) ([69.196.191.211]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 27 Oct 2010 20:52:32 -0400 Received: by pastel.home (Postfix, from userid 20848) id E5500A8558; Wed, 27 Oct 2010 20:52:31 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> Date: Wed, 27 Oct 2010 20:52:31 -0400 In-Reply-To: <9499566E643B466092A98013C6826011@us.oracle.com> (Drew Adams's message of "Wed, 27 Oct 2010 15:30:30 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > So does nil mean the code is performing an essential task? Or does > non-nil mean that? Let's see, you're asking whether "non-essential = nil" means "performing an essential task" or "performing a non-essential task"? Hmm... now that's a difficult question which I wouldn't expect any Lisp coder to be able to answer. > I cannot understand this. What does it really mean? If you can't understand it, then just ignore it. > If this variable is this important and global (no `tramp-' prefix) then > it should be documented in the Elisp manual. Emacs lived happily for more than 20 years without it, so I really have no clue whatsoever what makes you think "it's this important". Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 12:18:56 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 16:18:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBVBn-0001xX-9q for submit@debbugs.gnu.org; Thu, 28 Oct 2010 12:18:55 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBVBl-0001xS-Lz for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 12:18:54 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9SGN0c1008628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 16:23:01 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9SDuLCW004727; Thu, 28 Oct 2010 16:22:57 GMT Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 727168041288282965; Thu, 28 Oct 2010 09:22:45 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 09:22:44 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <9499566E643B466092A98013C6826011@us.oracle.com> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 09:22:43 -0700 Message-ID: <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2OmjhbQBnvrDuRwOHcEROUzZDygAfjFjQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > So does nil mean the code is performing an essential task? Or does > > non-nil mean that? > > Let's see, you're asking whether "non-essential = nil" means > "performing an essential task" or "performing a non-essential > task"? Actually, I asked whether `non-essential'=nil or `non-essential'=t means performing a non-essential task (whatever that in turn might mean). I asked about the variable value: what it's for, what it means. Do you know? The variable's only use is in Tramp. Why isn't it named with the prefix `tramp-'? Is there something more general going on? > Hmm... now that's a difficult question which I wouldn't > expect any Lisp coder to be able to answer. How cute. But if you cannot tell by reading the code and you cannot tell by reading the doc, then where are we? The doc apparently does try to answer that "difficult question", but it is not clear. Hence this doc-bug report. (Imagine a nuclear submarine with a big red flashing button labeled "UNIMPORTANT *", where the footnote `*' says "UNimportant ONLY if ______ - otherwise, IMPORTANT - push now!", where the _____ part is illegible...) The doc says something about the value determining whether or not users will be disturbed. It is unclear which value disturbs them, how it disturbs them, why or when it does so. > > I cannot understand this. What does it really mean? > > If you can't understand it, then just ignore it. Do you understand it? If so, then please clean up the doc string. That shouldn't be hard. If you do not, then let's find someone who does. > > If this variable is this important and global (no `tramp-' > > prefix) then it should be documented in the Elisp manual. > > Emacs lived happily for more than 20 years without it, so I > really have no clue whatsoever what makes you think "it's > this important". By that reasoning, we should simply remove the variable altogether. It wasn't needed during the last 20 years so it must not be needed now. (!?) You admit that the doc for this is incomprehensible and misleading. But you say that doesn't matter because this variable wasn't necessary for the previous 20 years. Huh? Still, I would like to know what this is about. Especially since it apparently matters for code that involves file-name completion. Is there something special about Ido and Icomplete that this should single them out for its treatment (whatever that treatment might be)? Or does it apply generally to file-name completion code? From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 13:10:00 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 17:10:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBVzD-0002K5-ME for submit@debbugs.gnu.org; Thu, 28 Oct 2010 13:09:59 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBVzC-0002K0-AY for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 13:09:58 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id o9SHE681006433; Thu, 28 Oct 2010 13:14:06 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 2497FB4681; Thu, 28 Oct 2010 13:14:06 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> Date: Thu, 28 Oct 2010 13:14:06 -0400 In-Reply-To: <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> (Drew Adams's message of "Thu, 28 Oct 2010 09:22:43 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3662=0 X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >> > So does nil mean the code is performing an essential task? Or does >> > non-nil mean that? >> Let's see, you're asking whether "non-essential = nil" means >> "performing an essential task" or "performing a non-essential >> task"? > Actually, I asked whether `non-essential'=nil or `non-essential'=t means > performing a non-essential task (whatever that in turn might mean). Right, same thing: the answer can be found by using, not the code nor the docstring, but: your brain. > The variable's only use is in Tramp. Why isn't it named with the prefix > `tramp-'? Is there something more general going on? It's used by icomplete and ido as well, so clearly it's not a Tramp-only variable. The fact that only Tramp reacts to it right now is not significant. > You admit that the doc for this is incomprehensible and misleading. No I don't. Apparently you don't understand it, but since you can't even figure out which of "non-essential=nil" or "non-essential=t" means that the executed code is non-essential, I think you're disqualified to judge. Of course, I'm disqualified as well since I wrote it, so we're left with a lack of judgment. > Still, I would like to know what this is about. Especially since it > apparently matters for code that involves file-name completion. > Is there something special about Ido and Icomplete that this should > single them out for its treatment (whatever that treatment might be)? > Or does it apply generally to file-name completion code? Yes, they perform operations which are non-essential, i.e. during which we don't want to pester the user. The particular example where it's currently used is: prompt the user for a password just in order to show the list of possible completions when the user hasn't even asked for completion (other than by turning on icomplete or ido which causes completions to be displayed eagerly). Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 13:34:04 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 17:34:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBWMW-0002Uv-55 for submit@debbugs.gnu.org; Thu, 28 Oct 2010 13:34:04 -0400 Received: from eagle.jhcloos.com ([207.210.242.212]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBWMS-0002UZ-V3 for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 13:34:01 -0400 Received: by eagle.jhcloos.com (Postfix, from userid 10) id E484D400E5; Thu, 28 Oct 2010 17:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1288287489; bh=jvPCoE8Ah+v+p3t/EHU0yaxTjUwWJrKeerBsUsZyztI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=A0ZJ7GLGt8Duq8pIzALwOa+jN98ioDLDeOS6gcyJlsg2zGmj93+j2mLjaxE8YudLb J4BuH4K9jMg5qggk2q6R11IGfXyChnKaTwq+dArc6bq3snBuEAgITjQxX04w8JeGF8 +cuRtWELFoMKGEM2bYoCA7aqyyc6Fa+44ipS7RBQ= Received: from carbon (localhost [127.0.0.1]) by carbon.jhcloos.org (Postfix) with ESMTP id BA15A1E9E21; Thu, 28 Oct 2010 17:33:15 +0000 (UTC) From: James Cloos To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible In-Reply-To: <9499566E643B466092A98013C6826011@us.oracle.com> (Drew Adams's message of "Wed, 27 Oct 2010 15:30:30 -0700") References: <9499566E643B466092A98013C6826011@us.oracle.com> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg== Copyright: Copyright 2009 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 28 Oct 2010 13:33:15 -0400 Message-ID: Lines: 40 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:101028:drew.adams@oracle.com::Vk+awnc8qN2Hb/YE:000000000000000000000000000000000000000kDlED X-Hashcash: 1:30:101028:7291@debbugs.gnu.org::eziKdNBWrHVqgPol:0000000000000000000000000000000000000000r/y2+ X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) >>>>> "DA" == Drew Adams writes: DA> Variable `non-essential' was introduced in Emacs 24. DA> The name is bad - doesn't say anything. Non-essential wrt what? DA> The doc is bad: DA> "Whether the currently executing code is performing an essential DA> task. This variable should be non-nil only when running code which DA> should not disturb the user. E.g. it can be used to prevent Tramp DA> from prompting the user for a password when we are simply scanning a DA> set of files in the background or displaying possible completions DA> before the user even asked for it." [Just translating between english and english here -JimC] Seems clear here. If the variable is nil tramp will be happy to do user-interactive stuff, such as prompting the user for a password. But tramp would prefer that the variable be set to non-nil in any function which does remote work which will not require such user- interaction. DA> So does nil mean the code is performing an essential task? Or does DA> non-nil mean that? What's an "essential task"? A task that should DA> disturb the user (because it is important) or a task that should not DA> disturb the user? I think you are thinking about it the wrong way -- or at least sufficiently differently than the authors as to fail to see their meaning. (Please do not take that as a flame.) Don't think "importance" but rather "will this require user interaction to succeed?". And set to nil if it will require user interaction to succeed. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 14:39:33 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 18:39:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXNs-0002vr-0w for submit@debbugs.gnu.org; Thu, 28 Oct 2010 14:39:32 -0400 Received: from mailout-de.gmx.net ([213.165.64.23] helo=mail.gmx.net) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1PBXNp-0002vm-6g for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 14:39:30 -0400 Received: (qmail invoked by alias); 28 Oct 2010 18:43:37 -0000 Received: from p4FC18D9F.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [79.193.141.159] by mail.gmx.net (mp067) with SMTP; 28 Oct 2010 20:43:37 +0200 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19SNRQZzFZSfd9pFKQR50r2da2Wt7fhFP1Wd/kYQp /zrYWB8OvrpnF4 From: Michael Albinus To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> Date: Thu, 28 Oct 2010 20:43:26 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 28 Oct 2010 13:14:06 -0400") Message-ID: <8739rqgnu9.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Hi Drew, Stefan Monnier writes: > No I don't. Apparently you don't understand it, but since you can't > even figure out which of "non-essential=nil" or "non-essential=t" means > that the executed code is non-essential, I think you're disqualified > to judge. Of course, I'm disqualified as well since I wrote it, so > we're left with a lack of judgment. I'm also disqualified because I was involved in introducing this variable. But you could read the background story at . HTH, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 14:48:23 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 18:48:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXWR-0002zi-6C for submit@debbugs.gnu.org; Thu, 28 Oct 2010 14:48:23 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXWO-0002zd-Cs for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 14:48:21 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9SIqSww024794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 18:52:29 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9SGt5LM029353; Thu, 28 Oct 2010 18:52:27 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 727672871288291892; Thu, 28 Oct 2010 11:51:32 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 11:51:31 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 11:51:31 -0700 Message-ID: <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2w43OxKl6SzgPQBenJIvhuy8mLAAAocgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > the answer can be found by using, not the code nor > the docstring, but: your brain. Personal insults are really not necessary, Stefan. > > The variable's only use is in Tramp. Why isn't it named > > with the prefix `tramp-'? Is there something more general > > going on? > > It's used by icomplete and ido as well, so clearly it's not > a Tramp-only variable. The fact that only Tramp reacts to it > right now is not significant. As I said in the original report, it is _used_ only in tramp.el, and it is _bound_ in ido.el and icomplete.el. AFAICT, the _reason_ it is bound there is for Tramp and Tramp alone. If some day this var were to have some additional effect, besides preventing Tramp from reading passwords, then ido.el and icomplete.el might need to be revisited. Any such additional (non-Tramp) effect would at least have to take into consideration any existing users such as ido.el and icomplete.el, in order to be sure not to break them. So the relation with Tramp is hardly insignificant. > Apparently you don't understand it, but since you can't > even figure out which of "non-essential=nil" or > "non-essential=t" means that the executed code is non-essential, > I think you're disqualified to judge. I am qualified to judge that the doc string is confusing to at least one reader, me. And as a longtime professional doc writer, it is likely that I'm somewhat qualified to guess that it might be confusing to some other readers as well. It's not so much that I can't figure things out from the code as it is that I think the current doc can confuse readers. FWIW, I have bound this var for six months now in my own completion code. It is the doc string that this bug report is about. The typical Emacs convention for such a doc string is to say clearly, preferably in the first line, what a nil or non-nil value means. For example: "Non-nil means the currently executing code is performing a non-essential task" or "nil means the executing code is performing an essential task". Not "_Whether_ the currently executing code is performing an essential task", which is ambiguous. That's the first change that should be made: state explicitly the particular value that means "non-essential" (or "essential"). The second change is to state what "non-essential" means here. It apparently means that the task being performed is so IMPORTANT that the user should NOT be interrupted (e.g. to read a password). And that goes somewhat against the usual meaning of "non-essential". One could easily suppose that a non-essential task is one that it is NOT IMPORTANT enough to protect against interruption. Especially because of this unusual interpretation, the meaning (behavior) needs to be pointed out clearly. I am not arguing that you should call it "essential" instead of "non-essential". An argument can be made for either - the devil is in the details (the actual behavior). The password reading would, yes, be unimportant here, non-essential (useless in fact, since no access is really needed at that point), so we dispense with it in order not to disrupt the user. I get that. But the "currently executing code" that would be interrupted by a password reading is not performing an unimportant, non-essential task - what it is doing is more important than reading a password, and we don't want to interrupt it. My point is only that the behavior needs to be stated clearly, and that is not the case now. And interrupted by what? In practice, so far at least, the answer is password-prompting. The example in the doc string is OK for pointing this out. > Of course, I'm disqualified as well since I wrote it, so > we're left with a lack of judgment. 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? > > Still, I would like to know what this is about. Especially since it > > apparently matters for code that involves file-name completion. > > Is there something special about Ido and Icomplete that this should > > single them out for its treatment (whatever that treatment > > might be)? Or does it apply generally to file-name completion code? > > 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? Do we want to pester the user only when s?he is performing _essential_ tasks? The behavior is no doubt consistent, but the terminology is, well, "creative". That's OK, if you explain it clearly. You can call it a "throunbof" task if you like, as long as you say what is meant by that term. > The particular example where it's currently used is: prompt the > user for a password just in order to show > the list of possible completions when the user hasn't even asked for > completion (other than by turning on icomplete or ido which causes > completions to be displayed eagerly). Yes, and that's why I have had it bound to non-nil in Icicles since last May when Michael Albinus informed me about it. And that's why I'm suggesting that we make this feature clear in the doc, for the benefit of other 3rd-party completion libraries (and for users generally). From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 14:50:29 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 18:50:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXYT-00030c-JO for submit@debbugs.gnu.org; Thu, 28 Oct 2010 14:50:29 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXYS-00030X-8j for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 14:50:28 -0400 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 o9SIsYTI031056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 18:54:36 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9S8Z6J3006112; Thu, 28 Oct 2010 18:54:33 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 727677281288291984; Thu, 28 Oct 2010 11:53:04 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 11:53:04 -0700 From: "Drew Adams" To: "'James Cloos'" References: <9499566E643B466092A98013C6826011@us.oracle.com> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 11:53:04 -0700 Message-ID: <574D27E117CE4DC18C451B99A12A456E@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2xuUhCVKxak7KQAujNW73FMZRMgAB8IBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > Seems clear here. If the variable is nil tramp will be happy to do > user-interactive stuff, such as prompting the user for a password. Which means that the task that was interrupted was "essential"? Can you imagine that a reader might think that an "essential" task would be one that you do NOT want interrupted, not the opposite? > But tramp would prefer that the variable be set to non-nil in any > function which does remote work which will not require such user- > interaction. Actually, it is set to non-nil in functions that are NOT (yet) doing any remote work, functions that (so far) just want to gather a list of possible file names (for completion), whether the files are remote or not. The idea is that the user should be prompted for a password only when s?he actually tries to visit the remote file (real access). > I think you are thinking about it the wrong way -- or at least > sufficiently differently than the authors as to fail to see their > meaning. No, I get the author's meaning. My point is that some readers will not. The doc as written lends itself easily to confusion. It is not the author's meaning that is in question here, but how that meaning is communicated. > Don't think "importance" but rather "will this require user > interaction to succeed?". If we have to tell readers how to think when they try to read the explanation, in particular that "essential" does not mean "important" (and what does that mean?), then the doc could benefit from clarification. To write clear doc one needs to look for ways that readers might interpret differently what is said, giving them an understanding that does not match what was meant. Writing doc is similar to writing a spec: if an alternate model also fits, then the spec is too loose. > And set to nil if it will require user interaction to succeed. What does "it succeeds" mean in this context? Stefan makes the point that this is something general, it's not just about password reading. If so, then the explanation needs to make sense at that level. From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 16:08:12 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 20:08:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBYlf-0004Ak-3c for submit@debbugs.gnu.org; Thu, 28 Oct 2010 16:08:11 -0400 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 1PBYlb-0004Ac-IS for 7291@debbugs.gnu.org; Thu, 28 Oct 2010 16:08:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwKADd2yUzO+Krc/2dsb2JhbACgVHxyvzqDE4I1BJIq X-IronPort-AV: E=Sophos;i="4.58,253,1286164800"; d="scan'208";a="80974726" Received: from 206-248-170-220.dsl.teksavvy.com (HELO pastel.home) ([206.248.170.220]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 28 Oct 2010 16:12:16 -0400 Received: by pastel.home (Postfix, from userid 20848) id 564A9A8559; Thu, 28 Oct 2010 16:12:16 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Date: Thu, 28 Oct 2010 16:12:16 -0400 In-Reply-To: <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> (Drew Adams's message of "Thu, 28 Oct 2010 11:51:31 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >> the answer can be found by using, not the code nor >> the docstring, but: your brain. > Personal insults are really not necessary, Stefan. Honestly, I can't think of any way someone who has the least bit of familiarity with Elisp can wonder "whether `non-essential'=nil or `non-essential'=t means performing a non-essential task (whatever that in turn might mean)". > AFAICT, the _reason_ it is bound there is for Tramp and Tramp alone. No. At most, the problem that triggered the introduction of this was linked to interactions between Tramp and ido/icomplete. So there's a link to Tramp, but it's not there "for Tramp alone". > If some day this var were to have some additional effect, besides > preventing Tramp from reading passwords, then ido.el and icomplete.el > might need to be revisited. No. The whole reason why it has such a docstring and a generic name is so that we can decide whether it's right for icomplete to use it regardless of what Tramp does with it, and similarly we can decide whether it's right for Tramp to use it regardless of where it's bound. > The second change is to state what "non-essential" means here. > It apparently means that the task being performed is so IMPORTANT that > the user should NOT be interrupted (e.g. to read a password). > And that goes somewhat against the usual meaning of "non-essential". 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. > 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. > 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. "As a longtime professional doc writer" you should be able to provide more constructive criticism, and not only after the Nth email exchange. >> 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. > Do we want to pester the user only when s?he is performing > _essential_ tasks? We're talking about what the code does, not about what the user does. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 28 17:56:25 2010 Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 21:56:25 +0000 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 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 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 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 Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 732359981288303114; Thu, 28 Oct 2010 14:58:34 -0700 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 14:58:34 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com><7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 14:58:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act23GzGSW3SAiywSdaAq//uR2mekAAAd6ow X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 04:32:10 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 08:32:10 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBkNe-0000o7-04 for submit@debbugs.gnu.org; Fri, 29 Oct 2010 04:32:10 -0400 Received: from mail-out.m-online.net ([212.18.0.9]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBkNa-0000nl-KG for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 04:32:07 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id EC4001C15AF5; Fri, 29 Oct 2010 10:36:16 +0200 (CEST) Received: from hase.home (ppp-93-104-142-159.dynamic.mnet-online.de [93.104.142.159]) by mail.mnet-online.de (Postfix) with ESMTP id 736111C00329; Fri, 29 Oct 2010 10:36:16 +0200 (CEST) From: Andreas Schwab To: Stefan Monnier Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> X-Yow: Yow! I'm UNEMPLOYED! Date: Fri, 29 Oct 2010 10:36:16 +0200 In-Reply-To: (Stefan Monnier's message of "Thu, 28 Oct 2010 16:12:16 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Stefan Monnier writes: > Honestly, I can't think of any way someone who has the least bit of > familiarity with Elisp can wonder "whether `non-essential'=nil or > `non-essential'=t means performing a non-essential task (whatever that > in turn might mean)". The variable is badly named. It should be using a positive form, like allow-whatever. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 11:58:53 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 15:58:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBrLx-0004YE-Ba for submit@debbugs.gnu.org; Fri, 29 Oct 2010 11:58:53 -0400 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 1PBrLv-0004Y9-Op for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 11:58:51 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwKABSNykzO+Krc/2dsb2JhbACgVn1yvyiFSASSKg X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="81043863" 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:03:03 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 64191660F5; Fri, 29 Oct 2010 12:03:03 -0400 (EDT) From: Stefan Monnier To: Andreas Schwab Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Date: Fri, 29 Oct 2010 12:03:03 -0400 In-Reply-To: (Andreas Schwab's message of "Fri, 29 Oct 2010 10:36:16 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >> Honestly, I can't think of any way someone who has the least bit of >> familiarity with Elisp can wonder "whether `non-essential'=nil or >> `non-essential'=t means performing a non-essential task (whatever that >> in turn might mean)". > The variable is badly named. It should be using a positive form, like > allow-whatever. `allow-whatever' does strike me as being any better. Any other suggestion? Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 12:16:42 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 16:16:42 +0000 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 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" 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 Received: by ceviche.home (Postfix, from userid 20848) id C5677660F5; Fri, 29 Oct 2010 12:20:36 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Date: Fri, 29 Oct 2010 12:20:36 -0400 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) >> 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 12:17:37 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 16:17:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBre4-0004gv-03 for submit@debbugs.gnu.org; Fri, 29 Oct 2010 12:17:36 -0400 Received: from mail-out.m-online.net ([212.18.0.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBre1-0004gq-Qc for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 12:17:34 -0400 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id D0A991C00249; Fri, 29 Oct 2010 18:21:44 +0200 (CEST) Received: from hase.home (ppp-93-104-142-159.dynamic.mnet-online.de [93.104.142.159]) by mail.mnet-online.de (Postfix) with ESMTP id 53DF11C0038C; Fri, 29 Oct 2010 18:21:44 +0200 (CEST) From: Andreas Schwab To: Stefan Monnier Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> X-Yow: Dizzy, are we "REAL PEOPLE" or "AMAZING ANIMALS"? Date: Fri, 29 Oct 2010 18:21:44 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 29 Oct 2010 12:03:03 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Stefan Monnier writes: >>> Honestly, I can't think of any way someone who has the least bit of >>> familiarity with Elisp can wonder "whether `non-essential'=nil or >>> `non-essential'=t means performing a non-essential task (whatever that >>> in turn might mean)". >> The variable is badly named. It should be using a positive form, like >> allow-whatever. > > `allow-whatever' does strike me as being any better. What's wrong with it? Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 12:44:53 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 16:44:53 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBs4R-0004tc-Uw for submit@debbugs.gnu.org; Fri, 29 Oct 2010 12:44:53 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBs4Q-0004tX-Ak for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 12:44:50 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9TGn0YX008197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Oct 2010 16:49:01 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9TGmxZG030063; Fri, 29 Oct 2010 16:48:59 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 734787831288370848; Fri, 29 Oct 2010 09:47:28 -0700 Received: from dradamslap1 (/10.159.223.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Oct 2010 09:47:26 -0700 From: "Drew Adams" To: "'Stefan Monnier'" References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com><7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Fri, 29 Oct 2010 09:47:26 -0700 Message-ID: <814E70A041AB4DC2A29E614DB19D2247@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: Act3hUHjuGw3DcnHQquAzsqmPn2ZpQAAGN3g X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > 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, Precisely why I said that the task to be performed _might_ be non-essential. Tramp knows that its operation might be disruptive, and it knows that some other code might not want that disruption, and that to communicate that the other code might indicate that the interruption action is "non-essential" (in which case it should be skipped). This variable is about conditionally inhibiting certain actions that could disrupt the user. It would be better for it to be named something that reflects that, but I'm not going to fight that battle. (Consequently, I won't bother to suggest a different name. I'll just say that that is what this var is about - it is not about "non-essential" anything.) > which is why it needs to look up non-essential > to figure that out. And that is why I said that Tramp can test the variable and skip the task if the value indicates non-essential. We are saying the same thing, or trying to. > 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. We agree about you wrote in this paragraph (starting with "Tramp doesn't know"). That's just what I tried to say too. So I suggest you put such info into the doc string. I have no objection to your wording here or similar. Both parts of the story need to be presented clearly: (1) the code such as Tramp that conditionally disturbs the user (depending on the var value) and (2) the code such as Icomplete that binds the var during an operation that it does not want interrupted. HTH. From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 13:32:02 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 17:32:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBso5-0005Dx-NI for submit@debbugs.gnu.org; Fri, 29 Oct 2010 13:32:01 -0400 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 1PBso3-0005Dq-O6 for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 13:32:00 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwKAGKjykzO+Krc/2dsb2JhbACgVn1yv0OFSASSKg X-IronPort-AV: E=Sophos;i="4.58,260,1286164800"; d="scan'208";a="81051972" 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 13:36:11 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 9FE36660F5; Fri, 29 Oct 2010 13:36:11 -0400 (EDT) From: Stefan Monnier To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <814E70A041AB4DC2A29E614DB19D2247@us.oracle.com> Date: Fri, 29 Oct 2010 13:36:11 -0400 In-Reply-To: <814E70A041AB4DC2A29E614DB19D2247@us.oracle.com> (Drew Adams's message of "Fri, 29 Oct 2010 09:47:26 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) Other than the "non-nil" part on the first line, I still don't know what's ambiguous about the rest of the current docstring. Your suggested wording sounds largely incomprehensible to me, so while it may be better for some, it's clearly not good enough to replace the current wording. > Both parts of the story need to be presented clearly: (1) the code > such as Tramp that conditionally disturbs the user (depending on the > var value) and (2) the code such as Icomplete that binds the var > during an operation that it does not want interrupted. It's not that icomplete doesn't want an operation to be interrupted, it's that it doesn't want this operation to disturb the user. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 14:25:33 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 18:25:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBtds-0005Zf-Ui for submit@debbugs.gnu.org; Fri, 29 Oct 2010 14:25:33 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBtdp-0005Za-Ue for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 14:25:30 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LB200200DW0WO00@a-mtaout20.012.net.il> for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 20:29:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.229.202]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LB2002VBE1CUJ10@a-mtaout20.012.net.il>; Fri, 29 Oct 2010 20:29:40 +0200 (IST) Date: Fri, 29 Oct 2010 20:29:43 +0200 From: Eli Zaretskii Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <837hh07syw.fsf@gnu.org> References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, schwab@linux-m68k.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Stefan Monnier > Date: Fri, 29 Oct 2010 12:03:03 -0400 > Cc: 7291@debbugs.gnu.org > > > The variable is badly named. It should be using a positive form, like > > allow-whatever. > > `allow-whatever' does strike me as being any better. > Any other suggestion? suppress-non-essential-prompts? From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 14:39:32 2010 Received: (at 7291) by debbugs.gnu.org; 29 Oct 2010 18:39:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBtrP-0005gb-3F for submit@debbugs.gnu.org; Fri, 29 Oct 2010 14:39:32 -0400 Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBtrM-0005gV-FM for 7291@debbugs.gnu.org; Fri, 29 Oct 2010 14:39:29 -0400 Received: (qmail 46970 invoked by uid 3782); 29 Oct 2010 18:43:39 -0000 Received: from acm.muc.de (pD9E503E7.dip.t-dialin.net [217.229.3.231]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Fri, 29 Oct 2010 20:43:38 +0200 Received: (qmail 3368 invoked by uid 1000); 29 Oct 2010 18:56:59 -0000 Date: Fri, 29 Oct 2010 18:56:59 +0000 To: Stefan Monnier Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Message-ID: <20101029185659.GA3080@muc.de> References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) Hi, Stefan! On Thu, Oct 28, 2010 at 04:12:16PM -0400, Stefan Monnier wrote: > Honestly, I can't think of any way someone who has the least bit of > familiarity with Elisp can wonder "whether `non-essential'=nil or > `non-essential'=t means performing a non-essential task (whatever that > in turn might mean)". Me. How should I get the notion of "task" from the logically incomplete phrase "non-essential? Please change the name of this variable to say what it means. "Non-essential" is way, way too abstract (in the sense of woolly, meaningless). I write the following as a native English speaker. The word "essential" describes a _RELATIONSHIP_ between _TWO_ nouns: A is essential to B if B without A wouldn't be B at all. For example, an extension language is essential to Emacs (?Emacs without an extension language?), and love is essential to a marriage (?a marriage without love?). To say that something is "essential" is like saying something is "better". Lacking the other noun (possibly implied), it's meaningless. The variable name "non-essential" is meaningless. The doc string helps a little, but not enough. It doesn't say what the task being executed is essential _to_. What would not be what it is to be, were the "essential task" to be missing? Such vagueness and linguistic misuse causes not only puzzlement, but also anger, revulsion and contempt. Please rename the variable to say what it means. Thanks! > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 29 18:56:49 2010 Received: (at submit) by debbugs.gnu.org; 29 Oct 2010 22:56:49 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBxsP-0007g8-3E for submit@debbugs.gnu.org; Fri, 29 Oct 2010 18:56:49 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBxsN-0007g2-Kk for submit@debbugs.gnu.org; Fri, 29 Oct 2010 18:56:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBxwR-0000PY-JE for submit@debbugs.gnu.org; Fri, 29 Oct 2010 19:01:00 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_RP_MATCHES_RCVD, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:46885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBxwR-0000PU-H6 for submit@debbugs.gnu.org; Fri, 29 Oct 2010 19:00:59 -0400 Received: from [140.186.70.92] (port=35264 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBxwQ-0005GI-7H for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 19:00:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBxwO-0000PI-Re for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 19:00:58 -0400 Received: from lo.gmane.org ([80.91.229.12]:33137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBxwO-0000P8-L5 for bug-gnu-emacs@gnu.org; Fri, 29 Oct 2010 19:00:56 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PBxwJ-0005DJ-7A for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 01:00:51 +0200 Received: from bb-87-81-240-236.ukonline.co.uk ([87.81.240.236]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Oct 2010 01:00:51 +0200 Received: from andrewjmoreton by bb-87-81-240-236.ukonline.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Oct 2010 01:00:51 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Andy Moreton Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Sat, 30 Oct 2010 00:00:33 +0100 Lines: 15 Message-ID: <82hbg4vc32.fsf@gmail.com> References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <837hh07syw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: bb-87-81-240-236.ukonline.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt) Cancel-Lock: sha1:RjytoRXNPukmCVdmH9AO1fwWzss= X-Antivirus: avast! (VPS 101029-2, 29/10/2010), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -5.9 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) On Fri 29 Oct 2010, Eli Zaretskii wrote: >> From: Stefan Monnier >> Date: Fri, 29 Oct 2010 12:03:03 -0400 >> Cc: 7291@debbugs.gnu.org >> >> > The variable is badly named. It should be using a positive form, like >> > allow-whatever. >> >> `allow-whatever' does strike me as being any better. >> Any other suggestion? > > suppress-non-essential-prompts? allow-user-interaction ? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 02:48:20 2010 Received: (at submit) by debbugs.gnu.org; 30 Oct 2010 06:48:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PC5Ei-00028v-8O for submit@debbugs.gnu.org; Sat, 30 Oct 2010 02:48:20 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PC5EW-00028q-Ak for submit@debbugs.gnu.org; Sat, 30 Oct 2010 02:48:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PC5Ib-00026Q-8M for submit@debbugs.gnu.org; Sat, 30 Oct 2010 02:52:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:42032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PC5Ib-00026M-6R for submit@debbugs.gnu.org; Sat, 30 Oct 2010 02:52:21 -0400 Received: from [140.186.70.92] (port=42027 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PC5Ia-00078C-3P for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 02:52:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PC5IZ-00025o-1s for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 02:52:19 -0400 Received: from mtaout21.012.net.il ([80.179.55.169]:54277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PC5IY-00025e-RT for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 02:52:19 -0400 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LB300E00C2TI200@a-mtaout21.012.net.il> for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 08:52:17 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.126.229.202]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LB300ES6CF4CK60@a-mtaout21.012.net.il>; Sat, 30 Oct 2010 08:52:17 +0200 (IST) Date: Sat, 30 Oct 2010 08:52:23 +0200 From: Eli Zaretskii Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible In-reply-to: <82hbg4vc32.fsf@gmail.com> X-012-Sender: halo1@inter.net.il To: Andy Moreton Message-id: <83zktw5g0o.fsf@gnu.org> References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <837hh07syw.fsf@gnu.org> <82hbg4vc32.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -2.4 (--) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) > From: Andy Moreton > Date: Sat, 30 Oct 2010 00:00:33 +0100 > Cc: > > On Fri 29 Oct 2010, Eli Zaretskii wrote: > > >> From: Stefan Monnier > >> Date: Fri, 29 Oct 2010 12:03:03 -0400 > >> Cc: 7291@debbugs.gnu.org > >> > >> > The variable is badly named. It should be using a positive form, like > >> > allow-whatever. > >> > >> `allow-whatever' does strike me as being any better. > >> Any other suggestion? > > > > suppress-non-essential-prompts? > > allow-user-interaction ? "User interaction" is too general, IMO. Almost as general as the original name, which is one of the reasons for this bug report. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 12:13:26 2010 Received: (at submit) by debbugs.gnu.org; 30 Oct 2010 16:13:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCE3Z-0006Vj-EF for submit@debbugs.gnu.org; Sat, 30 Oct 2010 12:13:25 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCE3X-0006Ve-4o for submit@debbugs.gnu.org; Sat, 30 Oct 2010 12:13:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCE7c-0000iR-MY for submit@debbugs.gnu.org; Sat, 30 Oct 2010 12:17:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:50234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCE7c-0000iL-K2 for submit@debbugs.gnu.org; Sat, 30 Oct 2010 12:17:36 -0400 Received: from [140.186.70.92] (port=53868 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCE7b-0002G5-DQ for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 12:17:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCE7a-0000hf-4T for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 12:17:35 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:63802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCE7Y-0000hI-Nl; Sat, 30 Oct 2010 12:17:32 -0400 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 o9UGHRin011634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Oct 2010 16:17:29 GMT 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 o9UEZojx013439; Sat, 30 Oct 2010 16:17:27 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 736504391288455376; Sat, 30 Oct 2010 09:16:16 -0700 Received: from dradamslap1 (/10.159.217.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Oct 2010 09:16:15 -0700 From: "Drew Adams" To: "'Eli Zaretskii'" , "'Andy Moreton'" References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com><7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <837hh07syw.fsf@gnu.org> <82hbg4vc32.fsf@gmail.com> <83zktw5g0o.fsf@gnu.org> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Sat, 30 Oct 2010 09:16:16 -0700 Message-ID: <6EF41FA484C34DC2AAE23367231A3C84@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83zktw5g0o.fsf@gnu.org> Thread-Index: Act4Afft1U+nm5VqQQGob5kdbAwF/QARVHFg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: submit Cc: bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > >> > The variable is badly named. It should be using a > > >> > positive form, like allow-whatever. > > >> > > >> `allow-whatever' does [NOT?] strike me as being any better. > > >> Any other suggestion? > > > > > > suppress-non-essential-prompts? > > > > allow-user-interaction ? > > "User interaction" is too general, IMO. Almost as general as the > original name, which is one of the reasons for this bug report. Stefan wants it to be general. He says it is not necessarily about Tramp or prompting or even interupting the user. It is about "disturbing" the user. --- One last attempt to get past the mauvaise foi... This var is a `PLEASE DO NOT DISTURB' sign for the user's hotel room. Nothing prevents firemen from entering. Maids know that their services are not important enough to ignore a do-not-disturb | no-molestar | ne-pas-deranger | nao-perturbe | non-disturbare request. This knowledge is built into their code. Firemen do not even notice the sign. Maids actively keep an eye out for it - that's part of their job. The user is a tempermental, often drunk&drugged musician who has a manager. The manager code hangs the sign on the door when appropriate. The maid code recognizes the sign and is polite enough not to enter to perform routine housekeeping. Icomplete is a musician manager. Tramp is a hotel maid. (defvar do-not-disturb nil "Non-nil is a sign to avoid disturbing the user. Code that performs a relatively unimportant action that might disturb the user can check this variable and choose not to act when it is non-nil. Code that wants to make other code aware that it might not be good to disturb the user now unnecessarily can bind this to non-nil. Example: Icomplete binds this to non-nil when collecting file names as completion candidates. Tramp checks the value before attempting to read a password for a remote file name: if non-nil then it does no password prompting.") --- Next week we will discuss room service. This code looks for the `do-not-disturb' sign, but it also checks the particular non-nil value for the advisory level. If it sees `this-means-YOU-too' or a list value that includes item `room-service' then it does not even think about knocking, let alone entering. The week after next we will study Homeland Security Advisory System threat levels: `severe', `high', `significant', `general', and `low'. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 13:50:26 2010 Received: (at submit) by debbugs.gnu.org; 30 Oct 2010 17:50:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCFZS-00078X-Ce for submit@debbugs.gnu.org; Sat, 30 Oct 2010 13:50:26 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCFZP-00078S-VB for submit@debbugs.gnu.org; Sat, 30 Oct 2010 13:50:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCFdV-00066e-6T for submit@debbugs.gnu.org; Sat, 30 Oct 2010 13:54:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:54219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCFdH-000626-1a for submit@debbugs.gnu.org; Sat, 30 Oct 2010 13:54:37 -0400 Received: from [140.186.70.92] (port=53991 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCFcz-0004dH-0h for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 13:54:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCFcu-0005zp-Qt for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 13:54:03 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]:37774 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PCFcu-0005zH-EN for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 13:54:00 -0400 Received: (qmail invoked by alias); 30 Oct 2010 17:53:57 -0000 Received: from p4FC184D2.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [79.193.132.210] by mail.gmx.net (mp049) with SMTP; 30 Oct 2010 19:53:57 +0200 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX186iiUf2Oo6ToeooHeI0vAkj1GZeQinfZMWP2vnr8 w7QWdk7dSyT+UV From: Michael Albinus To: "Drew Adams" Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible References: <9499566E643B466092A98013C6826011@us.oracle.com> <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <837hh07syw.fsf@gnu.org> <82hbg4vc32.fsf@gmail.com> <83zktw5g0o.fsf@gnu.org> <6EF41FA484C34DC2AAE23367231A3C84@us.oracle.com> Date: Sat, 30 Oct 2010 19:53:54 +0200 In-Reply-To: <6EF41FA484C34DC2AAE23367231A3C84@us.oracle.com> (Drew Adams's message of "Sat, 30 Oct 2010 09:16:16 -0700") Message-ID: <8739rnlg7h.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit Cc: 'Eli Zaretskii' , 'Andy Moreton' , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.4 (----) "Drew Adams" writes: > One last attempt to get past the mauvaise foi... > > This var is a `PLEASE DO NOT DISTURB' sign for the user's hotel > room. > > Nothing prevents firemen from entering. Maids know that their=20 > services are not important enough to ignore a do-not-disturb | > no-molestar | ne-pas-deranger | nao-perturbe | non-disturbare=20 > request. This knowledge is built into their code. > > Firemen do not even notice the sign. Maids actively keep an > eye out for it - that's part of their job. > > The user is a tempermental, often drunk&drugged musician who > has a manager. The manager code hangs the sign on the door > when appropriate. The maid code recognizes the sign and is > polite enough not to enter to perform routine housekeeping. > > Icomplete is a musician manager. Tramp is a hotel maid. I insist in being informed in German. "Bitte nicht st=C3=B6ren". Otherwise,= I do whatever I want to do. > (defvar do-not-disturb nil > "Non-nil is a sign to avoid disturbing the user. > Code that performs a relatively unimportant action that might > disturb the user can check this variable and choose not to act > when it is non-nil. It is not about "disturbing". If non-essential^W^W do-not-disturb is non-nil, Tramp does not open a remote connection. That's all until now, and that's the reason I have asked for this kind of variable. > The week after next we will study Homeland Security Advisory System > threat levels: `severe', `high', `significant', `general', and `low'. Oh, surprise. I thought there's only the threat level `severe'. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 16:03:00 2010 Received: (at submit) by debbugs.gnu.org; 30 Oct 2010 20:03:01 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCHdj-0007z9-Jh for submit@debbugs.gnu.org; Sat, 30 Oct 2010 16:02:59 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCHdh-0007z2-OE for submit@debbugs.gnu.org; Sat, 30 Oct 2010 16:02:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCHho-0003L4-4Z for submit@debbugs.gnu.org; Sat, 30 Oct 2010 16:07:13 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:49487) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCHho-0003L0-21 for submit@debbugs.gnu.org; Sat, 30 Oct 2010 16:07:12 -0400 Received: from [140.186.70.92] (port=34911 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PCHhm-0005oR-VO for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 16:07:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PCHhl-0003KO-Hg for bug-gnu-emacs@gnu.org; Sat, 30 Oct 2010 16:07:10 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:40424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PCHhk-0003Jk-3Y; Sat, 30 Oct 2010 16:07:08 -0400 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9UK6xnI008043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Oct 2010 20:07:01 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9UBEaCP016741; Sat, 30 Oct 2010 20:06:59 GMT Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 736720701288469145; Sat, 30 Oct 2010 13:05:45 -0700 Received: from dradamslap1 (/10.159.217.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Oct 2010 13:05:45 -0700 From: "Drew Adams" To: "'Michael Albinus'" References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com><7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> <837hh07syw.fsf@gnu.org><82hbg4vc32.fsf@gmail.com> <83zktw5g0o.fsf@gnu.org><6EF41FA484C34DC2AAE23367231A3C84@us.oracle.com> <8739rnlg7h.fsf@gmx.de> Subject: RE: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Sat, 30 Oct 2010 13:05:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8739rnlg7h.fsf@gmx.de> Thread-Index: Act4W28CCGsWimZhSqKMAaHQmqWCFwADnfOQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Spam-Score: -6.3 (------) X-Debbugs-Envelope-To: submit Cc: 'Eli Zaretskii' , 'Andy Moreton' , bug-gnu-emacs@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.3 (------) > > do-not-disturb | no-molestar | ne-pas-deranger | > > nao-perturbe | non-disturbare=20 > > I insist in being informed in German. "Bitte nicht st=F6ren".=20 > Otherwise, I do whatever I want to do. ;-) > > (defvar do-not-disturb nil > > "Non-nil is a sign to avoid disturbing the user. > > Code that performs a relatively unimportant action that might > > disturb the user can check this variable and choose not to act > > when it is non-nil. >=20 > It is not about "disturbing". If non-essential^W^W do-not-disturb is > non-nil, Tramp does not open a remote connection. That's all=20 > until now, and that's the reason I have asked for this kind of = variable. I understand. And in practice, today, objectively, this is used only by = Tramp (bound by Ido and Icomplete, handled by Tramp). But Stefan has been clear that he wants this to be something more = general: not necessarily about Tramp, not necessarily about remote connection, not necessarily about password-prompting, not necessarily about interrupting = the user,... He wants this to be something so general that its intention is recorded = only in terms of "disturbing the user". That's his point, not mine. I just = tried to follow up with a name and description that supports that intention. To reflect what you say and just the current situation, the name would = instead speak about Tramp not accessing remote files, not opening a remote = connection, not prompting for a password, or some such. But that is not Stefan's intention for this variable, AFAICT. Whatever gets done about this bug (probably nothing, if I had to guess), = I would like to see the doc let developers of code involving file names - in = particular, completion of possibly remote file names, know that they can bind this = to non-nil to prevent Tramp from opening a remote connection and possibly = prompting for a password. That's the most important use case, _for now_ at least. I thank you for = letting me know about this var for Icicles. My point in filing the bug was to = have the doc let others who write file-name completion code know also. I also = thought that the var name and description could be made a bit clearer. > > The week after next we will study Homeland Security Advisory System > > threat levels: `severe', `high', `significant', `general',=20 > > and `low'. >=20 > Oh, surprise. I thought there's only the threat level `severe'. ;-) From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 30 22:29:59 2010 Received: (at 7291) by debbugs.gnu.org; 31 Oct 2010 02:29:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCNgF-0004Kf-8q for submit@debbugs.gnu.org; Sat, 30 Oct 2010 22:29:59 -0400 Received: from mail-ww0-f46.google.com ([74.125.82.46]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PCNgD-0004KX-9u for 7291@debbugs.gnu.org; Sat, 30 Oct 2010 22:29:57 -0400 Received: by wwd20 with SMTP id 20so4894185wwd.15 for <7291@debbugs.gnu.org>; Sat, 30 Oct 2010 19:34:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.202 with SMTP id o52mr798549wem.29.1288492452422; Sat, 30 Oct 2010 19:34:12 -0700 (PDT) Received: by 10.216.37.69 with HTTP; Sat, 30 Oct 2010 19:34:12 -0700 (PDT) Date: Sat, 30 Oct 2010 22:34:12 -0400 X-Google-Sender-Auth: wVjqV8Cdh-YKqqZlCyQuk5rTpfE Message-ID: Subject: bug#7291: 24.0.50; `non-essential' is incomprehensible From: MON KEY To: 7291@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: 7291 Cc: Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) >> allow-user-interaction ? > "User interaction" is too general, IMO. Almost as general as the > original name, which is one of the reasons for this bug report. can-do-interactive can-do-allowed ok-to-disturb can-do-disturb can-disturb-user permit-to-tickle-cthulu <- Personal Favorite :) -- /s_P\ From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 14 10:35:44 2011 Received: (at control) by debbugs.gnu.org; 14 Jul 2011 14:35:45 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhN0y-0006cT-0l for submit@debbugs.gnu.org; Thu, 14 Jul 2011 10:35:44 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhN0w-0006cE-KB for control@debbugs.gnu.org; Thu, 14 Jul 2011 10:35:42 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QhN0l-0007w4-7Q for control@debbugs.gnu.org; Thu, 14 Jul 2011 16:35:31 +0200 Date: Thu, 14 Jul 2011 16:35:30 +0200 Message-Id: To: control@debbugs.gnu.org From: Lars Magne Ingebrigtsen Subject: control message for bug #7291 X-MailScanner-ID: 1QhN0l-0007w4-7Q X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311258931.74499@zf+3YV4nTzlqKKG++ew16A X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) tags 7291 notabug close 7291 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 14 10:45:04 2011 Received: (at 7291) by debbugs.gnu.org; 14 Jul 2011 14:45:05 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhNA0-0006uQ-Ob for submit@debbugs.gnu.org; Thu, 14 Jul 2011 10:45:04 -0400 Received: from hermes.netfonds.no ([80.91.224.195]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QhN9y-0006s5-Kz for 7291@debbugs.gnu.org; Thu, 14 Jul 2011 10:45:03 -0400 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=quimbies.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1QhN9j-00086J-Jo; Thu, 14 Jul 2011 16:44:47 +0200 From: Lars Magne Ingebrigtsen To: James Cloos Subject: Re: bug#7291: 24.0.50; `non-essential' is incomprehensible In-Reply-To: (James Cloos's message of "Thu, 28 Oct 2010 13:33:15 -0400") Date: Thu, 14 Jul 2011 16:35:27 +0200 Message-ID: References: <9499566E643B466092A98013C6826011@us.oracle.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) X-Now-Playing: Depeche Mode's _A Question of Lust_: "It Doesn't Matter Two (instrumental)" X-Hashcash: 1:23:110714:7291@debbugs.gnu.org::ddQgbZcqc6fOBGqK:000000000000000000000000000000000000000006fhl X-Hashcash: 1:23:110714:drew.adams@oracle.com::WIHz0ZUWwyx+KSPZ:0000000000000000000000000000000000000000g6tP X-Hashcash: 1:23:110714:cloos@jhcloos.com::hz5Jx4Sko+4G3Lq8:00000000000000000000000000000000000000000000gTql MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1QhN9j-00086J-Jo X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1311259487.78747@zWZlg2N1/SOYe/0i70LWAg X-Spam-Status: No X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 7291 Cc: 7291@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) James Cloos writes: > Seems clear here. I think the rough consensus here is that the doc string is clear enough as it is. Closing the report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From unknown Fri Jun 20 07:17:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 12 Aug 2011 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator