unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Roland Winkler <winkler@gnu.org>
Cc: 21563@debbugs.gnu.org
Subject: bug#21563: 24.5; discourage load-hook variables
Date: Wed, 15 Jan 2020 12:21:41 -0800 (PST)	[thread overview]
Message-ID: <dafa0308-f532-453a-9bba-35ec35cb05ba@default> (raw)
In-Reply-To: <87tv4w1poj.fsf@marxist.se>

>> I had rearranged my init file so that dired got loaded
>> before I was setting dired-load-hook.

IOW, simple pilot error.

> I would suggest to declare the above variables obsolete
> and point users to eval-after-load instead.

Why?  If the only reason (only one given so far) is
that a user set a hook after loading and expected
the hook setting to be effective, then I'd say that's
not a great reason.

Pilot error can also happen for `(with-)eval-after-load'.

And there was talk at one time of discouraging that as
well, I believe.  It's still discouraged for code that's
to be included in Emacs - see (emacs) `Coding Standards'.
(But see also (emacs) `Foldout'.)

And see (elisp) `Hooks for Loading':
 "Normally, well-designed Lisp programs should not
  use 'with-eval-after-load'."

Granted, that's about "Lisp programs" and not init
files.  Still...

> Does anyone disagree with that?

I think I do.  I see something like `dired-load-hook'
as a different tool than `(with-)eval-after-load'.
Not worse or better, either generally or always.

Setting or changing the explicit hook value has
no effect if the library was already loaded, whereas
`(with-)eval-after-load' has an immediate effect in 
that case.  (Sure, the latter could test in its body
whether it's loaded and act conditionally...)

I see no good reason why, because there is more than
one way to do something, and some users might shoot
themselves in the foot with some of those ways, we
should remove those that let you do that.

Emacs and Emacs Lisp provide tons of ways to do
things, and many ways to shoot yourself in the foot.

We can instead make clear in the doc anything that
might need pointing out.  In this case, I doubt that
Roland was just lacking a statement that the load
hook would have no effect if the library had already
been loaded.  But we could certainly make that fact
explicit, if it helps in general.

Note too that `C-h f dired-mode' explicitly lists
the hooks:

 Hooks (use C-h v to see their documentation):

   'dired-before-readin-hook'
   'dired-after-readin-hook'
   'dired-mode-hook'
   'dired-load-hook'

When you use apropos or similar to find a Dired hook
you find one for after-loading.  Removing that hook
means you won't find it.  This doc would then need
to be changed to list the other hooks but also say
that if you want a function to be invoked after
loading then use `(with-)eval-after-load' and invoke
the function in the body.

IOW, no parallelism or discoverability.  Many users
won't know about `(with-)eval-after-load'.

In addition, users can easily get confused between
'dired-after-readin-hook' and 'dired-load-hook'.
Having both, with their documentation, helps users
DTRT.

What does it really hurt, to keep such hooks?





  reply	other threads:[~2020-01-15 20:21 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=dafa0308-f532-453a-9bba-35ec35cb05ba@default \
    --to=drew.adams@oracle.com \
    --cc=21563@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).