bug#10946: 24.0.94; eval-after-load incompatible change

bug#10946: 24.0.94; eval-after-load incompatible change

[Leo]

I recently upgraded to emacs 24 and I noticed some after-load forms not
running any more.

In emacs 23, when provide is invoked, it checks after-load-alist and
runs the matching form.

In emacs 24, the after-load form is guarded by load-file-name and thus
`provide' alone cannot trigger eval'ing after-load form.

One of my after-load forms is related to some code defined via pymacs,
which has no load-file-name. This incompatible change breaks all such
forms related to pymacs.

I don't know how best to fix this.

Leo

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

> One of my after-load forms is related to some code defined via pymacs,
> which has no load-file-name.

Can you provide some details about how/why there's no load-file-name
(which I guess just means it's nil).


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Leo]

On 2012-03-05 23:05 +0800, Stefan Monnier wrote:
> Can you provide some details about how/why there's no load-file-name
> (which I guess just means it's nil).

See: https://github.com/pinard/Pymacs

`pymacs-load' loads python module and creates elisp functions that call
those python functions.

(defun pymacs-load (module &optional prefix noerror)
  (interactive
   (let* ((module (read-string "Python module? "))
          (default (concat (car (last (split-string module "\\."))) "-"))
          (prefix (read-string (format "Prefix? [%s] " default)
                               nil nil default)))
     (list module prefix)))
  (message "Pymacs loading %s..." module)
  (let ((lisp-code (pymacs-call "pymacs_load_helper" module prefix)))
    (cond (lisp-code (let ((result (eval lisp-code)))
                       (message "Pymacs loading %s...done" module)
                       result))
          (noerror (message "Pymacs loading %s...failed" module) nil)
          (t (pymacs-report-error "Pymacs loading %s...failed" module)))))

It uses eval so no load-file-name is defined, i.e. if lisp-code contains
a form (provide 'whatever), it no longer eval the matching form in
after-load-alist.

Leo

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

>> Can you provide some details about how/why there's no load-file-name
>> (which I guess just means it's nil).

> See: https://github.com/pinard/Pymacs

> `pymacs-load' loads python module and creates elisp functions that call
> those python functions.

> (defun pymacs-load (module &optional prefix noerror)
>   (interactive
>    (let* ((module (read-string "Python module? "))
>           (default (concat (car (last (split-string module "\\."))) "-"))
>           (prefix (read-string (format "Prefix? [%s] " default)
>                                nil nil default)))
>      (list module prefix)))
>   (message "Pymacs loading %s..." module)
>   (let ((lisp-code (pymacs-call "pymacs_load_helper" module prefix)))
>     (cond (lisp-code (let ((result (eval lisp-code)))
>                        (message "Pymacs loading %s...done" module)
>                        result))
>           (noerror (message "Pymacs loading %s...failed" module) nil)
>           (t (pymacs-report-error "Pymacs loading %s...failed" module)))))

> It uses eval so no load-file-name is defined, i.e. if lisp-code contains
> a form (provide 'whatever), it no longer eval the matching form in
> after-load-alist.

Wouldn't a better fix be to make Pymacs set load-file-name, then?


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Leo]

On 2012-03-06 05:33 +0800, Stefan Monnier wrote:
> Wouldn't a better fix be to make Pymacs set load-file-name, then?
>
>
>         Stefan

Even if it worked, it'd be worse because it means getting rid of
(eval-after-load 'feature ...), which is something I use exclusively. I
avoid strings as much as I can because they lead to ugly entries like
"\\(\\`\\|/\\)sendmail\\(\\.elc\\|\\.el\\)?\\(\\.gz\\)?\\'" in
after-load-alist.

The incompatible change is likely to break users' configuration. Is
there any benefit introducing this change? Does it outweigh the
inconvenience?

Leo

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

>> Wouldn't a better fix be to make Pymacs set load-file-name, then?
> Even if it worked, it'd be worse because it means getting rid of
> (eval-after-load 'feature ...),

I don't understand why it should have such a consequence.


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Leo]

On 2012-03-07 04:57 +0800, Stefan Monnier wrote:
> I don't understand why it should have such a consequence.

Because now you have to worry about load-file-name, which means
(eval-after-load 'feature ... ) does nothing unless the file provided
that feature is loaded. i.e. it is almost the same as (eval-after-load
"file" ...).

Leo

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

>> I don't understand why it should have such a consequence.
> Because now you have to worry about load-file-name, which means
> (eval-after-load 'feature ... ) does nothing unless the file provided
> that feature is loaded. i.e. it is almost the same as (eval-after-load
> "file" ...).

I didn't mean to say that provide should run the after-load thingies
when load-file-name is nil.  I meant to say that in your case, this
would only be a workaround, whereas the real fix should be to setup
load-file-name appropriately (tho it's only a guess on my part, since
I don't fully understand what's going on).


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

>>> I don't understand why it should have such a consequence.
>> Because now you have to worry about load-file-name, which means
>> (eval-after-load 'feature ... ) does nothing unless the file provided
>> that feature is loaded. i.e. it is almost the same as (eval-after-load
>> "file" ...).

> I didn't mean to say that provide should run the after-load thingies
                                             ^^^
                                             not

> when load-file-name is nil.

Sorry about this typo.  But note that after thinking some more about it,
I noticed that it's called "eval-after-LOAD", so it makes sense that it
should only work when LOADing a file.


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Leo]

On 2012-03-08 04:28 +0800, Stefan Monnier wrote:
> Sorry about this typo.  But note that after thinking some more about it,
> I noticed that it's called "eval-after-LOAD", so it makes sense that it
> should only work when LOADing a file.

Sure, but eval-after-load covered both load and provide before. So this
is an important incompatible change. eval-after-load is advertised for
use in user's personal setup after all.

I wonder if something for provide could be added. `provide' already
checks after-load-alist (though the code now does nothing), how about
give it a dedicated list to check such as post-provide-hook and use the
standard hook facility?

Leo

bug#10946: 24.0.94; eval-after-load incompatible change

[Glenn Morris]

Stefan Monnier wrote:

> But note that after thinking some more about it, I noticed that it's
> called "eval-after-LOAD", so it makes sense that it should only work
> when LOADing a file.

Yes; but the doc in Emacs 23.4 says:

  Alternatively, FILE can be a feature (i.e. a symbol), in which case
  FORM is evaluated whenever that feature is `provide'd.

without explicitly saying "`provide'd from a file".

So IMO there should at least be a NEWS entry about this.

Isn't it possible to get the old behaviour back by changing the thing
that gets added to after-load-alist from:

(when load-file-name
   ...stuff...)

to

(if load-file-name
   ...stuff...
   ;; Not being provided from a file, run form right now.
   (form))

bug#10946: 24.0.94; eval-after-load incompatible change

[Stefan Monnier]

> So IMO there should at least be a NEWS entry about this.

Indeed, please add one.

> Isn't it possible to get the old behaviour back by changing the thing
> that gets added to after-load-alist from:

> (when load-file-name
>    ...stuff...)

> to

> (if load-file-name
>    ...stuff...
>    ;; Not being provided from a file, run form right now.
>    (form))

Yes, please do make this change, maybe with a warning about it
being discouraged.


        Stefan

bug#10946: 24.0.94; eval-after-load incompatible change

[Glenn Morris]

Version: 24.0.95

>> Isn't it possible to get the old behaviour back by changing the thing
>> that gets added to after-load-alist from:
>
>> (when load-file-name
>>    ...stuff...)
>
>> to
>
>> (if load-file-name
>>    ...stuff...
>>    ;; Not being provided from a file, run form right now.
>>    (form))

Implemented.