bug#72414: 29.4; use-package :defer keyword does not honor ":defer nil"

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 01 Aug 2024 16:30:40 -0700
> From:  Derek Upham via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> - The relevant file is "lisp/use-package/use-package-core.el".
> - The function is "use-package-normalize-keywords".
> - This is as of commit 4c6e9f5b004, current for this file on the
>   "emacs-30" tag.
> 
> Near the bottom of the use-package-normalize-keywords function, we have
> the following code block.
> 
>     ;; If at this point no :load, :defer or :no-require has been seen, then
>     ;; :load the package itself.
>     (when (and (not (plist-member args :load))
>                (not (plist-member args :defer))
>                (not (plist-member args :no-require)))
>       (setq args (append args `(:load (,name)))))
> 
> The intent is that we add an immediate-load instruction to the keyword
> list, if there is no reason to not add it.  We have a couple of possible
> reasons to not add it:
> 
> 1. There's already a :load keyword.
> 2. We have asked use-package to :defer loading.
> 3. We have asked use-package to not require the package, to avoid
>    certain byte-compilation problems.
> 
> The Use-Package documentation section 3.2 goes into more detail about
> the :defer keyword behavior in (2).
> 
>    If you customize the user option ‘use-package-always-defer’ to
>    non-‘nil’, the ‘use-package’ macro will behave as if ‘:defer t’ is
>    always specified.  This can be overridden for individual declarations
>    using either ‘:defer nil’ or ‘:demand t’ (*note Forcing loading::).
> 
> The way the code above uses plist-member doesn't match the
> documentation.  The test looks for the simple presence of a :defer
> key/value, and doesn't distinguish between any of the possible values:
> t, nil, or an integer.
> 
> Replacing plist-member with plist-get should fix the problem.  A ":defer
> nil" would produce the same nil value as a missing :defer.

Thanks for the report and the analysis.

John, any comments or suggestions about this?