From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#7291: 24.0.50; `non-essential' is incomprehensible Date: Thu, 28 Oct 2010 11:51:31 -0700 Message-ID: <7908A4E9737248F79A9D74B584DAEAC9@us.oracle.com> References: <9499566E643B466092A98013C6826011@us.oracle.com><3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1288293755 14794 80.91.229.12 (28 Oct 2010 19:22:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2010 19:22:35 +0000 (UTC) Cc: 7291@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 28 21:22:33 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PBY2h-0002h6-TT for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 21:22:31 +0200 Original-Received: from localhost ([127.0.0.1]:51382 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBY2G-00038T-9F for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 15:21:16 -0400 Original-Received: from [140.186.70.92] (port=41117 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBXvk-0001eW-9z for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:14:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBXuM-0002Dq-3o for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:13:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBXuM-0002Dk-1N for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:13:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PBXX4-0002zx-E2; Thu, 28 Oct 2010 14:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Oct 2010 18:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7291 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7291-submit@debbugs.gnu.org id=B7291.128829170311517 (code B ref 7291); Thu, 28 Oct 2010 18:49:02 +0000 Original-Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 18:48:23 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PBXWR-0002zi-6C for submit@debbugs.gnu.org; Thu, 28 Oct 2010 14:48:23 -0400 Original-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 Original-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 Original-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 Original-Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 727672871288291892; Thu, 28 Oct 2010 11:51:32 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 11:51:31 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2w43OxKl6SzgPQBenJIvhuy8mLAAAocgA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 28 Oct 2010 14:49:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41203 Archived-At: > 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).