[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Delete variables obsolete since Emacs 23

From: Jeff Norden
Subject: Re: Delete variables obsolete since Emacs 23
Date: Tue, 18 Aug 2020 16:30:55 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]