bug#21563: 24.5; discourage load-hook variables

[Drew Adams]

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