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 09:22:43 -0700 Message-ID: <3457CB74869B424BB0DB5A41C034AED7@us.oracle.com> References: <9499566E643B466092A98013C6826011@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 1288284758 2776 80.91.229.12 (28 Oct 2010 16:52:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2010 16:52:38 +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 18:52:36 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 1PBViL-00005s-1J for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 18:52:33 +0200 Original-Received: from localhost ([127.0.0.1]:57537 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBVZX-0001MR-N4 for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 12:43:27 -0400 Original-Received: from [140.186.70.92] (port=41763 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBVZD-0001HD-1b for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 12:43:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBVZB-0005mB-OR for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 12:43:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBVZB-0005m5-La for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 12:43:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PBVBu-0001xl-CA; Thu, 28 Oct 2010 12:19: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 16:19: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.12882827367538 (code B ref 7291); Thu, 28 Oct 2010 16:19:02 +0000 Original-Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 16:18:56 +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 1PBVBn-0001xX-9q for submit@debbugs.gnu.org; Thu, 28 Oct 2010 12:18:55 -0400 Original-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 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 o9SGN0c1008628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 16:23:01 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 o9SDuLCW004727; Thu, 28 Oct 2010 16:22:57 GMT Original-Received: from abhmt015.oracle.com by acsmt354.oracle.com with ESMTP id 727168041288282965; Thu, 28 Oct 2010 09:22:45 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 09:22:44 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2OmjhbQBnvrDuRwOHcEROUzZDygAfjFjQ 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 12:19: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:41197 Archived-At: > > 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?