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: Tue, 15 Nov 2011 21:24:23 -0800 Message-ID: <5C41898136234BBFA995CBC4D05B7108@us.oracle.com> References: <8B7B45455BDC4BFBAC6E24B36D21695F@us.oracle.com><7DCB4AC13F2B4BA19A9BBB34E78086CA@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 1321426771 24303 80.91.229.12 (16 Nov 2011 06:59:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 16 Nov 2011 06:59:31 +0000 (UTC) Cc: 10057@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 16 07:59:27 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 1RQZSu-00067p-BU for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2011 07:59:24 +0100 Original-Received: from localhost ([::1]:38120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQZSt-0000Ni-Ta for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Nov 2011 01:59:23 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:55939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQZSr-0000Nd-Cy for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 01:59:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQZSp-0001MC-SG for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 01:59:21 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQZSp-0001M8-Mm for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 01:59:19 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RQZTW-0000Gy-DH for bug-gnu-emacs@gnu.org; Wed, 16 Nov 2011 02:00: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 07:00: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.1321426787994 (code B ref 10057); Wed, 16 Nov 2011 07:00:02 +0000 Original-Received: (at 10057) by debbugs.gnu.org; 16 Nov 2011 06:59: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 1RQZTH-0000Fz-CN for submit@debbugs.gnu.org; Wed, 16 Nov 2011 01:59:47 -0500 Original-Received: from rcsinet14.oracle.com ([148.87.113.126]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQZTE-0000Fm-0Y for 10057@debbugs.gnu.org; Wed, 16 Nov 2011 01:59:45 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet14.oracle.com (Switch-3.4.4/Switch-3.4.1) with ESMTP id pAG5nZ5w015758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 05:49:35 GMT Original-Received: from ucsinet21.oracle.com ([156.151.31.93]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAG5iAjb005160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 05:48:55 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAG5OUq0001366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2011 05:25:05 GMT Original-Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAG5OPHB007362; Tue, 15 Nov 2011 23:24:25 -0600 Original-Received: from dradamslap1 (/10.159.58.234) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Nov 2011 21:24:25 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcykF2+SNqCV5FK2Tti1aYbJJEuiKAAAB1iw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: [156.151.31.93] X-CT-RefId: str=0001.0A090204.4EC34EEF.002D,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 02:00: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:53975 Archived-At: > > I've sent plenty of patches, throughout "all these years", > > as you know. > > No, I do not think you've sent plenty of them. Especially not > docstring patches. I've sent as many patches as I've cared to send and had time to send. If you do not consider it enough, that's your right. If more had actually been applied I might have taken the time to send more - dunno. Like yours, my contribution to Emacs is voluntary. > > If you need a patch to change `t' to `non-nil' then there > > is a problem. > > You've overlooked the "and even install them yourself" part. I do not try to install Emacs code, as you know. That's my choice. I report bugs as a user, and I offer suggestions as a user. You are free to ignore both, as you know and sometimes do. > > But it's not the lack of a patch that prevents you from making this > > doc change, obviously. You do not _want_ to make it. > > The docstring you quoted has a clear meaning of "undocumented behavior > for non-nil and non-t values". I do not know whether that was the > intention of the original author Oh? You don't know the intention? I thought that was precisely your point: The intention is clear to readers. I thought your point was that missing info is necessarily intentionally missing, and readers should know that - no need to question it. And that lack signifies no promises from Emacs Dev: unsupported, unpredictable behavior, to foster future compatibility. That's your "general rule" below, which you say applies to all software. Readers are supposed to know this, no? They are not supposed, like me, to wonder or question what is meant by this or that ambiguous or missing info. They are supposed to assume that it is undocumented by design - as in all software you know of. By your rule, you, like other readers, should be able to conclude that this apparent "oubli" was intentional. That was your claim, no? The fact that the info is missing indicates clearly to readers "you're on your own", not that somebody might have made a boo-boo when writing the doc string. I just pointed out the missing info, raising the question. I really did not know what it meant, and I thought that other users too might like to know. I know what the _code_ does: it treats all non-nil values the same. But that does not imply that that's what you want to tell users, hence the question. Your answer was: if it's missing it should be missing - Circulez, il n'y a rien a voir! So be it. > and do not care to figure it out, Yes, well, that's the point, isn't it? And that was the point of my bug report: to raise the question it turns out you don't care to figure out. It's not the "intention of the original author" that counts at this point. It's your intention that counts - what do you want here? I didn't pose it in question form, admittedly. I suggested that whatever the intention (your call), it be made clear to users. But since it's your call, every bug report is in effect a question to you, "Do you want to fix this problem I noticed?" Yes/not-a-bug/wishlist/won't-fix... Users question/propose; you answer/dispose. > so no I don't want to install such a patch. > > > You apparently want a non-nil, non-t value to implicitly be > > considered unpredictable and unsupported ("you're on your > > own"), for the benefit of "future compatibility", and you > > apparently do not want to tell users that explicitly. So be it. > > Saying this explicitly everywhere we rely on it would be silly. > It's a general rule that applies to all software I know. But you just claimed that you don't even know if this is a place where you want to rely on it - you said that you don't know the intention here. Either you do or you don't. Either this is a place to rely on your general rule or it isn't. You seem to be saying two contradictory things: 1) If info is missing then it's intentional - don't bother to report it. 2) You don't know, in this case, whether it is intentional or not. (So how would a reader know?) Apparently, we should not bother to point out when parameters to functions etc. are undefined/undescribed. We should just assume that the person who wrote the doc left out such info intentionally, relying on the "general rule" to indicate that "you're on your own" for anything that is missing or unclear. That's one approach, I guess. Your call.