Re: cperl-mode: Eliminating references to obsolete packages

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> For example that "format-prompt" problem currently also affects the
>> python.el GNU ELPA package.  Luckily, AFAICT we haven't yet released
>> a new python.el package (because the version number has not been
>> bumped), but the problem is real.
>
> I noticed that some of them (but not python.el) contain a comment like
> this:
>
>   ;; This is an Elpa :core package. Don't use functionality that is not
>   ;; compatible with Emacs 24.1.
>
> ...but I don't know whether that actually helps.

It helps in the sense that at least the information is available without
having to ask someone, but for things like format-prompt applied via
searches like `grep` it's all too easy to overlook.

> For me it would be rather cumbersome to find out which functionality
> isn't compatible with Emacs 24.1.

That's yet another difficulty, indeed.

> Some recent doc strings (e.g. time-convert) show it,

It's actually not the docstring, it's a hack in the `C-h o` code which
adds this info by searching for the name in the etc/NEWS* files.

> some (e.g. format-prompt) don't.

Indeed.  Should be fixed now in `master`.

>> [...]
>> Some automated tests that try to build&compile (and treat warnings as
>> errors) those packages on the corresponding oldest Emacs version
>> supported would come in handy.
>
> Wouldn't this rule out the type of fallback patch you suggested?  When
> I byte-compile-file cperl-mode.el in Emacs 26.1 _with_ your fallback
> patch applied, I still get the warning:
>
>     In end of data:
>     cperl-mode.el:8736:1:Warning: the function ‘format-prompt’ is
>     not known to be defined.
>
> Sorta obvious, though: The compilation step doesn't _run_ the fboundp
> safeguard.

Just use `'format-prompt` instead of `#'format-prompt`.
But yes, turning warnings into errors can be tricky on older Emacsen.
There are other solutions, tho (e.g. keep an "expected output" against
which to compare so we get warned when a *new* warning appears).

IOW, the problem for now is to setup those automated tests: finding
a machine on which to run them, figuring out which version of Emacs to
use for each, making sure the corresponding Emacs version is available,
etc...

> Anyway: Are there frameworks for such tests in the Emacs repository?

I'm not very knowledgeable about that, I'm afraid.


        Stefan