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 17:59:34 -0800 (PST) Message-ID: <2783fdfd-d5d4-4b68-b1d9-27a7cba1efdb@default> References: > <83lfh743j8.fsf@gnu.org>> <53945b2b-cb3f-4823-85e1-ff8676f10161@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="4374"; 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 03:02:53 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 1kdOQO-00010U-6B for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Nov 2020 03:02:52 +0100 Original-Received: from localhost ([::1]:44434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdOQN-0001Jr-2Z for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Nov 2020 21:02:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdOPK-0000s6-Ph for emacs-devel@gnu.org; Thu, 12 Nov 2020 21:01:48 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:52620) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdOPH-0000It-Pm; Thu, 12 Nov 2020 21:01:45 -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 0AD1ruvi070640; Fri, 13 Nov 2020 02:01:38 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=P7qQoTS1DyyElDcOKvpEo8Ad8qVtnHjNLOKeq9zxBhQ=; b=hKc2rFDE1/UggDajbOSjanmoVhXHe/vTqJ467OlYWqycmsnXaD4EGgaD0fC/nOVHCgq1 7KWT8a64m8Xy8dbHxi8JoyeCAjCeXmjbf1aZsqGnt9zzrGF3q6j7TL4HWiqdMCPdoQg+ nXhspTZPPbRVJSU241H4l+fVshvpzw8+78N40PivfkLRpbmTIcUJHtAAnwjawt2SdDri nfvR44FyQTwlVPvjSBXI/pzV/twgGz6m4FK9zdg4e11H3xPTI0uyfHgknJwBWZZ2C8Te 9mWrnq1eiCfoaAg6zZO4EiXb7R9tUPsUrH3jWpiPcqYQGZcUylvODDCTaFrApyKq66Ck 6A== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 34nkhm8ede-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Nov 2020 02:01:38 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0AD1uF6U105589; Fri, 13 Nov 2020 01:59:37 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 34rtkss3rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 13 Nov 2020 01:59:37 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0AD1xZKU016540; Fri, 13 Nov 2020 01:59:36 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 mlxscore=0 phishscore=0 suspectscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130009 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-2011130009 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/12 21:01:41 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, 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:259111 Archived-At: > > And if they don't work then there should be no supporting > > code, and they'd be unrecognized - raise an error if > > referenced in any way. Typically, deprecated/obsolete !=3D > > unsupported. Does Emacs take the point of view that all > > of this is unsupported? If so, remove its code, so using > > raises an error. >=20 > The problem is that, AFAICT, it is not really feasible to have a > one-size-fits-all for how we go about deprecating options. In some > cases it makes sense for them to continue to have effect during the > obsoletion period, but in other cases it does not. >=20 > I for one was bitten by this trying to customize an option > that turned out to simply no longer have any effect. But are you then applying your lesson from that one option to all of these options? Doesn't that contradict your previous paragraph? (And there are likely some non-obsolete options that in some cases have no effect.) But see what I wrote above: if an option no longer works then we should raise an error when it's referenced - it should be desupported. 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. > Should it have just been > removed in this case? Well, it would of course have helped me. But > third-party code that tried to use it would get the signal "Symbol's > value as variable is void" at run-time, instead of the much gentler > byte-compiler warning that it is obsolete. It's either one or the other, no? If it doesn't work then users deserve the runtime error. In that case, what good is a byte-compiler message intended to warn you to move away from using it? If it does work, and we just want you to move away from it, then a warning makes sense. What are we warning about? The fact that it might become desupported at some point. That's the point of a deprecation notice and warnings. > Not showing it in `M-x customize-group' seems like a > good compromise. If it no longer works, yes. But in that case we should raise an error, not issue a compiler warning. If it does still work then I see no reason why we'd remove it from `customize-group'. Especially if `customize-option' still works etc. This makes no sense to me. (Just one opinion.) > > What's not fine, IMO, is to remove it from Customize. If > > something is removed from Customize then it's not the case > > that it's still usable with Customize (or Customize is > > still usable for it). >=20 > The current proposal as discussed in the bug will keep both > `customize-option' and `customize-saved'. So you can still customize > them using customize. See above. I don't see how that helps users.