Re: Delete variables obsolete since Emacs 23

[Jeff Norden]

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’m still using software that I wrote for Emacs back in 1995. ...
  Every once in a while it might require a minor tweak, but it’s really
  quite rare. I’m not aware of anything I’ve ever written for Emacs (and
  I’ve 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’s 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 optional
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 snippet
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 people
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 nothing
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 that
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 involves
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 simply
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 who
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.  If 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 unwavering
commitment to principles rather than self promotion.

Thanks,
-Jeff