From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: `thunk-let'? Date: Wed, 8 Nov 2017 15:06:02 -0800 (PST) Message-ID: References: <87infp9z6j.fsf@web.de> <87zi90eehg.fsf@web.de> <87o9ocd6s4.fsf@web.de> <83zi7wr6jc.fsf@gnu.org> <87k1z0csxa.fsf_-_@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1510184411 26763 195.159.176.226 (8 Nov 2017 23:40:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Nov 2017 23:40:11 +0000 (UTC) Cc: nicolas@petton.fr, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Michael Heerdegen , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 09 00:40:05 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eCZwy-0006j5-Uv for ged-emacs-devel@m.gmane.org; Thu, 09 Nov 2017 00:40:05 +0100 Original-Received: from localhost ([::1]:34481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCZx6-00042z-Ap for ged-emacs-devel@m.gmane.org; Wed, 08 Nov 2017 18:40:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eCZQD-0003Zg-4D for emacs-devel@gnu.org; Wed, 08 Nov 2017 18:06:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eCZQC-0004ff-5a for emacs-devel@gnu.org; Wed, 08 Nov 2017 18:06:13 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:46693) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eCZQ8-0004em-DI; Wed, 08 Nov 2017 18:06:08 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA8N6651000814 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Nov 2017 23:06:06 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA8N65U9016532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 8 Nov 2017 23:06:06 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA8N63CJ017894; Wed, 8 Nov 2017 23:06:03 GMT In-Reply-To: <87k1z0csxa.fsf_-_@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4600.0 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:219989 Archived-At: > Well, it's in subr-x because I'm not sure that it is yet a good idea to > "advertize it so loudly" as Stefan uses to say. Nothing in subr-x is > described in the manual. This is not a good approach, IMHO. Whether we should have a library that is for "half-baked" stuff is debatable. But even if it is decided to do that (why?), I don't think it makes sense to decide whether something gets documented in the manuals based on how well baked we think it is. That's a bad criterion to use (IMHO). And it invites things to fall through the cracks and not be documented even after they get improved. The usual criteria for deciding whether something gets documented in a manual should apply to half-baked features also. We should WANT users to try half-baked stuff that we deliver. That's how it gets improved. Not advertizing something just because it is still iffy is not advisable. An exception could exist for something that we think might prove dangerous in some way (e.g. possible data loss). But probably something like that should not be delivered at all - it should just continue to be tested and improved "internally" until it is not problematic. If something is TOO iffy then just don't deliver it. Don't use _doc_ as way of "hiding" something that is unsure. My "vote" is to move the stuff in subr.el to where it belongs, thing by thing, place by place, and to document any of it that we would normally document, with no concern about how well baked we might think it is. > If we are sure that we want to document this right now > in the manual... There should be no "right now" based on how finished something is. If we really feel that something is not ready for release then it should just be pulled from the release. If something is distributed then it should be supported normally. Just one opinion.