Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Lloyd Zusman]

I'm a very long-term GNU emacs user: since the 1980's.

I have been using numerous elisp packages, lots of which date
back many years, and a few of my own elisp modules go all the
way back to the 1980's.

I have been using emacs-27.2 for a few years, and now I decided
to upgrade again. However, when going to emacs-28.2, I hit an
issue with the following emacs enhancement (this comes from the
emacs change log):

> 2021-01-03  Stefan Monnier  <monnier@iro.umontreal.ca>
>
>        * lisp/emacs-lisp/byte-run.el (make-obsolete): Make `when` mandatory
>
>        (define-obsolete-function-alias, make-obsolete-variable)
>        (define-obsolete-variable-alias): Adjust similarly.

Because of `when` becoming mandatory, I now get literally hundreds
of messages which look like this when starting up emacs-28.2 ...

> Warning (comp): /path/to/some-elisp-module.el: Error: Wrong number of arguments make-obsolete-variable

I know that I can get rid of these messages by upgrading each and
every one of my installed emacs packages. However, I have several
dozens of these packages, and some are old, no-longer-maintained
modules. It would take me a huge amount of time to replace the
packages that are upgradable and to manually go into all of the
no-longer-maintained packages and change the calling sequence of
`make-obsolete` and the others.

If the `when` parameter was not made mandatory in `make-obsolete`
and its cousins, I would not have to do this huge amount of work
to upgrade emacs.

The `make-obsolete` family of functions are meant to help during
upgrading. However, changing the mandatory/non-mandatory parameter
semantics of those functions is actually an *impediment* to
upgrading.

Is there any existing fix for this problem short of the massive
amount of work needed for me to upgrade and fix all my existing
emacs packages?

I'm thinking of doing something like the following. Put code like
this at the top of my $HOME/.emacs file:

> (if (not (fboundp 'orig-make-obsolete))
>     (fset 'orig-make-obsolete
>           (symbol-function 'make-obsolete)))
> (fmakunbound 'make-obsolete)
> (unintern 'make-obsolete)
> (defun make-obsolete (obsolete-name current-name &optional when-var)
>   (when when-var
>       (orig-make-obsolete obsolete-name current-name when-var)))

... or something like that.

Is this kind of workaround my only hope for avoiding the huge amount
of work necessary to upgrade and fix the code in all of my existing
emacs packages?

... and what do you folks think about the possibility of making the
`when` parameter optional again?

Thank you in advance for any thoughts and suggestions.

-- 
  Lloyd Zusman
  hippoman@potamuses.net
  God bless you.

     .---------, 0__0
    /           (  oo'---,
   /                    oo\
  ,\                      |
  | \                ,=__/
     \              /
     /  /------|  /|
     |__|-'    |__|'

Re: Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Platon Pronko]

On 2023-04-23 21:56, Lloyd Zusman wrote:
> I'm a very long-term GNU emacs user: since the 1980's.
> 
> I have been using numerous elisp packages, lots of which date
> back many years, and a few of my own elisp modules go all the
> way back to the 1980's.
> 
> I have been using emacs-27.2 for a few years, and now I decided
> to upgrade again. However, when going to emacs-28.2, I hit an
> issue with the following emacs enhancement (this comes from the
> emacs change log):
> 
>> 2021-01-03  Stefan Monnier  <monnier@iro.umontreal.ca>
>>
>>        * lisp/emacs-lisp/byte-run.el (make-obsolete): Make `when` mandatory
>>
>>        (define-obsolete-function-alias, make-obsolete-variable)
>>        (define-obsolete-variable-alias): Adjust similarly.
> 
> Because of `when` becoming mandatory, I now get literally hundreds
> of messages which look like this when starting up emacs-28.2 ...
> 
>> Warning (comp): /path/to/some-elisp-module.el: Error: Wrong number of arguments make-obsolete-variable
> 
> I know that I can get rid of these messages by upgrading each and
> every one of my installed emacs packages. However, I have several
> dozens of these packages, and some are old, no-longer-maintained
> modules. It would take me a huge amount of time to replace the
> packages that are upgradable and to manually go into all of the
> no-longer-maintained packages and change the calling sequence of
> `make-obsolete` and the others.
> 
> If the `when` parameter was not made mandatory in `make-obsolete`
> and its cousins, I would not have to do this huge amount of work
> to upgrade emacs.

The commit message for the change states that usages without `when` were marked obsolete
in version 23.1, which was released in 2009 (14 years ago).

It seems you have dozens of packages that haven't been updated for 14+ years.

While some may argue the "security" aspect, I won't,
because I don't fully agree that everyone needs
  to sacrifice everything for imaginary "security."
Old, tried, and tested software can be great.

However, I question the wisdom of upgrading one part of the system
without upgrading everything else. If you're okay with running such ancient packages,
maybe you don't need to upgrade Emacs?
Even the 23.1 release should compile and run fine today.


In general, there are two approaches to upgrades:

1. Gradually and in sync update everything (e.g., rolling releases like Arch Linux are a great example).
    This approach spreads the pain of breakage evenly over time, and you get to enjoy the benefits of fresh software.

2. Fix everything at a single point in time, and keep it that way for a long time.
    This brings the benefit of stability and everything working exactly the same at all times.
    However, at some point, you might need to upgrade, and then you'll have to endure the pain
    of upgrading everything at once, with many things breaking down and needing a complete overhaul.

I don't think that anything in between these approaches really works –
you'll get downsides of both approaches without much benefit.


> The `make-obsolete` family of functions are meant to help during
> upgrading. However, changing the mandatory/non-mandatory parameter
> semantics of those functions is actually an *impediment* to
> upgrading.
> 
> Is there any existing fix for this problem short of the massive
> amount of work needed for me to upgrade and fix all my existing
> emacs packages?

Perhaps contributing back to the community by fixing the packages might be the best way forward?
This task involves relatively straightforward and easy changes, something that can be done in several hours at most.

> I'm thinking of doing something like the following. Put code like
> this at the top of my $HOME/.emacs file:
> 
>> (if (not (fboundp 'orig-make-obsolete))
>>     (fset 'orig-make-obsolete
>>           (symbol-function 'make-obsolete)))
>> (fmakunbound 'make-obsolete)
>> (unintern 'make-obsolete)
>> (defun make-obsolete (obsolete-name current-name &optional when-var)
>>   (when when-var
>>       (orig-make-obsolete obsolete-name current-name when-var)))
> 
> ... or something like that.
> 
> Is this kind of workaround my only hope for avoiding the huge amount
> of work necessary to upgrade and fix the code in all of my existing
> emacs packages?

This workaround (or something similar) should work. However, consider other deprecations,
obsoletions, and breakages that have accumulated over the years.
At some point, you'll still need to bite the bullet and upgrade.

-- 
Best regards,
Platon Pronko
PGP 2A62D77A7A2CB94E

Re: Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Po Lu]

Platon Pronko <platon7pronko@gmail.com> writes:

> Even the 23.1 release should compile and run fine today.

This is, alas, no longer true.  Nothing prior to Emacs 27.1 compiles and
runs correctly on a recent GNU/Linux system.

It is possible to make 23.x work again -- several people currently use a
modified 23.4, but the changes have not been made public.

Re: Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Platon Pronko]

On 2023-04-24 14:59, Po Lu wrote:
> Platon Pronko <platon7pronko@gmail.com> writes:
> 
>> Even the 23.1 release should compile and run fine today.
> 
> This is, alas, no longer true.  Nothing prior to Emacs 27.1 compiles and
> runs correctly on a recent GNU/Linux system.

I guess my point about "updating everything or nothing at all" extends to Operating Systems as well.

Re: Changes to `make-obsolete` and similar functions make upgrades nearly impossible.

[Ruijie Yu via Users list for the GNU Emacs text editor]

Lloyd Zusman <hippoman@potamuses.net> writes:

> I'm a very long-term GNU emacs user: since the 1980's.
>
> I have been using numerous elisp packages, lots of which date
> back many years, and a few of my own elisp modules go all the
> way back to the 1980's.
>
> I have been using emacs-27.2 for a few years, and now I decided
> to upgrade again. However, when going to emacs-28.2, I hit an
> issue with the following emacs enhancement (this comes from the
> emacs change log):
>
>> 2021-01-03  Stefan Monnier  <monnier@iro.umontreal.ca>
>>
>>        * lisp/emacs-lisp/byte-run.el (make-obsolete): Make `when` mandatory
>>
>>        (define-obsolete-function-alias, make-obsolete-variable)
>>        (define-obsolete-variable-alias): Adjust similarly.
>
> Because of `when` becoming mandatory, I now get literally hundreds
> of messages which look like this when starting up emacs-28.2 ...
>
>> Warning (comp): /path/to/some-elisp-module.el: Error: Wrong number of arguments make-obsolete-variable

Would it work if you place a `:filter-args' advice on
`make-obsolete-variable', inside early-init.el or something even earlier
(not sure if one exists)?  I am not sure what the effects would be if
you byte-compile or native-compile, but loading sources directly _might_
work?

-- 
Best,


RY

[Please note that this mail might go to spam due to some
misconfiguration in my mail server -- still investigating.]