Re: eval-after-load as a macro (and eval-next-after-load)

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

>     However, such hooks (e.g. cua-mode-hook) are normally for users to
>     set, so if a package like crisp modifies it (too), Customize will
>     report "this variable is set outside custom"
> 
> It is normal for Lisp packages to modify hooks.  We mustn't base the
> discussion on the assumption that this is somehow anomalous.

Perhaps not, but IMO there are two types of hooks -- those defined
with defcustom [supposing they are for users to change] and other
hooks [which are for Lisp code to change].  Mixing such hooks may lead
to undefined/undesireable behaviour.

> 
>     IMO, that is an unnecessary complication, when eval-after-load does
>     the job perfectly.  
> 
> It makes no sense to argue that people should avoid using hooks for
> this sort of customization.  This is the reason for the hooks.

So are you arguing that it is wrong to use defcustom to define hooks
(at least those which may be modified by Lisp packages)?

> It could be useful to clean up the way Custom handles hooks.  For
> instance, if Custom sees elements in the hook that it did not put
> there, it could automatically divide the elements into two parts:
> those specified thru Custom, and those specified outside Custom.
> The user, in Custom, would edit only the former.  This way, one
> hook variable would do both jobs, and we would not have to change
> any packages.

That's fine with me -- if someone can find a clean way to implement it.

How do you mark an element on a list as "set by Lisp" (or "set by
Custom")?  

What should happen if the user adds a hook that is already "set by
Lisp" via Custom?


BTW, does define-minor-mode create the xxx-mode-hook variable via
defvar (rather than defcustom)?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk