Strange eval-after-load

Strange eval-after-load

[Richard Stallman]

I was distressed to read that there are 70 calls to eval-after-load in
the Emacs sources.  That is very bad.  After the release, we should eliminate all of these,
just as we should eliminate all use of defadvice.

Starting immediately, please do NOT install calls to eval-after-load
in Emacs without asking for my specific approval.


In some cases, a file specifies eval-after-load for itself!  For
instance, msb.el ends with

    (provide 'msb)
    (eval-after-load "msb" '(run-hooks 'msb-after-load-hook 'msb-after-load-hooks))

What is it trying to do?
Why not just call run-hooks directly,
testing (featurep 'msb) before calling provide?

And look at these crocks in net/tramp.el

(unless (featurep 'xemacs)
  (eval-after-load "tramp"
    '(progn
       (require 'tramp-ftp)
       (add-hook 'tramp-unload-hook
		 '(lambda ()
		    (when (featurep 'tramp-ftp)
		      (unload-feature 'tramp-ftp 'force)))))))
(when (and tramp-unified-filenames (featurep 'xemacs))
  (eval-after-load "tramp"
    '(progn
       (require 'tramp-efs)
       (add-hook 'tramp-unload-hook
		 '(lambda ()
		    (when (featurep 'tramp-efs)
		      (unload-feature 'tramp-efs 'force)))))))

Why not do them the straightforward way, at the end?


However, confusing as these are, they are not as bad as using
`eval-after-load' in the "usual" way, for another file.  That is bad
for maintenance just as use of advice is bad for maintenance.

Re: Strange eval-after-load

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 25 May 2006 22:22:57 -0400
> 
> However, confusing as these are, they are not as bad as using
> `eval-after-load' in the "usual" way, for another file.  That is bad
> for maintenance just as use of advice is bad for maintenance.

How about starting a file with style guidelines such as these?  We
could begin as a simple text file somewhere in admin/, and later, when
it accumulates enough material, rewrite it as a coherent section for
the ELisp manual.

If there's already a place where we describe such issues, please tell
me where it is; I will then add the references to eval-after-load
there.

Re: Strange eval-after-load

[Luc Teirlinck]

Eli Zaretskii wrote:

   If there's already a place where we describe such issues, please tell
   me where it is; I will then add the references to eval-after-load
   there.

There is (elisp)Tips.

Sincerely,

Luc.

Re: Strange eval-after-load

[Eli Zaretskii]

> Date: Fri, 26 May 2006 09:20:49 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: rms@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> 
>    If there's already a place where we describe such issues, please tell
>    me where it is; I will then add the references to eval-after-load
>    there.
> 
> There is (elisp)Tips.

Thanks, I added the advice against eval-after-load there.

Re: Strange eval-after-load

[Richard Stallman]

    > However, confusing as these are, they are not as bad as using
    > `eval-after-load' in the "usual" way, for another file.  That is bad
    > for maintenance just as use of advice is bad for maintenance.

    How about starting a file with style guidelines such as these?  We
    could begin as a simple text file somewhere in admin/, and later, when
    it accumulates enough material, rewrite it as a coherent section for
    the ELisp manual.

We already have that section -- it is the Tips appendix.
Want to add a note about this?

Hi, I'm back! + Re: Strange eval-after-load

[Alan Mackenzie]

Hi, Richard and Emacs!

<OFF-TOPIC>
In case anybody's wondering what's being happening to me over the last
month (I hope somebody has), my PC died on Thursday 2006-05-25.  My
beloved 166MHz PC is dead.  :-(  I didn't lose any files, though.

I've spent most of the last month bringing a replacement PC up to
operation, installing Debian Gnu/Linux "Sarge".  It's a ghastly
experience.  Getting the basic OS installation is easy enough - even
getting X-Windows working tolerably well can be done within a few hours.

But then the pain starts, particularly with HW and networking software.
Each piece has a sequence of little glitches, each one of which takes 2
to 3 hours to resolve.  The documentation is nearly always nowhere near
the quality of Emacs's, and is not in any particular place - there's the
HOWTOs (most useful), most programs have something in /usr/share/doc,
and sometimes you have to go down to the Linux kernel documentation.
Sometimes its authors fragment it into many files.html, thus making text
searches difficult.

Many, many times I had to interpret messages in /var/log/..., or even
delve into the /proc/.... area of the filesystem.  Getting my printing
working, for example, took me a full working day.

I think this thing is one of the biggest obstacles to the use of free
OSes - Routinely setting up a PC with G/L, except perhaps in a rigid
lowest-common-denominator configuration created by Red-Hat or SuSE, is
beyond the capabilities of all but the most stubborn and dedicated
hackers.  Several times I was asking to myself, half seriously, is
Microsoft Windows XP really _that_ bad?  [A: yes it is.  ;-]

Anyhow, with apologies for such a delayed response to this thread, back
to Emacs....
</OFF-TOPIC>

On Thu, May 25, 2006 at 10:22:57PM -0400, Richard Stallman wrote:
> I was distressed to read that there are 70 calls to eval-after-load in
> the Emacs sources.  That is very bad.  After the release, we should
> eliminate all of these, just as we should eliminate all use of
> defadvice.
 
There are also around 800 gotos.
 
> Starting immediately, please do NOT install calls to eval-after-load
> in Emacs without asking for my specific approval.

I would beg you not to be so dogmatic.  There are valid uses for
eval-after-load, just as there are for goto.  For example, in
cc-defs.el, we have:

    ;; Make edebug understand the macros.
    (eval-after-load "edebug"
      '(progn
           (def-edebug-spec cc-eval-when-compile t)
           (def-edebug-spec c-point t)
	   .....
	   ))

This seems to be a good thing.  Shouldn't such a lisp form accompany
_every_ defmacro?  Alternatives to this sort of thing would either
inconvenience CC Mode hackers severely, or unnecessarily load Edebug
along with CC Mode.
 
I'm asking you explicitly to permit eval-after-load forms like this, for
some suitable value of "like".

[ .... ]

> However, confusing as these are, they are not as bad as using
> `eval-after-load' in the "usual" way, for another file.  That is bad
> for maintenance just as use of advice is bad for maintenance.

I do not understand this.  I think the use of (eval-after-load "edebug"
...), as above, is helpful for maintenance.

-- 
Alan.

Re: Hi, I'm back! + Re: Strange eval-after-load

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

>     ;; Make edebug understand the macros.
>     (eval-after-load "edebug"
>       '(progn
>            (def-edebug-spec cc-eval-when-compile t)
>            (def-edebug-spec c-point t)
> 	   .....
> 	   ))

each defmacro can include a `declare' form which
can include a (debug SPEC) clause.  i wonder if:

  (def-edebug-spec cc-eval-when-compile t)

is equivalent to

  (defmacro cc-eval-when-compile (...)
    (declare (debug t))
    ...)

?  if so, these particular usages of `eval-after-load'
are no longer necessary.

thi

Re: Hi, I'm back! + Re: Strange eval-after-load

[Alan Mackenzie]

On Sun, Jul 02, 2006 at 01:28:33PM -0400, Thien-Thi Nguyen wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >     ;; Make edebug understand the macros.
> >     (eval-after-load "edebug"
> >       '(progn
> >            (def-edebug-spec cc-eval-when-compile t)
> >            (def-edebug-spec c-point t)
> > 	   .....
> > 	   ))

> each defmacro can include a `declare' form which
> can include a (debug SPEC) clause.  i wonder if:

>   (def-edebug-spec cc-eval-when-compile t)

> is equivalent to

>   (defmacro cc-eval-when-compile (...)
>     (declare (debug t))
>     ...)

Ah.  I didn't know about that.  Thanks!

> ?  if so, these particular usages of `eval-after-load'
> are no longer necessary.

This feature is not documented in the Elisp for Emacs 21, and is thus
probably available only in GNU Emacs 22.  Even after the release of Emacs
22, it will still be necessary to Edebug CC Mode with other Emacsen.

I don't think this invalidates my main point, namely that there are valid
uses of eval-after-load.

> thi

-- 
Alan.

Re: Hi, I'm back! + Re: Strange eval-after-load

[Richard Stallman]

    I don't think this invalidates my main point, namely that there are valid
    uses of eval-after-load.

Perhaps there are some.  Anyone who wants to install a call to
eval-after-load should talk with me, so we can see if it really
is necessary -- and so we can maybe implement a way to avoid it.

Re: Strange eval-after-load

[Alan Mackenzie]

On Mon, Jul 03, 2006 at 11:05:27AM -0400, Richard Stallman wrote:
>     I don't think this invalidates my main point, namely that there are valid
>     uses of eval-after-load.
 
> Perhaps there are some.  Anyone who wants to install a call to
> eval-after-load should talk with me, so we can see if it really
> is necessary -- and so we can maybe implement a way to avoid it.

PLEASE, PLEASE, PLEASE give your views on the example I quoted from
cc-defs.el.  I am getting very frustrated that people seem to be evading
my main point, namely that code like

    ;; Make edebug understand the macros.
    (eval-after-load "edebug"
      '(progn
           (def-edebug-spec cc-eval-when-compile t)
           (def-edebug-spec c-point t)
           (def-edebug-spec c-set-region-active t)
	   ....
	   ))

is not merely acceptable, but is an epitome of clear and efficient
coding.  If I am wrong here, then please educate me, bring me to
understand HOW I am wrong.

Given that CC Mode is intented to be compatible with many (X)Emacs
versions, nearly all of which lack the `declare' feature in defmacro, I
cannot see how I can get along without eval-after-loads like the above.

I do not understand why you regard eval-after-load as objectionable.
Just because it can be used in an objectionable fashion does not make it
objectionable per se.

It seems to me that eval-after-load is essential in the following
circumstance:

A package (say, CC Mode) must tweak something in an optional library
which a user may choose to load (say, font-lock[*] or edebug) in order
to work satisfactorally with it.

[*] Yes, I know that font-lock is now pre-loaded, but it didn't used to
be.

I believe that Emacs should NEVER clutter up a user's ram by loading
libraries he will not be using.  Not edebug, not Info, not Font Lock[*].

Unless there is a better way of doing things, I do not want to take the
eval-after-loads out of CC Mode.  Please tell me that this is OK.

-- 
Alan.

Re: Strange eval-after-load

[Michael Albinus]

Alan Mackenzie <acm@muc.de> writes:

> It seems to me that eval-after-load is essential in the following
> circumstance:
>
> A package (say, CC Mode) must tweak something in an optional library
> which a user may choose to load (say, font-lock[*] or edebug) in order
> to work satisfactorally with it.

| edebug-setup-hook's value is 
| nil
| 
| Documentation:
| *Functions to call before edebug is used.
| Each time it is set to a new value, Edebug will call those functions
| once and then `edebug-setup-hook' is reset to nil.  You could use this
| to load up Edebug specifications associated with a package you are
| using but only when you also use Edebug.
| 
| You can customize this variable.
| 
| Defined in `edebug'.

I've checked this with prehistoric Emacs 20.7.

Best regards, Michael.

Re: Strange eval-after-load

[John Paul Wallington]

Alan Mackenzie <acm@muc.de> writes:

>     ;; Make edebug understand the macros.
>     (eval-after-load "edebug"
>       '(progn
>            (def-edebug-spec cc-eval-when-compile t)
>            (def-edebug-spec c-point t)
>            (def-edebug-spec c-set-region-active t)
> 	   ....
> 	   ))

How about getting rid of the (eval-after-load "edebug" '(progn ... ))
form and instead replacing the `def-edebug-spec' calls with (put
'mumble 'edebug-form-spec 'spec) at toplevel ?  Or alternatively
having those `def-edebug-spec' calls appear at toplevel where they
would be expanded to `put' calls when compiled provided that
`def-edebug-spec' is defined (untested) ?

Re: Strange eval-after-load

[Alan Mackenzie]

On Mon, Jul 03, 2006 at 06:06:58PM +0100, John Paul Wallington wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >     ;; Make edebug understand the macros.
> >     (eval-after-load "edebug"
> >       '(progn
> >            (def-edebug-spec cc-eval-when-compile t)
> >            (def-edebug-spec c-point t)
> >            (def-edebug-spec c-set-region-active t)
> > 	   ....
> > 	   ))

> How about getting rid of the (eval-after-load "edebug" '(progn ... ))
> form and instead replacing the `def-edebug-spec' calls with (put
> 'mumble 'edebug-form-spec 'spec) at toplevel ?  Or alternatively
> having those `def-edebug-spec' calls appear at toplevel where they
> would be expanded to `put' calls when compiled provided that
> `def-edebug-spec' is defined (untested) ?

Ah, thanks!  So the thing to do would be to load edebug at compile time,
and expand the `def-edebug-spec' macros at compile time.  This would
surely work.  Well, it will work if we can guarantee that every Emacs
where somebody's going to be installing CC Mode _has_ edebug.  Or
putting in another wearisome check for it.  But....

What's wrong with the `eval-after-load' call as it stands?

Making this change would entail checking that it works with at least 4
versions of Emacs and XEmacs.  That might not be much work, but it's a
lot more than none at all.  With the paperwork in committing the
changes, we could be talking about 2 - 4 hours to do this.  Why?

-- 
Alan.

Re: Strange eval-after-load

[Johan Bockgård]

Alan Mackenzie <acm@muc.de> writes:

> On Mon, Jul 03, 2006 at 06:06:58PM +0100, John Paul Wallington wrote:
>
>> How about getting rid of the (eval-after-load "edebug" '(progn ...
>> )) form and instead replacing the `def-edebug-spec' calls with (put
>> 'mumble 'edebug-form-spec 'spec) at toplevel ? Or alternatively
>> having those `def-edebug-spec' calls appear at toplevel where they
>> would be expanded to `put' calls when compiled provided that
>> `def-edebug-spec' is defined (untested) ?
>
> Ah, thanks! So the thing to do would be to load edebug at compile
> time, and expand the `def-edebug-spec' macros at compile time. This
> would surely work. Well, it will work if we can guarantee that every
> Emacs where somebody's going to be installing CC Mode _has_ edebug.
> Or putting in another wearisome check for it. But....

I think that edebug may be unavailable. So how about the first
alternative? Gnus uses the `(put ...)' form directly and so does ERC
(we went through the same thing).

-- 
Johan Bockgård

Re: Strange eval-after-load

[Richard Stallman]

    PLEASE, PLEASE, PLEASE give your views on the example I quoted from
    cc-defs.el.

It is obsolete -- the code should use `declare'.

def-edebug-spec is autoloaded, so calls to it do not _need_ to be in
eval-after-load.  However, it is inefficient to load all of edebug
just to execute a call to def-edebug-spec; so I think it would be good
to move that definition into subr.el.

Would someone like to do that?

    Given that CC Mode is intented to be compatible with many (X)Emacs
    versions, nearly all of which lack the `declare' feature in defmacro, I
    cannot see how I can get along without eval-after-loads like the above.

For XEmacs, you can use a conditional.  Old Emacs versions do not
matter; I do not want ugly code for their sake.

    I do not understand why you regard eval-after-load as objectionable.

I am sorry you don't understand, but I will not change this policy
and I don't have time to reopen the question.  I have other work to do!

Re: Strange eval-after-load

[Alan Mackenzie]

Hi, Richard!

On Tue, Jul 04, 2006 at 08:54:30AM -0400, Richard Stallman wrote:
>     PLEASE, PLEASE, PLEASE give your views on the example I quoted from
>     cc-defs.el.

> It is obsolete -- the code should use `declare'.

> def-edebug-spec is autoloaded, so calls to it do not _need_ to be in
> eval-after-load.  However, it is inefficient to load all of edebug
> just to execute a call to def-edebug-spec; so I think it would be good
> to move that definition into subr.el.

I'm sure this isn't the only such example.  As a more general solution
(with the idea coming from David Kastrup), how about each "utility"
library having an initialisation hook, along the lines of
c-initialization-hook?  Thus, edebug-initialization-hook would be run
exactly once, after first initialising edebug.  This could entirely
eliminate the need to use eval-after-load.

> Would someone like to do that?

>     Given that CC Mode is intented to be compatible with many (X)Emacs
>     versions, nearly all of which lack the `declare' feature in defmacro, I
>     cannot see how I can get along without eval-after-loads like the above.

> For XEmacs, you can use a conditional.  Old Emacs versions do not
> matter; I do not want ugly code for their sake.
 
OK.  From my point of view, such a conditional would make the upstream
CC Mode code ugly and (marginally) more difficult to maintain.  It's
been one of CC Mode's objectives (since 4004 B.C.) to maintain
compatibility with older (X)Emacsen as far as possible.  We shouldn't be
fighting over this incompatibility in project aims.  ;-)
 
>     I do not understand why you regard eval-after-load as objectionable.

> I am sorry you don't understand, but I will not change this policy
> and I don't have time to reopen the question.  I have other work to do!

OK.  I don't understand this policy, and I don't agree with it.  I'll
follow Martin Stjernholm's lead here[*], and say that while I won't
make these changes myself, neither in savannah nor in the CC Mode
project at SourceForge, I will respect them (in merging, for example) if
made by other people in the savannah repository.

[*] the issue then (2003) was the use of the CL stuff in Emacs at
run-time.

Thanks for being definite, here - I've got other work to do, too.  :-)

-- 
Alan.

Re: Strange eval-after-load

[Richard Stallman]

    I'm sure this isn't the only such example.  As a more general solution
    (with the idea coming from David Kastrup), how about each "utility"
    library having an initialisation hook, along the lines of
    c-initialization-hook?

This is a good solution, but since it is a certain amount of work to
set this up in each package, we do it only for the packages that need
it.

Re: Strange eval-after-load

[Bob Rogers]

   From: Richard Stallman <rms@gnu.org>
   Date: Tue, 04 Jul 2006 16:52:53 -0400

       I'm sure this isn't the only such example.  As a more general solution
       (with the idea coming from David Kastrup), how about each "utility"
       library having an initialisation hook, along the lines of
       c-initialization-hook?

   This is a good solution, but since it is a certain amount of work to
   set this up in each package, we do it only for the packages that need
   it.

Two observations:

   1.  It seems to me this can be done without any setup work on the
part of the package.  Suppose the provide routine were changed to run a
specified hook, e.g. "foo-provide-hook" if "(provide 'foo)" were
executed, and the symbol "foo" was not already on the "features" list?
That would seem to be more or less equivalent to eval-after-load, but
less magical, and without file synonym issues.  (Maybe that's not the
best idea for the hook name, but at least there are no "-provide-hook"
hits in the codebase at present.)

   2.  I notice that Fprovide already does something related, but using
after-load-alist instead of a per-package hook:

	/* Run any load-hooks for this file.  */
	tem = Fassq (feature, Vafter_load_alist);
	if (CONSP (tem))
	  Fprogn (XCDR (tem));

(This is documented for after-load-alist, BTW, but not for provide.)
But this seems to have semantic problems of its own.  What if two
packages independently decide to use this mechanism for the same third
package?  It would be somewhat tricky for them to cooperate.  Does this
other use of after-load-alist also fall under your injunction not to use
eval-after-load without first asking?

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: Strange eval-after-load

[Stuart D. Herring]

>    2.  I notice that Fprovide already does something related, but using
> after-load-alist instead of a per-package hook:
>
> 	/* Run any load-hooks for this file.  */
> 	tem = Fassq (feature, Vafter_load_alist);
> 	if (CONSP (tem))
> 	  Fprogn (XCDR (tem));
>
> (This is documented for after-load-alist, BTW, but not for provide.)
> But this seems to have semantic problems of its own.  What if two
> packages independently decide to use this mechanism for the same third
> package?  It would be somewhat tricky for them to cooperate.  Does this
> other use of after-load-alist also fall under your injunction not to use
> eval-after-load without first asking?

My apologies if I misunderstand, but it looks like you don't realize that
`after-load-alist' is precisely the implementation of `eval-after-load'. 
(The fact that Fprogn() is called allows `eval-after-load' to put multiple
forms on the alist, thus resolving the "cooperation" issue (to an
extent).)  So of course this is just as verboten as `eval-after-load' is,
as it is `eval-after-load'.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Strange eval-after-load

[Richard Stallman]

       1.  It seems to me this can be done without any setup work on the
    part of the package.  Suppose the provide routine were changed to run a
    specified hook, e.g. "foo-provide-hook" if "(provide 'foo)" were
    executed, and the symbol "foo" was not already on the "features" list?

What you are trying to achieve is precisely the problem I am trying to
avoid.  Namely, that this would work with no explicit call in the file.

The explicit call in the file is what calls the programmer's attention
to the fact that some code might be run from there.

Re: Hi, I'm back! + Re: Strange eval-after-load

[Richard Stallman]

    > Starting immediately, please do NOT install calls to eval-after-load
    > in Emacs without asking for my specific approval.

    I would beg you not to be so dogmatic.

This rule is the only way to get control over the situation.

      For example, in
    cc-defs.el, we have:

	;; Make edebug understand the macros.
	(eval-after-load "edebug"
	  '(progn
	       (def-edebug-spec cc-eval-when-compile t)
	       (def-edebug-spec c-point t)

Isn't there now a defun feature for doing this?

Re: Strange eval-after-load

[Alan Mackenzie]

Morning, Richard!

On Sun, Jul 02, 2006 at 06:30:55PM -0400, Richard Stallman wrote:
>     > Starting immediately, please do NOT install calls to eval-after-load
>     > in Emacs without asking for my specific approval.
> 
>     I would beg you not to be so dogmatic.

> This rule is the only way to get control over the situation.

I don't really understand what the situation is over which control has
to be got.  It is possible to to use eval-after-load badly, just as it
is possible to use goto badly.  That's a far cry from demonstrating that
all e-a-l's/goto's are bad.

>       For example, in
>     cc-defs.el, we have:
> 
> 	;; Make edebug understand the macros.
> 	(eval-after-load "edebug"
> 	  '(progn
> 	       (def-edebug-spec cc-eval-when-compile t)
> 	       (def-edebug-spec c-point t)

> Isn't there now a defun feature for doing this?

There is, and thanks to Thi for telling me about it.  However, this new
`declare' feature in defmacro seems to be a bit ad-hoc.  Since it
doesn't exist in older Emacsen, it's not suitable for packages like CC
Mode, which will continue to need edebugging on these other (X)Emacsen.

I really don't want to contemplate anything like a macro `meta-macro'
where

    (meta-macro c-lang-defvar ...... t)

would expand to a `defmacro' containing a `declare' in Emacs 22, and to
a `defmacro' followed by `(eval-after-load "edebug" ...)' in other
Emacsen.  I can't see any other way around this problem.  I absolutely
do not want to take these `(eval-after-load "edebug" ...)'s out of CC
Mode, because it would create so much hassle for no gain that I can see
(and I'll admit I'm struggling to keep up with all the work on CC Mode
as it is).

However, the main point of that example from cc-defs.el was not to plead
it as a special case, but to demonstrate the existence of a good use of
eval-after-load.  Nobody, not even yourself, has said that that code
snippet is intrinsically bad.  There will surely be other uses of
eval-after-load which are just as useful and necessary.

Rather than banning eval-after-load, why not formulate when it is
acceptable to use it, and put this advice into the Elisp manual?

-- 
Alan.

Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Morning, Richard!
>
> On Sun, Jul 02, 2006 at 06:30:55PM -0400, Richard Stallman wrote:
>>     > Starting immediately, please do NOT install calls to eval-after-load
>>     > in Emacs without asking for my specific approval.
>> 
>>     I would beg you not to be so dogmatic.
>
>> This rule is the only way to get control over the situation.
>
> I don't really understand what the situation is over which control has
> to be got.  It is possible to to use eval-after-load badly, just as it
> is possible to use goto badly.  That's a far cry from demonstrating that
> all e-a-l's/goto's are bad.

What about "asking for my specific approval" did you not understand?
That's a far cry from claiming that all e-a-l's/goto's are bad.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange eval-after-load

[Alan Mackenzie]

Guten Tag, David!

On Mon, Jul 03, 2006 at 12:21:45PM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Morning, Richard!

> > On Sun, Jul 02, 2006 at 06:30:55PM -0400, Richard Stallman wrote:
> >>     > Starting immediately, please do NOT install calls to eval-after-load
> >>     > in Emacs without asking for my specific approval.
> >> 
> >>     I would beg you not to be so dogmatic.
> >
> >> This rule is the only way to get control over the situation.

> > I don't really understand what the situation is over which control has
> > to be got.  It is possible to to use eval-after-load badly, just as it
> > is possible to use goto badly.  That's a far cry from demonstrating that
> > all e-a-l's/goto's are bad.

> What about "asking for my specific approval" did you not understand?

Hee!  I'll admit I didn't really see that bit.  However, knowing some of
the people on this mailing list, it seems unlikely they'll knuckle under
to this piece of bureaucracy, however enlightenedly it might be
exercised.  ;-)  I think people will either just quietly commit
eval-after-loads, or they'll write clumsy abstruse workarounds.

> That's a far cry from claiming that all e-a-l's/goto's are bad.

Not really - the implication, a most strong one, is there.  At the
moment, nobody is ready to defend the notion that e-a-l's are bad.  Not
even you.  :-(

> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)

Re: Strange eval-after-load

[Richard Stallman]

    I think people will either just quietly commit
    eval-after-loads, or they'll write clumsy abstruse workarounds.

If people try to sneak them in, I will do something about them.

The "clumsy workarounds" might actually be superior, for maintenance
purposes.  That's the reason for this policy: so people will take the
trouble to use those "clumsy" workarounds, instead of taking the
inferior lazy way out.

Re: Strange eval-after-load

[Alan Mackenzie]

Morning, Richard!

On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote:
>     I think people will either just quietly commit
>     eval-after-loads, or they'll write clumsy abstruse workarounds.
 
> If people try to sneak them in, I will do something about them.

:-)
 
> The "clumsy workarounds" might actually be superior, for maintenance
> purposes.  That's the reason for this policy: so people will take the
> trouble to use those "clumsy" workarounds, instead of taking the
> inferior lazy way out.

Richard, please tell me what's wrong with using eval-after-load.

I've been trying to get an answer to this question in post after post
after post, and all replies have been evasive.  Everybody else has been
writing as though it were perfectly obvious and uncontrovertible that
eval-after-load is bad.  It's anything but obvious to me.

If you don't want to give me an answer, for whatever reason, please tell
me explicitly.  That would be OK too.

-- 
Alan.

Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Morning, Richard!
>
> On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote:
>>     I think people will either just quietly commit
>>     eval-after-loads, or they'll write clumsy abstruse workarounds.
>  
>> If people try to sneak them in, I will do something about them.
>
> :-)
>  
>> The "clumsy workarounds" might actually be superior, for maintenance
>> purposes.  That's the reason for this policy: so people will take the
>> trouble to use those "clumsy" workarounds, instead of taking the
>> inferior lazy way out.
>
> Richard, please tell me what's wrong with using eval-after-load.
>
> I've been trying to get an answer to this question in post after
> post after post, and all replies have been evasive.  Everybody else
> has been writing as though it were perfectly obvious and
> uncontrovertible that eval-after-load is bad.  It's anything but
> obvious to me.

Like defadvice, it is hooking into parts of a package that are lacking
a proper interface.  It is not guaranteed to continue to work, its
effects are not certain when you are loading a package more than once,
it makes debugging a pain.  If there is a missing interface, the
proper solution is to create it, not fudge something onto a package
that might stop working at some time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange eval-after-load

[Alan Mackenzie]

On Tue, Jul 04, 2006 at 09:15:53AM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Morning, Richard!

> > On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote:
> >>     I think people will either just quietly commit
> >>     eval-after-loads, or they'll write clumsy abstruse workarounds.

> >> If people try to sneak them in, I will do something about them.

> > :-)

> >> The "clumsy workarounds" might actually be superior, for maintenance
> >> purposes.  That's the reason for this policy: so people will take the
> >> trouble to use those "clumsy" workarounds, instead of taking the
> >> inferior lazy way out.

> > Richard, please tell me what's wrong with using eval-after-load.

> > I've been trying to get an answer to this question in post after
> > post after post, and all replies have been evasive.  Everybody else
> > has been writing as though it were perfectly obvious and
> > uncontrovertible that eval-after-load is bad.  It's anything but
> > obvious to me.

> Like defadvice, it is hooking into parts of a package that are lacking
> a proper interface.

Not true in general.  e-a-l doesn't "hook into" packages.  It calls lisp
forms.  The lisp forms it calls need not be (and should not be) undefined
interfaces.  In my favourite example, `def-edebug-spec' is a perfectly
well defined interface.

Or have I misunderstood what you mean?

> It is not guaranteed to continue to work,

Whhaaat?  Is _any_ part of Emacs "guaranteed" to work?  If you mean that
eval-after-load is buggy, I think that the fixes I applied to it in May
fix those bugs.  If not, it should be fixed, just like any other part of
Emacs.

> its effects are not certain when you are loading a package more than
> once,

I fixed the doc-string and Elisp manual to state that the e-a-l forms are
executed _each_ time the package is loaded.  Any uncertainties are due to
the forms in e-a-l, not e-a-l itself.

> it makes debugging a pain.

That surely depends on how it is used.  You would not, I think, assert
that (eval-after-load "edebug" '(def-edebug-spec ...)) causes any
debugging difficulties at all.  On the contrary, it assists debugging.

Please substantiate your assertion.  Give me an example of a non-silly
use of e-a-l that hinders debugging.  Please show me how the alternative
would be better.  There are (or until recently were) over 70 e-a-l's in
the Emacs source.  This isn't a rhetorical thrust - I genuinely want to
find out.

> If there is a missing interface, the proper solution is to create it,

??? eval-after-load doesn't deal with "missing interfaces".  It deals
with calling functions (usually well-defined) which haven't yet been
loaded.

The forms in e-a-l are usually well defined interfaces, such as
`def-edebug-spec' or `require'.  Or do you mean something else?

> not fudge something onto a package that might stop working at some time.

eval-after-load is now well defined, and works as predictably as anything
else.  I wouldn't call the use of `def-edebug-spec' "fudging something
onto a package".

As somebody who switches Font Lock off, what would you put in cc-mode.el
for GNU Emacs 21 in place of the following form:

    (eval-after-load "font-lock" '(require 'cc-fonts))

?  Note that cc-fonts won't load without Font Lock first being loaded,
and the user who hates Font Locking doesn't want his store clogged up
with it.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)

Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Tue, Jul 04, 2006 at 09:15:53AM +0200, David Kastrup wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > On Mon, Jul 03, 2006 at 07:21:15PM -0400, Richard Stallman wrote:
>> >>     I think people will either just quietly commit
>> >>     eval-after-loads, or they'll write clumsy abstruse workarounds.
>
>> >> If people try to sneak them in, I will do something about them.
>
>> > :-)
>
>> >> The "clumsy workarounds" might actually be superior, for maintenance
>> >> purposes.  That's the reason for this policy: so people will take the
>> >> trouble to use those "clumsy" workarounds, instead of taking the
>> >> inferior lazy way out.
>
>> > Richard, please tell me what's wrong with using eval-after-load.
>
>> > I've been trying to get an answer to this question in post after
>> > post after post, and all replies have been evasive.  Everybody else
>> > has been writing as though it were perfectly obvious and
>> > uncontrovertible that eval-after-load is bad.  It's anything but
>> > obvious to me.
>
>> Like defadvice, it is hooking into parts of a package that are lacking
>> a proper interface.
>
> Not true in general.  e-a-l doesn't "hook into" packages.  It calls
> lisp forms.

So does defadvice.  You are trying to play semantic games here.

> Whhaaat?  Is _any_ part of Emacs "guaranteed" to work?  If you mean that
> eval-after-load is buggy, I think that the fixes I applied to it in May
> fix those bugs.  If not, it should be fixed, just like any other part of
> Emacs.

It is not guaranteed to continue to work because it uses a package
mechanisms in ways that are not designed for it.

>> its effects are not certain when you are loading a package more than
>> once,
>
> I fixed the doc-string and Elisp manual to state that the e-a-l
> forms are executed _each_ time the package is loaded.  Any
> uncertainties are due to the forms in e-a-l, not e-a-l itself.

Which won't work for most instances of eval-region and similar, and
the user can't actually see why or fix it since no user-visible
variable contains the info what is supposed to be happening.

>> it makes debugging a pain.
>
> That surely depends on how it is used.  You would not, I think,
> assert that (eval-after-load "edebug" '(def-edebug-spec ...)) causes
> any debugging difficulties at all.  On the contrary, it assists
> debugging.

You are playing semantic games again.

> Please substantiate your assertion.  Give me an example of a
> non-silly use of e-a-l that hinders debugging.

Any you like, because it causes unpredictable side effects if (and
only if) the `provide' line gets executed.  `provide''s DOC-string
does not even mention `eval-after-load'.

> Please show me how the alternative would be better.  There are (or
> until recently were) over 70 e-a-l's in the Emacs source.  This
> isn't a rhetorical thrust - I genuinely want to find out.

Using an interface for delayed effects that is _documented_ in the
source file of a module and where you can check a dedicated variable
for what will be happening instead of things magically happening at
`provide' time because some other library did an eval-after-load
(which will, BTW, likely cause havoc if you unload-feature that
library, as eval-after-load can't be undone) is just not the same
thing.

>> If there is a missing interface, the proper solution is to create
>> it,
>
> ??? eval-after-load doesn't deal with "missing interfaces".  It
> deals with calling functions (usually well-defined) which haven't
> yet been loaded.

You are again playing semantic games.  `eval-after-load' is used in
lack of any other interface for achieving the same results.

> As somebody who switches Font Lock off, what would you put in cc-mode.el
> for GNU Emacs 21 in place of the following form:
>
>     (eval-after-load "font-lock" '(require 'cc-fonts))

(if (featurep 'font-lock)
    (require 'cc-fonts)
  (add-hook 'font-lock-mode-hook '(lambda nil (require 'cc-fonts))))

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange eval-after-load

[Nick Roberts]

 > > As somebody who switches Font Lock off, what would you put in cc-mode.el
 > > for GNU Emacs 21 in place of the following form:
 > >
 > >     (eval-after-load "font-lock" '(require 'cc-fonts))
 > 
 > (if (featurep 'font-lock)
 >     (require 'cc-fonts)
 >   (add-hook 'font-lock-mode-hook '(lambda nil (require 'cc-fonts))))

font-lock-mode-hook doesn't seem to exist, perhaps because it's only a minor
mode.

The only problem that I've encountered with eval-after-load was one
Klaus Zeitler reported using (eval-after-load "gdb-ui" FORM)
(http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-05/msg00389.html)

It might have been one of timing - unlike a mode-hook you have no control over
when the forms are evaluated - but it gave problems even when the FORM did
nothing significant.  That said, I don't think there was a problem before
Alan's recent changes to eval-after-load ;-)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Strange eval-after-load

[Johan Bockgård]

Nick Roberts <nickrob@snap.net.nz> writes:

> font-lock-mode-hook doesn't seem to exist,

but it does.

-- 
Johan Bockgård

Re: Strange eval-after-load

[Thien-Thi Nguyen]

Alan Mackenzie <acm@muc.de> writes:

> I've been trying to get an answer to this question in post after post
> after post, and all replies have been evasive.  Everybody else has
> been writing as though it were perfectly obvious and uncontrovertible
> that eval-after-load is bad.  It's anything but obvious to me.

the fewer axioms, the more obvious the proofs, no?

using `eval-after-load' introduces complexity at the maintenance level
in order to hide that complexity at the user level.  that is, it is a
feature intended for users who may not care much about the consequences
of its use.  maintainers, on the other hand, always care about such
consequences because time spent understanding complex interdependent
behavior is time not spent hacking (or doing other maintenance).

people have a different feel for "complex interdependent behavior" and a
different valuation for it when they recognize it, so a one- or two-link
chain (of loading, of coding, of debugging, of required reasoning, etc)
may not seem excessive to one but may seem extremely tedious to another.
in moments of drunken elitism one might even exclaim "how crass!".

surely having fewer such chains is better, especially when the given
alternative (to DTRT) is to be more precise and more explicit.  that is
the general problem of `eval-after-load', essentially, from a lazy
maintainer's pov: it is overkill.

anyway, that's how i see things.  ymmv.

thi

Re: Strange eval-after-load

[Richard Stallman]

    Richard, please tell me what's wrong with using eval-after-load.

Here's the explanation from tips.texi.

@item
Redefining (or advising) an Emacs primitive is a bad idea.  It may do
the right thing for a particular program, but there is no telling what
other programs might break as a result.  In any case, it is a problem
for debugging, because the two advised function doesn't do what its
source code says it does.  If the programmer investigating the problem
is unaware that there is advice on the function, the experience can be
very frustrating.

We hope to remove all the places in Emacs that advise primitives.
In the mean time, please don't add any more.

@item
It is likewise a bad idea for one Lisp package to advise a function
in another Lisp package.

@item
Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
Loading}) in libraries and packages.  This feature is meant for
personal customizations; using it in a Lisp program is unclean because
it modifies the behavior of another Lisp file in an invisible way.
This is an obstacle for debugging, much like advising a function in
the other package.

Re: Strange eval-after-load

[Alan Mackenzie]

On Tue, Jul 04, 2006 at 01:30:17PM -0400, Richard Stallman wrote:
>     Richard, please tell me what's wrong with using eval-after-load.
 
> Here's the explanation from tips.texi.

[ .... ]

> @item
> It is likewise a bad idea for one Lisp package to advise a function
> in another Lisp package.

> @item
> Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
> Loading}) in libraries and packages.  This feature is meant for
> personal customizations; using it in a Lisp program is unclean because
> it modifies the behavior of another Lisp file in an invisible way.
> This is an obstacle for debugging, much like advising a function in
> the other package.

(eval-after-load "edebug" '(def-edebug-spec c-point t))

To construe this form as "modifying the behaviour of another Lisp file
(?edebug, presumably) in an invisible way" seems like a total perversion
of reality to me.  I would call this e-a-l "Telling another Lisp file
how to handle the current one" - in essence, the module which is
modified by this e-a-l is cc-defs, not edebug.

[Just for clarity, this point is independent of the precise semantics of
`def-edebug-spec'.  I think it is also the case that `def-edebug-spec'
doesn't modify edebug's state at all.]

-- 
Alan.

Re: Strange eval-after-load

[Nick Roberts]

 > To construe this form as "modifying the behaviour of another Lisp file
 > (?edebug, presumably) in an invisible way" seems like a total perversion
 > of reality to me.

To exaggerate the case makes it appear weaker not stronger.

 >                    I would call this e-a-l "Telling another Lisp file
 > how to handle the current one" - in essence, the module which is
 > modified by this e-a-l is cc-defs, not edebug.

Theres a more fundamental reality here: Richard perceives eval-after-load
as bad and he is project mainatainer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Strange eval-after-load

[Eli Zaretskii]

> Date: Tue, 4 Jul 2006 22:08:05 +0100
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> (eval-after-load "edebug" '(def-edebug-spec c-point t))
> 
> To construe this form as "modifying the behaviour of another Lisp file
> (?edebug, presumably) in an invisible way" seems like a total perversion
> of reality to me.  I would call this e-a-l "Telling another Lisp file
> how to handle the current one" - in essence, the module which is
> modified by this e-a-l is cc-defs, not edebug.

Doesn't "Telling another Lisp file how to handle the current one"
modify the behavior of that other package in a way that isn't visible
if you look at the code of that other package?  In your example above,
Edebug's behavior is modified, but one cannot know that by reading
Edebug's code alone.

Btw, the original text I wrote for this tip was a bit different, it
explicitly said that eval-after-load increases a coupling between the
two packages, which is a maintenance burden:

    Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
    Loading}) in libraries and packages.  This feature is meant for
    personal customizations; using it in a Lisp package increases the
    coupling between it and the package mentioned in
    @code{eval-after-load}, and thus makes it harder to maintain the two
    packages independently.

Re: Strange eval-after-load

[Alan Mackenzie]

On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 4 Jul 2006 22:08:05 +0100
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > (eval-after-load "edebug" '(def-edebug-spec c-point t))

> > To construe this form as "modifying the behaviour of another Lisp file
> > (?edebug, presumably) in an invisible way" seems like a total perversion
> > of reality to me.  I would call this e-a-l "Telling another Lisp file
> > how to handle the current one" - in essence, the module which is
> > modified by this e-a-l is cc-defs, not edebug.

> Doesn't "Telling another Lisp file how to handle the current one"
> modify the behavior of that other package in a way that isn't visible
> if you look at the code of that other package?

Whether it does or not is surely independent of whether
`def-edebug-spec' is called directly, or through eval-after-load.
Again, this change is just as visible, whichever way the function is
called.  Surely?

There is nothing objectionable about using the documented functional
interface `def-edebug-spec'.

> In your example above, Edebug's behavior is modified, but one cannot
> know that by reading Edebug's code alone.

Why is this bad?  Edebug provides the function `def-edebug-spec'
specifically to allow Edebug's behaviour to be modified thusly.  Why is
it OK to do this in a direct call, but not OK within an eval-after-load?
Wherein lies the essential difference?

> Btw, the original text I wrote for this tip was a bit different, it
> explicitly said that eval-after-load increases a coupling between the
> two packages, which is a maintenance burden:
> 
>     Likewise, avoid using @code{eval-after-load} (@pxref{Hooks for
>     Loading}) in libraries and packages.  This feature is meant for
>     personal customizations; using it in a Lisp package increases the
>     coupling between it and the package mentioned in
>     @code{eval-after-load}, and thus makes it harder to maintain the two
>     packages independently.

How does eval-after-load change the coupling?  It seems to me that all
the nasty coupling things that can happen, like accessing global
variables, implicitly sharing data structurings, etc., are completely
orthogonal to eval-after-load.

eval-after-load _decreases_ the "coupling" in an important sense - it
allows CC Mode to run without forcing Edebug to be loaded.

It is true that e-a-l makes the code more difficult to read, but then,
so do things like ,@ inside macros.

I still don't understand.  I'm trying to.

-- 
Alan.

Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
>> > Date: Tue, 4 Jul 2006 22:08:05 +0100
>> > From: Alan Mackenzie <acm@muc.de>
>> > Cc: emacs-devel@gnu.org
>
>> > (eval-after-load "edebug" '(def-edebug-spec c-point t))
>
>> > To construe this form as "modifying the behaviour of another Lisp file
>> > (?edebug, presumably) in an invisible way" seems like a total perversion
>> > of reality to me.  I would call this e-a-l "Telling another Lisp file
>> > how to handle the current one" - in essence, the module which is
>> > modified by this e-a-l is cc-defs, not edebug.
>
>> Doesn't "Telling another Lisp file how to handle the current one"
>> modify the behavior of that other package in a way that isn't visible
>> if you look at the code of that other package?
>
> Whether it does or not is surely independent of whether
> `def-edebug-spec' is called directly, or through eval-after-load.
> Again, this change is just as visible, whichever way the function is
> called.  Surely?

Again, you are playing semantic games.  The change is not visible
where it happens, namely at the (provide 'edebug).

> There is nothing objectionable about using the documented functional
> interface `def-edebug-spec'.

Straw man.  Nobody objected to its use.  What is objectional is that
its call happens at the (provide 'edebug) line without any visible
indication in edebug.el, and without any user-accessible variables or
hook that would allow for inspection and modification of the behavior.
A user won't have cause to be surprised if he added eval-after-load
himself.  But expecting and tracking every such use that might be
hidden in Emacs' code base is a bit much.

>> In your example above, Edebug's behavior is modified, but one cannot
>> know that by reading Edebug's code alone.
>
> Why is this bad?

The reasons have been cited to you several times and it is in the
manual which also has been cited to you.

I think you are blinded by your wishes.

> I still don't understand.  I'm trying to.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange eval-after-load

[Alan Mackenzie]

On Wed, Jul 05, 2006 at 11:09:24AM +0200, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Wed, Jul 05, 2006 at 06:20:41AM +0300, Eli Zaretskii wrote:
> >> > Date: Tue, 4 Jul 2006 22:08:05 +0100
> >> > From: Alan Mackenzie <acm@muc.de>
> >> > Cc: emacs-devel@gnu.org

> >> > (eval-after-load "edebug" '(def-edebug-spec c-point t))

> >> > To construe this form as "modifying the behaviour of another Lisp file
> >> > (?edebug, presumably) in an invisible way" seems like a total perversion
> >> > of reality to me.  I would call this e-a-l "Telling another Lisp file
> >> > how to handle the current one" - in essence, the module which is
> >> > modified by this e-a-l is cc-defs, not edebug.

> >> Doesn't "Telling another Lisp file how to handle the current one"
> >> modify the behavior of that other package in a way that isn't visible
> >> if you look at the code of that other package?

> > Whether it does or not is surely independent of whether
> > `def-edebug-spec' is called directly, or through eval-after-load.
> > Again, this change is just as visible, whichever way the function is
> > called.  Surely?

> The change is not visible where it happens, namely at the (provide 'edebug).

That is WHEN the change happens.  Loading edebug is the trigger.  I'm
not sure what you mean by "where", here.  Do you mean the module whose
data is changed?  Or do you mean the module whose functions make the
change?  If you could say what you wanted to see and why, that might
help me.

> > There is nothing objectionable about using the documented functional
> > interface `def-edebug-spec'.

> Straw man.  Nobody objected to its use.  What is objectional is that
> its call happens at the (provide 'edebug) line without any visible
> indication in edebug.el, and without any user-accessible variables or
> hook that would allow for inspection and modification of the behavior.

Don't all hooks work this way?  What do you mean by "visible"?  I'm
sorry, but the rest of the paragraph is too vague to make any sense to
me.  A call happening without user-accessible variables or a hook is
like a cuckoo clock chiming without Pythagoras's theorem.  There are
several behaviours which you could mean by "the" behaviour.  When would
a user want to access these variables, and why?  What would be the
purpose of using a hook to modify whichever behaviour?

> A user won't have cause to be surprised if he added eval-after-load
> himself.  But expecting and tracking every such use that might be
> hidden in Emacs' code base is a bit much.

It's no more or less difficult that tracking down every place a hook is
used.  eval-after-load is conceptually the same as add-hook.  Why is
using e-a-l worse than using LaTeX-mode-hook,  for example?

> >> In your example above, Edebug's behavior is modified, but one cannot
> >> know that by reading Edebug's code alone.

> > Why is this bad?

> The reasons have been cited to you several times and it is in the
> manual which also has been cited to you.
 
Resorts to hand waving abstractions have been made, but no descent to the
concrete.  I think that you and Richard and Eli must have experienced
problems with eval-after-load - I've not.  The only problems I've had
with it were those cause by bugs in its code and documentation, not its
use, and I've tried to fix these bugs.

Since I haven't experienced these problems, the level of abstraction you
have been talking at is meaningless to me.  It's obvious that
eval-after-load can be used very stupidly, but that's not the point.

I cannot conceive of any (real) problems which might be caused by

   (eval-after-load "edebug" '(def-edebug-spec c-point t))

If you're still willing to carry on trying to help me get the point,
perhaps you could cite a specific problem caused by a specific
"nice" use of eval-after-load.  I'd be grateful.

> David Kastrup, Kriemhildstr. 15, 44793 Bochum

-- 
Alan Mackenzie (Munich, Germany)

Re: Strange eval-after-load

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

>> The change is not visible where it happens, namely at the (provide
>> 'edebug).
>
> That is WHEN the change happens.  Loading edebug is the trigger.
> I'm not sure what you mean by "where", here.  Do you mean the module
> whose data is changed?  Or do you mean the module whose functions
> make the change?  If you could say what you wanted to see and why,
> that might help me.

The code is called at (provide 'edebug), and there is no way to
a) expect this
b) see what code gets called
c) debug this.

>> > There is nothing objectionable about using the documented functional
>> > interface `def-edebug-spec'.
>
>> Straw man.  Nobody objected to its use.  What is objectional is that
>> its call happens at the (provide 'edebug) line without any visible
>> indication in edebug.el, and without any user-accessible variables or
>> hook that would allow for inspection and modification of the behavior.
>
> Don't all hooks work this way?

No.  All hooks get called by
(run-hooks 'some-hook)
or equivalent.  You see the place where it happens, you can debug it,
and you can check and/or change some-hook in order to control what
gets done.

> What do you mean by "visible"?  I'm sorry, but the rest of the
> paragraph is too vague to make any sense to me.  A call happening
> without user-accessible variables or a hook is like a cuckoo clock
> chiming without Pythagoras's theorem.

It is by now abundantly clear that you choose not to understand and
will discount anything one says in the way of explanation.

>> A user won't have cause to be surprised if he added eval-after-load
>> himself.  But expecting and tracking every such use that might be
>> hidden in Emacs' code base is a bit much.
>
> It's no more or less difficult that tracking down every place a hook
> is used.

Wrong.  Because one _sees_ the hook getting called in the code, and
the hook has a name, and its contents can be checked.

> eval-after-load is conceptually the same as add-hook.  Why is using
> e-a-l worse than using LaTeX-mode-hook, for example?

Because there is a
(run-hook 'LaTeX-mode-hook) in LaTeX-mode explicitly (or implicitly as
part of a define-major-mode or define-derived-mode).

Because you can check LaTeX-mode-hook.  Because the point of time
where it is called is well-defined and visible.

>> The reasons have been cited to you several times and it is in the
>> manual which also has been cited to you.
>  
> Resorts to hand waving abstractions have been made, but no descent
> to the concrete.

It is clear that you won't accept anything with a different conclusion
than what you want.

I am sorry I wasted my time in that manner.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Strange eval-after-load

[Richard Stallman]

      eval-after-load is conceptually the same as add-hook.

The point here is the difference between them.  If you've decided to
treat that difference as unimportant, then of course you don't see
why I prefer one to the other.

      Why is
    using e-a-l worse than using LaTeX-mode-hook,  for example?

The code in tex-mode.el explicitly runs LaTeX-mode-hook,
but it does not explicitly run the eval-after-load forms.

    I cannot conceive of any (real) problems which might be caused by

       (eval-after-load "edebug" '(def-edebug-spec c-point t))

I agree this does not cause any practical problem.
However, it is cleaner to use `declare'.

Also, I will move def-edebug-spec into subr.el, so that there
is no point in using eval-after-load here.

Re: Strange eval-after-load

[Alan Mackenzie]

Hi, Richard!

On Fri, Jul 07, 2006 at 12:14:34AM -0400, Richard Stallman wrote:
>       eval-after-load is conceptually the same as add-hook.

> The point here is the difference between them.  If you've decided to
> treat that difference as unimportant, then of course you don't see
> why I prefer one to the other.

>       Why is
>     using e-a-l worse than using LaTeX-mode-hook,  for example?

> The code in tex-mode.el explicitly runs LaTeX-mode-hook,
> but it does not explicitly run the eval-after-load forms.

>     I cannot conceive of any (real) problems which might be caused by
> 
>        (eval-after-load "edebug" '(def-edebug-spec c-point t))

> I agree this does not cause any practical problem.
> However, it is cleaner to use `declare'.

> Also, I will move def-edebug-spec into subr.el, so that there
> is no point in using eval-after-load here.

OK.  I'll change the CC Mode source files to call def-edebug-spec
directly.

Thanks!

-- 
Alan.

Re: Strange eval-after-load

[Richard Stallman]

    Btw, the original text I wrote for this tip was a bit different, it
    explicitly said that eval-after-load increases a coupling between the
    two packages, which is a maintenance burden:

What you wrote is true, but not specific.  Coupling between modules is
often necessary.  There are many kinds of coupling, and not all of
them are bad.  I replaced it with text that is more specific--it
explains why this kind of coupling is particularly bad.

Re: Strange eval-after-load

[Richard Stallman]

    To construe this form as "modifying the behaviour of another Lisp file
    (?edebug, presumably) in an invisible way" seems like a total perversion
    of reality to me.

I'm sorry you don't see it, but I don't see any further way to try to
explain.

Re: Strange eval-after-load

[Alan Mackenzie]

Hi, Richard!

On Wed, Jul 05, 2006 at 10:51:33AM -0400, Richard Stallman wrote:
>     To construe this form as "modifying the behaviour of another Lisp file
>     (?edebug, presumably) in an invisible way" seems like a total perversion
>     of reality to me.

> I'm sorry you don't see it, but I don't see any further way to try to
> explain.

OK.  I seem to be in a small minority on this point.  As I said
yesterday, I accept your decision as project maintainer and all-round good
guy.  At the same time, as a matter of self respect, I won't be actively
making changes in the source which seem bad to me.  I don't see there
should be any more problems on this score.

Let's finish this discussion - there are more important things to do.

-- 
Alan.

Re: Strange eval-after-load

[Richard Stallman]

    There is, and thanks to Thi for telling me about it.  However, this new
    `declare' feature in defmacro seems to be a bit ad-hoc.  Since it
    doesn't exist in older Emacsen, it's not suitable for packages like CC
    Mode, which will continue to need edebugging on these other (X)Emacsen.

It is not necessary for the CC Mode files installed in Emacs to work
on any platform other than the Emacs version they are installed in.
If you want to support XEmacs using eval-after-load, that is ok, but
please conditionalize the eval-after-load calls so that they don't get
used on Emacs.

As for old Emacs versions, they are not worth uglifying our sources for.

Re: Strange eval-after-load

[Richard Stallman]

    I don't really understand what the situation is over which control has
    to be got.  It is possible to to use eval-after-load badly, just as it
    is possible to use goto badly.

I want to make sure no additional bad uses are installed, and
meanwhile get rid of the ones that are already installed.

    Rather than banning eval-after-load, why not formulate when it is
    acceptable to use it, and put this advice into the Elisp manual?

Theoretically, there could be good ways to use it in Emacs,
but I do not know of any use which I would describe as good.