Subject: bug#21440: 25.0.50; Manual: FEATURE-unload-hook in (info "(elisp) Coding Conventions")

From: Eli Zaretskii <[email-masked]>
Date: Mon, 12 Jul 2021 14:59:45 +0300

> From: Michael Heerdegen <[email-masked]>
> Date: Mon, 12 Jul 2021 05:56:50 +0200
> Cc: Michael Albinus <[email-masked]>, [email-masked],
>  Stefan Kangas <[email-masked]>
> 
> Lars Ingebrigtsen <[email-masked]> writes:
> 
> > But I don't know whether -unload-function has the same problems that
> > -unload-hook had?
> 
> At least now (docstring of `unload-feature'):
> 
> | If a function `FEATURE-unload-function' is defined, this function
> | calls it with no arguments, before doing anything else.  That function
> | can do whatever is appropriate to undo the loading of the library.  If
> | `FEATURE-unload-function' returns non-nil, that suppresses the
> | standard unloading of the library.  Otherwise the standard unloading
> | proceeds.
> 
> So it can now be controlled whether standard unloading stuff will still
> be performed (last problem mentioned in my report -> solved).
> 
> This questionable paragraph is sill in the manual however:
> 
>    • If loading the file adds functions to hooks, define a function
>      ‘FEATURE-unload-function’, where FEATURE is the name of the feature
>      the package provides, and make it undo any such changes.  Using
>      ‘unload-feature’ to unload the file will run this function.  *Note
>      Unloading::.
> 
> I guess it is a bit outdated and this had been automated long ago,
> although partially heuristically.

I don't understand why you say this is outdated.  What did I miss?

> Instead it could say what typical non-standard changes need to be
> handled in an unload-function.

Isn't that what it says?