From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: On obsoleting defcustoms Date: Thu, 12 Nov 2020 21:18:02 -0800 (PST) Message-ID: References: > <83lfh743j8.fsf@gnu.org>> <53945b2b-cb3f-4823-85e1-ff8676f10161@default> <2783fdfd-d5d4-4b68-b1d9-27a7cba1efdb@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19563"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 13 06:21:34 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kdRWg-0004zi-2p for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 06:21:34 +0100 Original-Received: from localhost ([::1]:54150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdRWf-0002tK-3I for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 00:21:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdRUh-0001NW-Vr for emacs-devel@gnu.org; Fri, 13 Nov 2020 00:19:32 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:55798) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdRUZ-0006Co-Tu; Fri, 13 Nov 2020 00:19:31 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0AD5GmLa109049; Fri, 13 Nov 2020 05:19:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=KrSeMxZ4tRlKFeeoeAbVhPBhJUqvl1ho08XXE+oA/Sk=; b=qGVfcSRUub6A1ZJ7xVlMWErZWL2NUbZFXnS/GeXpH2/nDlRw0JfAbzJMPBjT5g/d0eqh ipL38gfXKTkJKuUfwIqZHDMm0trXmXIFyGk7Oa3OEkXPH3wJWv4m7MBLWy2WPtteRfND 7915zhjSt91uZZ6ep5gTHtxPxTP9hz6G8+AN106xbw5N4f78QFON6b8TXPS3JEszAiAE L/o1pdAXhEvWPhO+1M+edwnX3fkhCj8Q87roz0MYxCLyp35fh13KelaccTJRNEcNyYM7 fRI3wb6GL+AX9sNY5503COQUuAS/7Xg4PChrhQ1P6xz9kGmWVavYTlFaIcfAj+W3vi0R Fw== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 34nkhm8s9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Nov 2020 05:19:19 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0AD5FEEn187069; Fri, 13 Nov 2020 05:19:18 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 34rt5789yk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Nov 2020 05:19:18 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0AD5Ii2p015780; Fri, 13 Nov 2020 05:19:03 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5071.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9803 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130030 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9803 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 mlxlogscore=999 lowpriorityscore=0 spamscore=0 malwarescore=0 adultscore=0 clxscore=1015 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130030 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/13 00:19:20 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:259117 Archived-At: > > Obsolete should mean still works and is still supported, > > but is no longer being actively developed. Desupport > > means the code supporting it is gone and we raise an > > error instead. >=20 > Is "desupported" defined in Emacs development? Searching online, I > was only able to find that word used in reference to Oracle Database. No idea, and I don't care what terms we use. There's often (usually?) a distinction between these 3 levels of support (these are descriptions, not names): 1. Actively supported and developed. If you file a bug or suggest an enhancement it will likely be looked at, at some point. 2. Not actively supported and developed, but still in the code, still working (but support for fixing bugs may not be there or may be reduced), and maybe even still documented to some extent. 3. Not supported at all. Doesn't work. Not in the code. Not documented (except old doc out on the wild web). Each is a gray area, and different organizations have different policies and draw lines in different places. In principle, at least, #2 is transitional, or at least users are told that the feature _might_ at some point in the future change to status #3. Things may continue to work, but you're recommended to use the preferred alternative/replacement (if any). Since in #3 the feature is absent - doesn't work, you generally get an error if you try somehow to use it. The transition from #1 to #2 is sometimes called deprecation, and in #2 the feature is sometimes called obsolete or deprecated. In #3, the feature no longer exists, and it's sometimes said to be unsupported. The transition from #2 to #3 is sometimes called desupport. There's no obligation to move from #2 to #3, BTW. At least in business, where there can be particularly important customers, some features may be deprecated (move to #2) with no intention or expectation that they will ever really be moved to #3. Users might not be told that, however, since the idea is to get them to abandon the deprecated feature. But some considerations can come into play that make it impossible or undesirable to ever really remove a feature altogether. > I think we talk about "making obsolete" and "removing" a > variable/function/face, and their definitions are: >=20 > a) Obsolete means the byte-compiler warns about their use > b) Removed means it no longer exists OK, that sounds to me like #2 and #3, respectively. > Note that we have many obsolete variables that are declared to be "no > longer used", that is, they have no effect. You are free to argue > against the status quo, of course, but that is what we have. Maybe so. We also have lots of stuff that's called obsolete and that still works - thank goodness, IMO! It may no longer be used much by the distributed Emacs code, but it may well still be used by Emacs users. And even if an obsolete feature is no longer used, that doesn't necessarily mean that it would have no effect if someone did use it. If something really has no effect then there's no reason to warn about using it. There may be, and often is, a reason to retain code that just raises an error for something that's unsupported (which isn't quite the same thing as having no effect, but it's at least not having the expected effect). > > If it doesn't work then users deserve the runtime error. >=20 > I don't think raising a run-time error is wise just because we decided > that a variable should have no effect. That would mean gratuitously > breaking code that might otherwise be working. It is better to allow > for a grace period by raising an obsoletion warning. It sounds like we maybe have different understandings of "have no effect". A variable that has no effect isn't a variable. It's not even an unbound variable. But yes, if you want to remove a variable from having its formerly expected effect, then unbind it so users get an unbound error. A variable that continues to have its expected effect, or at least some semblance of that, and that you're warned/recommended not to continue to use, is just obsolete - it's not yet missing/removed. > > I don't see how that helps users. >=20 > The point IMO is that advertising features that we are planning to > remove does not help users. On the contrary, we should recommend > moving away from obsolete features. Yes, a warning is appropriate in that case. Removing the feature is something else. You're keeping `customize-option' for such a variable, but you're removing it from `customize-group'. To me that's not a great approach, but it's not a big deal. And I wouldn't call keeping either of those customize possibilities "advertising". If you remove the possibility of using an option as an option, i.e., remove its usual customization, then you've removed more than advertising. OK, you've only removed some, not all, possibilities of customizing - just `customize-group', I guess. You did that to reduce noise in the group UI. That's understandable. I suggested instead keeping the obsolete options in the group but showing warnings there for them. Not a big deal anyway. These things aren't hard & fast rules. They're judgment calls. And opinions can differ.