bug#81643: 32.0.50; use-package :hook is not the same as :init add-hook

>>>>> Eli Zaretskii <[email protected]> writes:

> John, any comments or suggestions?

Hello, if we expand the macros involved here, we can see the difference:

  (progn
    (unless (fboundp 'test-hook-attr)
      (autoload (function test-hook-attr) "modus-themes" nil t))
    (require-theme 'modus-themes)
    (defun test-hook-attr nil (load-theme 'modus-vivendi))
    (eval-after-load 'modus-themes
      '(progn (modus-themes-load-theme 'modus-operandi) t))
    (add-hook 'modus-themes-after-load-theme-hook (function test-hook-attr)))
  
  (progn
    (require-theme 'modus-themes)
    (defun test-hook-attr nil (load-theme 'modus-vivendi))
    (add-hook 'modus-themes-after-load-theme-hook (function test-hook-attr))
    (modus-themes-load-theme 'modus-operandi) t)

As you can see, the difference lies in the fact that `:hook' defers
configuration of the module until the function being hooked is used. This is
the default behavior of most things that “bind”. Without `:hook', there is
nothing to cause deferred behavior and so the `:config' lock is evaluated
immediately.

Adding `:demand t` to the first example will make the two equivalent.

The original reporter is correct: If the manual implies that `:hook' is the
same as using `add-hook' in a `:init' block, then it should be correctly to
say that this depends on whether (1) the nature of the use-package macro
causes auto-deferral to happen, and (2) there is code in a `:config' block
that would thusly be deferred.

Maybe it’s best to just drop this statement from the manual.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2