GNU bug report logs - #10946
24.0.94; eval-after-load incompatible change

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10946 in the body.
You can then email your comments to 10946 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; eval-after-load incompatible change
Date: Mon, 05 Mar 2012 18:57:23 +0800

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

Message #8 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo <sdl.web <at> gmail.com>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Mon, 05 Mar 2012 10:05:39 -0500

> 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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Tue, 06 Mar 2012 00:16:17 +0800

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

Message #14 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo <sdl.web <at> gmail.com>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Mon, 05 Mar 2012 16:33:33 -0500

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

Message #17 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Tue, 06 Mar 2012 23:29:40 +0800

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

Message #20 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo <sdl.web <at> gmail.com>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Tue, 06 Mar 2012 15:57:39 -0500

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

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Wed, 07 Mar 2012 07:49:37 +0800

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

Message #26 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo <sdl.web <at> gmail.com>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Wed, 07 Mar 2012 12:06:13 -0500

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

Message #29 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Leo <sdl.web <at> gmail.com>
Cc: 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Wed, 07 Mar 2012 15:28:57 -0500

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

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Thu, 08 Mar 2012 11:21:19 +0800

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

Message #35 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Leo <sdl.web <at> gmail.com>, 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Fri, 09 Mar 2012 13:14:54 -0500

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

Message #38 received at 10946 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Leo <sdl.web <at> gmail.com>, 10946 <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Fri, 09 Mar 2012 21:40:39 -0500

> 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

Message #43 received at 10946-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 10946-done <at> debbugs.gnu.org
Subject: Re: bug#10946: 24.0.94; eval-after-load incompatible change
Date: Thu, 15 Mar 2012 21:29:06 -0400

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.