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#10057: 24.0.91; doc string of `Info-find-file' Date: Wed, 16 Nov 2011 12:04:47 -0800 Message-ID: <7E855B9DA1F942EC92061D42CBA989E9@us.oracle.com> References: <8B7B45455BDC4BFBAC6E24B36D21695F@us.oracle.com><7DCB4AC13F2B4BA19A9BBB34E78086CA@us.oracle.com><87wrb0p2nf.fsf@mail.jurta.org> <871ut7x3ro.fsf@mail.jurta.org> 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 1321473931 21041 80.91.229.12 (16 Nov 2011 20:05:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2011 20:05:31 +0000 (UTC) Cc: 10057@debbugs.gnu.org To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 16 21:05:20 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RQljU-0005Wb-Be for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2011 21:05:20 +0100 Original-Received: from localhost ([::1]:54525 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQljT-0000qe-Pg for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2011 15:05:19 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:44728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQljQ-0000qH-OQ for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 15:05:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQljP-0001on-PV for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 15:05:16 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQljP-0001oj-KY for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 15:05:15 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RQlkA-0004kC-53 for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 15:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Nov 2011 20:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10057 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10057-submit@debbugs.gnu.org id=B10057.132147394718213 (code B ref 10057); Wed, 16 Nov 2011 20:06:02 +0000 Original-Received: (at 10057) by debbugs.gnu.org; 16 Nov 2011 20:05:47 +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 1RQljv-0004ji-6J for submit@debbugs.gnu.org; Wed, 16 Nov 2011 15:05:47 -0500 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQljr-0004jV-B5 for 10057@debbugs.gnu.org; Wed, 16 Nov 2011 15:05:44 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAGK4nQt023115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 20:04:50 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAGK4nPY008090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2011 20:04:49 GMT Original-Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAGK4hih013882; Wed, 16 Nov 2011 14:04:43 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 16 Nov 2011 12:04:40 -0800 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcykluPASBXB2PhxTZKtKEMJG2NfjAAALG1g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: <871ut7x3ro.fsf@mail.jurta.org> X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4EC41762.011C,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 16 Nov 2011 15:06:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54000 Archived-At: > > What part of this problem statement (your "what") is so difficult > > to understand? > > > > >> This says only what a value of `t' means. > > >> It does not say what other non-nil values mean. > > This statement implies that there are other non-nil values that should > be documented. No, it does not imply that, if by that you mean particular non-nil values. But it might have been clearer if I had added "might": "It does not say what other non-nil values might mean." IOW, there is nothing in my statement that implies that there are other non-nil values that act differently from `t'. The point was that non-nil other than t is not addressed. So yes, there are other non-nil values, and yes, something should be said about them. If they are in the same boat as `t', then there is nothing particular to say about any of them - including `t': just say "non-nil". Anyway, you already raised that question for clarification and I answered it: >> > Do you know other possible non-nil values? >> >> No, not I. If all non-nil values are treated the same, then >> the doc should not single out `t'. As it stands now, it says >> "if t, ..." it means ..., which _suggests_ that that is the case >> _only_ if t. >> >> Either it is saying the wrong thing (via such a suggestion of >> "only") or it is incomplete (saying nothing about other non-nil >> values). >> >> If what is really meant is "if non-nil,...", then please just >> say that. > I'm not aware of other non-nil values you are > talking about. Again. You asked that already and I answered it. But "you are talking about" is incorrect - I did not talk about any other particular non-nil values. The point is that there _are_ other non-nil values besides `t', and the doc string does not cover them (but the code handles them, and exactly like `t'). If they are intended (NB _intended_) to act the same as `t', then the doc string should simply say "non-nil", not "t". There is no reason to single out `t' here, any more than 42 or `Juri'. Unless there is a reason - and in that case, it should be passed along to the users. It's about making things clear to readers; nothing more than that. What happens if the value is 42? Readers wonder (I did, for one) and they have the right to know. Without having to look in the code to find out. If you want to say that non-nil and non-t is unpredictable and unsupported, that's fine, and clear. Saying nothing leaves readers wondering. > > In any case, I did say how I would like to see it fixed: > > > > >> Please state clearly and completely what NOERROR means. > > Such unclear statements are of no help until you explain > what do you mean by "clearly". Doesn't really matter what I mean by "clearly". As I said, the "how" is not important. Fix it anyway you like - choose your own meaning of "clearly" and "completely". Come on. Today, non-nil values other than `t' are not described _at all_. So any description of them that is at all accurate would be an improvement in clarity and completeness. You are making a big deal out of nothing. If some other user had reported this bug, saying only "Please change `t' to `non-nil'", would there have been such a clamor? I wonder.