[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21563: 24.5; discourage load-hook variables

From: Drew Adams
Subject: 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]