do-after-load-evaluation

do-after-load-evaluation

[Noah Friedman]

The following change:

    2006-05-24  Alan Mackenzie  <acm@muc.de>

            * lread.c (Vafter_load_alist): doc-string: state that an element
            now has a regexp to match file names, not a file name as such.
  
breaks backward compatibility because now the after-load forms for "foo"
will be evaluated when "foobar" is loaded.

This is not backward compatible and it breaks things in a bad way, because
lots of packages have a common prefix, and it's not really possible to have
the same alist values for all versions of emacs.

If there were some new syntax for regexp members, e.g.

      ((:re "regexp")  forms...)

then an assoc in older versions of emacs won't match and the new syntax
won't confuse them.

So I propose making that change.


Besides that, the existing implementation looks only halfway finished to
me.  Why does Fprovide still use the old hardcoded Fassq+Fprogn evaluation
method?  It should call do-after-load-evaluation too and that function
should do the right thing for symbols.

Re: do-after-load-evaluation

[Romain Francoise]

Noah Friedman <friedman@splode.com> writes:

> The following change:

>     2006-05-24  Alan Mackenzie  <acm@muc.de>

>             * lread.c (Vafter_load_alist): doc-string: state that an element
>             now has a regexp to match file names, not a file name as such.
>
> breaks backward compatibility because now the after-load forms for "foo"
> will be evaluated when "foobar" is loaded.

You should use `eval-after-load' instead of adding to `after-load-alist'
directly; it builds the following regexp for "foo":

    "\\(\\`\\|/\\)foo\\(\\.elc\\|\\.el\\)?\\(\\.gz\\)?\\'"

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: do-after-load-evaluation

[David Kastrup]

Romain Francoise <romain@orebokech.com> writes:

> Noah Friedman <friedman@splode.com> writes:
>
>> The following change:
>
>>     2006-05-24  Alan Mackenzie  <acm@muc.de>
>
>>             * lread.c (Vafter_load_alist): doc-string: state that an element
>>             now has a regexp to match file names, not a file name as such.
>>
>> breaks backward compatibility because now the after-load forms for "foo"
>> will be evaluated when "foobar" is loaded.
>
> You should use `eval-after-load' instead of adding to `after-load-alist'
> directly; it builds the following regexp for "foo":
>
>     "\\(\\`\\|/\\)foo\\(\\.elc\\|\\.el\\)?\\(\\.gz\\)?\\'"

Any reason this is not
"\\(\\`\\|/\\)foo\\(\\.elc?\\)?\\(\\.gz\\)?\\'"
instead (should perform better)?  And is there a reason that .elc? is
optional?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: do-after-load-evaluation

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

> Any reason this is not "\\(\\`\\|/\\)foo\\(\\.elc?\\)?\\(\\.gz\\)?\\'"
> instead (should perform better)?

The regexp is built from `load-suffixes' in a place where we can't use
regexp-opt, so it's a simple mapconcat...  I'm not sure if performance
is an important factor in this context, anyway.

> And is there a reason that .elc? is optional?

I don't know about that... it's probably just to make the code do the
same thing as it did before the change.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: do-after-load-evaluation

[David Kastrup]

Romain Francoise <romain@orebokech.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Any reason this is not "\\(\\`\\|/\\)foo\\(\\.elc?\\)?\\(\\.gz\\)?\\'"
>> instead (should perform better)?
>
> The regexp is built from `load-suffixes' in a place where we can't use
> regexp-opt, so it's a simple mapconcat...  I'm not sure if performance
> is an important factor in this context, anyway.
>
>> And is there a reason that .elc? is optional?
>
> I don't know about that... it's probably just to make the code do the
> same thing as it did before the change.

Probably to catch (load "foo").  Ok.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum