Dealing with obsoletion warnings in non-core code

Dealing with obsoletion warnings in non-core code

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]

Here's something that keeps irking me when maintaining community
packages written back when Emacs 24.3 was a reasonable version to
support: With every new Emacs release I receive more and more
byte-compiler warnings that are tricky to silence.  One pattern that
keeps showing up is that of functions/variables the byte-compiler
doesn't know about (for example because these are only available in a
future Emacs release), for those it's possible to use a conditional
testing for the function/variable existence:

    (if (fboundp 'new-and-exciting-function)
        (new-and-exciting-function)
      (boring-function))

The same trick however cannot be used for functions/variables declared
obsoleted, the only construct I've found to work in this case is the
following:

    (with-suppressed-warnings ((obsolete old-but-useful-function))
      (if (fboundp 'recommended-function)
          (recommended-function)
        (old-but-useful-function)))

Ideally I'd like to be able to write the following instead to avoid the
needless repetition:

    (if (fboundp 'recommended-function)
        (recommended-function)
      (old-but-useful-function))

Is there something I'm overlooking here?  I've looked at core code and
it seems to mostly ignore this kind of compatibility issue and instead
drops all obsolete usage.  This is not always an option as community
package author.  Many authors and users just ignore warnings, especially
if they can't do anything about them.  This leads to fatigue and might
let them overlook actually important warnings.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Dealing with obsoletion warnings in non-core code

[Stefan Monnier]

> The same trick however cannot be used for functions/variables declared
> obsoleted, the only construct I've found to work in this case is the
> following:
>
>     (with-suppressed-warnings ((obsolete old-but-useful-function))
>       (if (fboundp 'recommended-function)
>           (recommended-function)
>         (old-but-useful-function)))
>
> Ideally I'd like to be able to write the following instead to avoid the
> needless repetition:
>
>     (if (fboundp 'recommended-function)
>         (recommended-function)
>       (old-but-useful-function))

Indeed, it's a problem of which I'm aware but I don't know how to solve
it nicely.  Here's my thoughts about it so far:

I see how I could silence the obsolescence warning for:

      (if (fboundp 'old-but-useful-function)
          (old-but-useful-function)
        (recommended-function))

but that then gives you byte-compile warnings in older Emacsen because
of the use of a `recommended-function` they don't know about, and more
problematically it makes your code keep using the obsolete function even
when the all-dancing-all-singing `recommended-function` is
already available.

I guess we could try and add some kind of database of "replacements", so
when the byte-compiler sees (fboundp 'recommended-function) it knows to
silence warnings for `old-but-useful-function`, but that seems terribly
ad-hoc, will likely only work for some particular cases, and requires
the programmer to be aware of which `recommend-function` to test in
order to silence the warning.  Maybe it's still worth doing,
I don't know.


        Stefan

Re: Dealing with obsoletion warnings in non-core code

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 28 Sep 2020 13:32:47 -0400
> 
> > Ideally I'd like to be able to write the following instead to avoid the
> > needless repetition:
> >
> >     (if (fboundp 'recommended-function)
> >         (recommended-function)
> >       (old-but-useful-function))
> 
> Indeed, it's a problem of which I'm aware but I don't know how to solve
> it nicely.

What about something like the below?

  (if (> emacs-major-version NN)
    (defun recommended-function (...)
      ...))

Re: Dealing with obsoletion warnings in non-core code

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

> What about something like the below?
> 
>   (if (> emacs-major-version NN)
>     (defun recommended-function (...)
>       ...))

You don't want a third-party package defining a potentially
non-conformant version of future built-in functionality (for example if
they take the definition from a specific Emacs version and it changes in
another one).  Users could mistake that for the real one.  Shimming may
be acceptable in a JavaScript world, but remember, they have invented
fixes to lack of namespacing and modules and we haven't, so their damage
from a package is global.

Besides, isn't the logic the wrong way around?  The recommended function
is something available in a newer Emacs version, so you'd test for an
older one and if the check is positive, define the shim.  Assuming you
can even, some functionality cannot be backported that easily.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Dealing with obsoletion warnings in non-core code

[Eli Zaretskii]

> Date: Mon, 28 Sep 2020 20:34:57 +0200
> From: Vasilij Schneidermann <mail@vasilij.de>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> >   (if (> emacs-major-version NN)
> >     (defun recommended-function (...)
> >       ...))
> 
> You don't want a third-party package defining a potentially
> non-conformant version of future built-in functionality

We've been using such shims in packages that supported both Emacs and
XEmacs, for eons.  I don't see how it's suddenly so wrong.

> (for example if they take the definition from a specific Emacs
> version and it changes in another one)

That's a separate problem, and will happen even if you only support
versions where the function is available.  It's why we try very hard
not to make backward-incompatible changes in public APIs.

> Besides, isn't the logic the wrong way around?  The recommended function
> is something available in a newer Emacs version, so you'd test for an
> older one and if the check is positive, define the shim.

You assume that the older one is removed?  That usually doesn't
happen.

> Assuming you can even, some functionality cannot be backported that
> easily.

If the functionality cannot be had at all, there's no problem: just
provide a no-op function by that name.

Anyway, you asked how to avoid warning messages, and I suggested a way
which should do that.  If that's not what you want, fine; I tried to
help you.

Re: Dealing with obsoletion warnings in non-core code

[Stefan Monnier]

>> > Ideally I'd like to be able to write the following instead to avoid the
>> > needless repetition:
>> >
>> >     (if (fboundp 'recommended-function)
>> >         (recommended-function)
>> >       (old-but-useful-function))
>> 
>> Indeed, it's a problem of which I'm aware but I don't know how to solve
>> it nicely.
>
> What about something like the below?
>
>   (if (> emacs-major-version NN)
>     (defun recommended-function (...)
>       ...))

I'm not sure I understand what you mean.  You're suggesting to replace
the `fboundp` test above with something like:

    (if (< emacs-major-version NN)
      (defun recommended-function (...)
        ...
        (old-but-useful-function)
        ...))

    [...]

        (recommended-function)

?  If so, I fail to see how it helps.  It will still result in an obsolete
warning on new Emacsen (and adds an "unknown function" warning on old ones).

Or did I misunderstand your suggestion?


        Stefan

Re: Dealing with obsoletion warnings in non-core code

[Gregory Heytings via Emacs development discussions.]

> The same trick however cannot be used for functions/variables declared 
> obsoleted, the only construct I've found to work in this case is the 
> following:
>
>    (with-suppressed-warnings ((obsolete old-but-useful-function))
>      (if (fboundp 'recommended-function)
>          (recommended-function)
>        (old-but-useful-function)))
>
> Ideally I'd like to be able to write the following instead to avoid the 
> needless repetition:
>
>    (if (fboundp 'recommended-function)
>        (recommended-function)
>      (old-but-useful-function))

Here's a proposed solution:

(defmacro call (fun &rest args) `(funcall (intern (symbol-name ,fun)) ,@args))

(defun select-text (text)
   (if (> emacs-major-version 25)
       (call 'gui-select-text text)
     (call 'x-select-text text)))

It avoids the needless repetition, and does not give warnings on older 
Emacsen that do not know about gui-select-text, or on newer Emacsen that 
have x-select-text marked as obsolete.

Re: Dealing with obsoletion warnings in non-core code

[Gregory Heytings via Emacs development discussions.]

>> The same trick however cannot be used for functions/variables declared 
>> obsoleted, the only construct I've found to work in this case is the 
>> following:
>>
>>    (with-suppressed-warnings ((obsolete old-but-useful-function))
>>      (if (fboundp 'recommended-function)
>>          (recommended-function)
>>        (old-but-useful-function)))
>> 
>> Ideally I'd like to be able to write the following instead to avoid the 
>> needless repetition:
>>
>>    (if (fboundp 'recommended-function)
>>        (recommended-function)
>>      (old-but-useful-function))
>
> Here's a proposed solution:
>
> (defmacro call (fun &rest args) `(funcall (intern (symbol-name ,fun)) ,@args))
>
> (defun select-text (text)
>  (if (> emacs-major-version 25)
>      (call 'gui-select-text text)
>    (call 'x-select-text text)))
>
> It avoids the needless repetition, and does not give warnings on older 
> Emacsen that do not know about gui-select-text, or on newer Emacsen that 
> have x-select-text marked as obsolete.
>

P.S.:

Obviously

(defun select-text (text)
   (if (fboundp 'gui-select-text)
       (call 'gui-select-text text)
     (call 'x-select-text text)))

also works.

Re: Dealing with obsoletion warnings in non-core code

[Gregory Heytings via Emacs development discussions.]

>>> The same trick however cannot be used for functions/variables declared 
>>> obsoleted, the only construct I've found to work in this case is the 
>>> following:
>>>
>>>    (with-suppressed-warnings ((obsolete old-but-useful-function))
>>>      (if (fboundp 'recommended-function)
>>>          (recommended-function)
>>>        (old-but-useful-function)))
>>> 
>>> Ideally I'd like to be able to write the following instead to avoid 
>>> the needless repetition:
>>>
>>>    (if (fboundp 'recommended-function)
>>>        (recommended-function)
>>>      (old-but-useful-function))
>> 
>> Here's a proposed solution:
>> 
>> (defmacro call (fun &rest args) `(funcall (intern (symbol-name ,fun)) ,@args))
>> 
>> (defun select-text (text)
>>  (if (> emacs-major-version 25)
>>      (call 'gui-select-text text)
>>    (call 'x-select-text text)))
>> 
>> It avoids the needless repetition, and does not give warnings on older 
>> Emacsen that do not know about gui-select-text, or on newer Emacsen 
>> that have x-select-text marked as obsolete.
>> 
>
> P.S.:
>
> Obviously
>
> (defun select-text (text)
>  (if (fboundp 'gui-select-text)
>      (call 'gui-select-text text)
>    (call 'x-select-text text)))
>
> also works.
>

P.P.S.:

And for variables, the equivalent would of course be:

(defmacro assign (var val) `(set (intern (symbol-name ,var)) ,val))

(if (boundp 'switch-to-prev-buffer-skip)
     (assign 'switch-to-prev-buffer-skip t)
   (assign 'switch-to-visible-buffer t))

Re: Dealing with obsoletion warnings in non-core code

[Stefan Monnier]

> Here's a proposed solution:
>
> (defmacro call (fun &rest args) `(funcall (intern (symbol-name ,fun)) ,@args))
>
> (defun select-text (text)
>   (if (> emacs-major-version 25)
>       (call 'gui-select-text text)
>     (call 'x-select-text text)))

That's just obfuscating the code (which will prevent the compiler from
detecting some real errors such as when you have a typo in the
function's name or when you don't provide the right number of args), and
might be defeated by compiler optimizations.

I think the OP's question was how to "do it right", rather than how to
work around the problem.


        Stefan

Re: Dealing with obsoletion warnings in non-core code

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Mon, 28 Sep 2020 15:24:36 -0400
> 
> > What about something like the below?
> >
> >   (if (> emacs-major-version NN)
> >     (defun recommended-function (...)
> >       ...))
> 
> I'm not sure I understand what you mean.  You're suggesting to replace
> the `fboundp` test above with something like:
> 
>     (if (< emacs-major-version NN)
>       (defun recommended-function (...)
>         ...
>         (old-but-useful-function)
>         ...))

No, I didn't suggest to call old-but-useful-function.  I suggested to
implement recommended-function or its close emulation.

Re: Dealing with obsoletion warnings in non-core code

[Gregory Heytings via Emacs development discussions.]

Hi Stefan,

I gave the two macros a better name, they are now:

(defmacro funcall-no-warn (fun &rest args) `(funcall (intern (symbol-name ,fun)) ,@args))
(defmacro set-no-warn (var val) `(set (intern (symbol-name ,var)) ,val))

and should be used as follows:

(if (fboundp 'new-function)
     (funcall-no-warn 'new-function arg ...)
   (funcall-no-warn 'old-function arg ...))

(if (boundp 'new-variable)
     (set-no-warn 'new-variable value)
   (set-no-warn 'old-variable value))

>
> That's just obfuscating the code
>

You probably meant: Indeed, that Just Works^TM, congratulations! ;-)

>
> (which will prevent the compiler from detecting some real errors such as 
> when you have a typo in the function's name or when you don't provide 
> the right number of args)
>

Indeed.  If there's another way to do this while detecting errors at 
compilation time, that would be even better.  OTOH, this will quickly 
raise a runtime error in case of typos or wrong number of arguments, which 
is unlikely to get unnoticed by the maintainer.  Of course I'm not 
advocating to use this everywhere.

>
> and might be defeated by compiler optimizations.
>

It might be, but AFAICS it is not.  I forgot to mention that I tested the 
above macros on Emacs 21, 22, 23, 24, 25, 26, 27 and 28.  As I said, it 
Just Works^TM.

>
> I think the OP's question was how to "do it right", rather than how to 
> work around the problem.
>

I don't know.  It's just my proposed solution.  OTOH, I don't see how he 
could "do it right" when his problem statement mentions that he wants to 
support old Emacs versions, which by definition nobody can improve 
anymore.

Your idea of of a database of replacements might work, but it has to be 
implemented, and for the use case the OP has in mind it will not be useful 
before Emacs 3X.

Gregory

Re: Dealing with obsoletion warnings in non-core code

[Stefan Monnier]

> Your idea of of a database of replacements might work, but it has to be
> implemented, and for the use case the OP has in mind it will not be useful
> before Emacs 3X.

Emacs-3X is what I'm interested in.  If I only cared about "current
Emacs", then I wouldn't be working on Emacs itself ;-)


        Stefan

Re: Dealing with obsoletion warnings in non-core code

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 299 bytes --]

in the meantime, I've been using file-local variables  by setting
byte-compiler-warning to (not obsolete) works for small file units where
the file-level warning shut off doesn't hide other real obsolete
warnings that deserve fixing 
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Dealing with obsoletion warnings in non-core code

[Gregory Heytings via Emacs development discussions.]

>> Your idea of of a database of replacements might work, but it has to be 
>> implemented, and for the use case the OP has in mind it will not be 
>> useful before Emacs 3X.
>
> Emacs-3X is what I'm interested in.  If I only cared about "current 
> Emacs", then I wouldn't be working on Emacs itself ;-)
>

Being interested in Emacs 3X does not conflict with being interested in 
Emacs 2X _users_ ;-)