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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Derek Upham <derek_upham <at> mailfence.com>, John Wiegley <johnw <at> gnu.org>
Cc: 72414 <at> debbugs.gnu.org
Subject: bug#72414: 29.4; use-package :defer keyword does not honor ":defer nil"
Date: Fri, 02 Aug 2024 08:57:46 +0300

> 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 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.