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:53:04 -0700 Message-ID: <574D27E117CE4DC18C451B99A12A456E@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 1288294883 19878 80.91.229.12 (28 Oct 2010 19:41:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2010 19:41:23 +0000 (UTC) Cc: 7291@debbugs.gnu.org To: "'James Cloos'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 28 21:41:21 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 1PBYLe-0004oY-JF for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 21:41:18 +0200 Original-Received: from localhost ([127.0.0.1]:38268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBXyX-0002PS-Pe for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Oct 2010 15:17:25 -0400 Original-Received: from [140.186.70.92] (port=60592 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBXvi-00020U-HL for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:17:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBXuN-0002EP-MQ for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:13:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42608) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBXuN-0002EL-Jj for bug-gnu-emacs@gnu.org; Thu, 28 Oct 2010 15:13:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PBXYz-00030u-PB; Thu, 28 Oct 2010 14:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Oct 2010 18:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7291 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7291-submit@debbugs.gnu.org id=B7291.128829182911573 (code B ref 7291); Thu, 28 Oct 2010 18:51:01 +0000 Original-Received: (at 7291) by debbugs.gnu.org; 28 Oct 2010 18:50:29 +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 1PBXYT-00030c-JO for submit@debbugs.gnu.org; Thu, 28 Oct 2010 14:50:29 -0400 Original-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 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9SIsYTI031056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 18:54:36 GMT Original-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 Original-Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 727677281288291984; Thu, 28 Oct 2010 11:53:04 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Oct 2010 11:53:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Act2xuUhCVKxak7KQAujNW73FMZRMgAB8IBQ 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:51:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41204 Archived-At: > 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.