all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Drew Adams <drew.adams@oracle.com>
Cc: Roland Winkler <winkler@gnu.org>, 21563@debbugs.gnu.org
Subject: bug#21563: 24.5; discourage load-hook variables
Date: Thu, 16 Jan 2020 01:54:45 +0100	[thread overview]
Message-ID: <87h80wz0dm.fsf@marxist.se> (raw)
In-Reply-To: <320a9fa6-6419-420e-ac97-9dcbe54a04a6@default> (Drew Adams's message of "Wed, 15 Jan 2020 16:24:10 -0800 (PST)")

Drew Adams <drew.adams@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





  reply	other threads:[~2020-01-16  0:54 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-25 18:57 bug#21563: 24.5; discourage load-hook variables Roland Winkler
2020-01-15 19:32 ` Stefan Kangas
2020-01-15 20:21   ` Drew Adams
2020-01-15 20:42     ` Stefan Kangas
2020-01-16  0:27       ` Roland Winkler
2020-01-15 22:06   ` Glenn Morris
2020-01-16  0:03     ` Stefan Kangas
2020-01-16  0:24       ` Drew Adams
2020-01-16  0:54         ` Stefan Kangas [this message]
2020-01-16  3:56           ` Drew Adams
2020-01-16 13:33             ` Stefan Kangas
2020-01-16 16:15               ` Drew Adams
2020-01-16 20:30                 ` Stefan Kangas
2020-01-16 21:08                   ` Drew Adams
2020-01-16  0:31       ` Stefan Kangas
2020-04-16  4:14     ` Stefan Kangas
2020-04-16  9:07       ` Roland Winkler
2020-04-26 14:33         ` Stefan Kangas
2020-10-20 17:16           ` Stefan Kangas
2020-01-16 11:49 ` Mauro Aranda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h80wz0dm.fsf@marxist.se \
    --to=stefan@marxist.se \
    --cc=21563@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=winkler@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.