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: Mon, 17 Aug 2020 20:55:56 -0500 Message-ID: References: <38b4c392-0a02-4505-87df-74d29e872ee7@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36512"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, stefankangas@gmail.com, rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 18 03:56:52 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 1k7qrs-0009Hc-Oq for ged-emacs-devel@m.gmane-mx.org; Tue, 18 Aug 2020 03:56:52 +0200 Original-Received: from localhost ([::1]:47736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7qrr-00043l-Hm for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 21:56:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7qr9-0003dN-Kl for emacs-devel@gnu.org; Mon, 17 Aug 2020 21:56:07 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:50685) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7qr7-0003Xg-91 for emacs-devel@gnu.org; Mon, 17 Aug 2020 21:56:07 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id 0CC7A3000AF8; Mon, 17 Aug 2020 20:56:03 -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 1k7qqy-0004St-DQ; Mon, 17 Aug 2020 20:56:00 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id 537A32572B73; Mon, 17 Aug 2020 20:55:56 -0500 (CDT) In-Reply-To: <38b4c392-0a02-4505-87df-74d29e872ee7@default> (message from Drew Adams on Mon, 17 Aug 2020 07:20:57 -0700 (PDT)) 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/17 21:56:03 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:253918 Archived-At: Drew Adams wrote: > My only request is to not remove `interactive-p'. > My request is to please leave it "obsolete". 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 to warn that the function is obsolete whenever it byte-compiles code containing that function, and whenever it displays the documentation for that function. In all other respects, an obsolete function behaves like any other function. The phrase "may be removed" seems a bit vague. Would "will be removed" or "will probably be removed" be more accurate? If so, perhaps it would help for obsolete functions and variables to also include something like a 'target-expiration-date', which could be a release number rather than an actual date. A target-expiration of "31.1" would mean that the current intent is that the function/variable will no longer exist when version 31.1 is released. The chromium project does something similar for its experimental "flags" that can be used to customize the user interface. >From where I sit, it seems plausible that someone might view interactive-p as just an obsolete way of writing (called-interactively-p 'interactive), which exists for backward compatibility, and would be available long term. It seems that the last part is a mis-interpretation of the intent of marking it as obsolete. The fact that emacs maintains backward compatibility so well is one of the features that I appreciate the most. But, in this case, the fact that interactive-p has been obsolete for so long may give the impression that it would continue to be available. I can see arguments on both sides of the coin for why interactive-p should or should not continue to exist. If the underlying fact is that virtually all functions marked as obsolete will eventually be removed, then this should be made clear (or more clear than it currently seems to be). Then the issue of whether or not something should be marked as obsolete would have a better focus. Also, it might be worthwhile for the elisp manual to mention one other difference that obsolete functions have. When an interactive command is obsolete, it no longer appears as a possible completion when you press [tab] while entering a command-name after M-x. Regards, -Jeff