GNU bug report logs - #21563
24.5; discourage load-hook variables

Previous Next

Full log

Message #23 received at 21563 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefan <at> marxist.se>, Glenn Morris <rgm <at> gnu.org>
Cc: Roland Winkler <winkler <at> gnu.org>, 21563 <at> debbugs.gnu.org
Subject: RE: bug#21563: 24.5; discourage load-hook variables
Date: Wed, 15 Jan 2020 16:24:10 -0800 (PST)

> Interesting.  Since they also seem to be prone to cause problems like
> in Bug#24491, perhaps it is indeed better to get rid of them.  They do
> look crufty and redundant once you start reviewing them in context --
> with no clear benefit.
> 
> I believe Drew already pointed out that any use of them could be
> easily replaced by (with-)?eval-after-load.

No.  I didn't say anything about "any use of them".

I said only that the behavior that a load hook isn't invoked
if the library has already been loaded can be realized by
using conditional code inside `(with-)?eval-after-load'.

A load hook is a function.  Code can invoke it anytime, in
any context.  It has no predefined behavior, on its own -
in particular, nothing like `(with-)?eval-after-load'
behavior.  The only similarity is that by convention a load
hook is invoked at the end of a Lisp file.  But nothing
prevents using a (funcall dired-load-hook) anywhere.

This is not to say that we really need to be able to do
that.  It's just to say that there's no way to claim that
`(with-)?eval-after-load' can be made to do what a load
hook does, in general.

I don't have a giant objection to doing what you're talking
about doing.  But I think it's unfortunate, and little, if
anything, is really gained.  Who knows what 3rd-party code
out there makes use of such hooks?  And again, they're easy
for users to discover.  And I think they're likely to be
used by code, and not just in init files.  That's not so
true of `(with-)?eval-after-load' (explicitly discouraged).

Previous Next

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