From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jeff Norden Newsgroups: gmane.emacs.devel Subject: Re: Delete variables obsolete since Emacs 23 Date: Tue, 18 Aug 2020 16:30:55 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com, ghe@sdf.org, eliz@gnu.org, drew.adams@oracle.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 18 23:32:44 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 1k89Dn-0003BB-Rq for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Aug 2020 23:32:43 +0200 Original-Received: from localhost ([::1]:35272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k89Dm-0003k6-P3 for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Aug 2020 17:32:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k89CC-0002Zs-TN for emacs-devel@gnu.org; Tue, 18 Aug 2020 17:31:05 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:42728) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k89CA-0004eR-B3 for emacs-devel@gnu.org; Tue, 18 Aug 2020 17:31:04 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id CDE373000051; Tue, 18 Aug 2020 16:30:57 -0500 (CDT) Original-Received: from norden.tntech.edu ([149.149.102.4] helo=norden.math.tntech.edu) by math.tntech.edu with esmtp (Exim 4.92) (envelope-from ) id 1k89C3-0006Sk-E7; Tue, 18 Aug 2020 16:30:55 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 5DE332572B73; Tue, 18 Aug 2020 16:30:55 -0500 (CDT) In-Reply-To: (message from Stefan Monnier on Tue, 18 Aug 2020 15:27:00 -0400) X-SA-Spam-Score: 0.0 X-SA-Spam-Report: Spam detection software, running on the system "math.tntech.edu", has NOT identified this incoming email as spam. If you have any questions, contact @@CONTACT_ADDRESS@@ pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) Received-SPF: pass client-ip=149.149.2.87; envelope-from=jnorden@tntech.edu; helo=mta.tntech.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/18 17:30:57 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:253978 Archived-At: I said: >> The elisp manual says: >> You can mark a named function as "obsolete", meaning that it may be >> removed at some point in the future. This causes Emacs ... >> The phrase "may be removed" seems a bit vague. Would "will be removed" or >> "will probably be removed" be more accurate? To which Eli Zaretskii replied: > No, it won't. Primarily because we don't really know whether we will > remove it, let alone when. It depends on too many factors that we > cannot predict. But then Stefan Monnier wrote: > If there's no intention to remove it in the future, then we don't > declare it obsolete. I really like the use of 'obsolete' instead of 'deprecate'. Merriam-Webster gives a two-part definition: Definition of obsolete: 1 a: no longer in use or no longer useful b: of a kind or style no longer current : OLD-FASHIONED I personally think that there is a case for keeping a limited number of obsolete functions/variables long term, for backward compatibility. You can apply definition (b) to these, although it's not a perfect fit, since obsolete functions shouldn't be used in new code. Windows still supports 8.3 file names (a horrible example, since they never should have been created in the first place). My pickup truck still uses a carburetor, which was certainly made obsolete by fuel injection, but still works fine for me. Of course, obsolete features won't be maintained, updated, etc. (My local parts stores no longer stock an air filter that fits my truck.) But, if a function or variable fits (a), and is really no longer used or useful, then it only make sense to remove it. It may not be possible or practical to precisely label each obsolete emacs item with a category. But, it would be good to be clear as to whether or not (make-obsolete) should be regarded as including both possible cases. Thanks, -Jeff