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: Wed, 19 Aug 2020 19:33:43 -0500 Message-ID: References: <83364iekfe.fsf@gnu.org> 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="6077"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca, ghe@sdf.org, larsi@gnus.org, drew.adams@oracle.com, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 20 02:43:03 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 1k8YfX-0001Pp-Hj for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Aug 2020 02:43:03 +0200 Original-Received: from localhost ([::1]:56566 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8YfW-0000v5-H3 for ged-emacs-devel@m.gmane-mx.org; Wed, 19 Aug 2020 20:43:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8YWd-0001JI-Uk for emacs-devel@gnu.org; Wed, 19 Aug 2020 20:33:51 -0400 Original-Received: from mta.tntech.edu ([149.149.2.87]:51784) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8YWb-0004a0-8i for emacs-devel@gnu.org; Wed, 19 Aug 2020 20:33:51 -0400 Original-Received: from math.tntech.edu (unknown [149.149.102.6]) by mta.tntech.edu (Postfix) with ESMTPS id 9FEC53000055; Wed, 19 Aug 2020 19:33:46 -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 1k8YWW-0001BM-21; Wed, 19 Aug 2020 19:33:44 -0500 Original-Received: by norden.math.tntech.edu (Postfix, from userid 742) id F21E02572B73; Wed, 19 Aug 2020 19:33:43 -0500 (CDT) In-Reply-To: <83364iekfe.fsf@gnu.org> (message from Eli Zaretskii on Wed, 19 Aug 2020 18:15:33 +0300) 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/19 20:33:46 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, URIBL_BLOCKED=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:254034 Archived-At: Stefan Monnier wrote: > IMNSHO it doesn't: if we don't intend to remove it ever, then we don't > declare it obsolete. > > Of course, declaring it obsolete doesn't guarantee that we will remove > it: it's just a declaration of intention. Eli Zaretskii wrote: > You seem to be under the impression that we have difficulty removing > obsolete features when we decide it's time for that. But the reality > is we do remove such obsolete features. It's the decision to do so > that's difficult, not the execution of the removal once we do decide. This makes it clear, I think. Perhaps the elisp manual could say something like: When the Emacs developers mark a function or variable as obsolete, this signals the intent to remove it at some point in the future. You should refrain from using it in new code, and should work towards removing it from existing code that you plan to maintain for the long term. But maybe that is not really necessary. --- Lars Ingebrigtsen wrote: > ...this is a pretty entertaining read: > https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy= -is-killing-you-ee7525dc05dc Thanks for this link, which I really enjoyed. In addition to characterizing Emacs as "a sort of hybrid between Windows Notepad, a monolithic-kernel operating system, and the International Space Station," Yegge says: I=E2=80=99m still using software that I wrote for Emacs back in 1995. ... Every once in a while it might require a minor tweak, but it=E2=80=99s re= ally quite rare. I=E2=80=99m not aware of anything I=E2=80=99ve ever written f= or Emacs (and I=E2=80=99ve written a lot) that was ever forced into re-architecture. ... when they make an API obsolete, they are basically saying: "You really shouldn't use this approach, because even though it works, it suffers from various deficiencies which we enumerate here. But in the end it=E2=80=99s= your call." Whereas in the Google world, deprecation means: "We are breaking our commitments to you." It really does. --- As far as interactive-p is concerned, I grepped thru my personal stuff and found exactly one instance of interactive-p, which dates to April 1993. It is used to make a function behave differently on the rare times that I invoke it via M-x. I changed the interactive spec and introduced an option= al arg. I agree this is a better solution - but I would also argue that this = use of interactive-p was harmless, since I'm the only person who uses this snip= pet of code, and interactive-p did a perfectly good job for my use case. I can see an argument for removing interactive-p as a way to encourage peop= le to carefully examine where it was used, and replace it with something better when possible. But the docstrings and elisp manual already do this, and it isn't clear to me that removing the function would accomplish much more. There is nothing gained by replacing (interactive-p) with (called-interactively 'interactive) where it is really necessary. And noth= ing can prevent someone from just blindly doing a search-and-replace if they choose to. On the other hand, if I hadn't been reading this list this summer, it would have been a "gentle annoyance" when my old snippet of code failed to run. Or, as Yegge put it, one of the rare times that it required a minor tweak. Maybe a stronger docstring could be used instead of deletion. Perhaps: (defun interactive-p () "Equivalent to (called-interactively-p 'interactive), for backward compatibility. See the Info node `(elisp)Distinguish Interactive' for the limited situations in which this is appropriate, and suggestions for more robust alternatives." (called-interactively-p 'interactive)) But, the design of Emacs makes this a very minor issue, especially compared to other software I use. (No matter how many times I set it, tex-live seems find a new way to change my default paper size back to A4.) --- Thinking more broadly, it seems to me that the issue is more than just backward compatibility. It's about having respect for the people who will = be using your software. I think of Arethra Franklin singing R-E-S-P-E-C-T in = her rendition of the classic Otis Redding song. More than any other software t= hat I know of, Emacs embodies the concept of "user-respect." One thing that's clear to me from reading this list recently is that *every* decision involv= es a careful consideration of the effects it will have on the people who use Emacs. That a lack of user-respect is otherwise ubiquitous today is evidenced simp= ly by the number of times each day that you mutter "WTF, why did that just happen?" as you browse the web, interact with software, etc, etc. https://commadot.com/wtf-per-minute/ In commercial settings, this is likely due to the (perhaps misguided) perception that decisions are in their financial interest, and the people w= ho use their products are willing to just "live with it." In other circles, I think that the ego and hubris of developers is, in large part, to blame. I= f I had to guess, I'd say that the respect embodied by Emacs is due, in no small part, to Richard Stallman: his apparent humility and his absolutely unwaver= ing commitment to principles rather than self promotion. Thanks, -Jeff