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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Kangas <stefan <at> marxist.se>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Glenn Morris <rgm <at> gnu.org>, Roland Winkler <winkler <at> gnu.org>, 21563 <at> debbugs.gnu.org
Subject: bug#21563: 24.5; discourage load-hook variables
Date: Thu, 16 Jan 2020 01:54:45 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

> 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'.

Thanks, you are correct.  I didn't mean to misquote you.

> 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.

The question now though is more limited: is it useful to keep them or
not?  Glenn says that it is not useful, and I think I agree with him.

> 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.

Well, Emacs is old.  Like any old software, it has a certain amount of
cruft and/or historical accidents.  Getting rid of such things when we
can makes Emacs easier to maintain in the long run.

> Who knows what 3rd-party code out there makes use of such hooks?

It should migrate to use (with-)eval-after-load.  That should be
backwards compatible through "Emacs version 19.29" according to C-h f.

Note that the way these hooks have been obsoleted by Glenn is to still
run them if they exist, but add an obsoletion warning.  I think this
is the correct approach.

Given how long it takes for us to finally delete obsolete stuff, that
should give ten years, give or take, before any third party code
depending on these hooks would stop working.

> And again, they're easy for users to discover.

I think a general facility is even more discoverable and user
friendly.  In particular, it shows users that this could be used for
any package, and not just packages which has defined a particular
hook.

> 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).

Shouldn't use of these hooks in code be considered bad practice for
the same reasons that eval-after-load is?

Best regards,
Stefan Kangas

Previous Next

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