* bug#10946: 24.0.94; eval-after-load incompatible change
@ 2012-03-05 10:57 Leo
2012-03-05 15:05 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Leo @ 2012-03-05 10:57 UTC (permalink / raw)
To: 10946
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-05 10:57 bug#10946: 24.0.94; eval-after-load incompatible change Leo
@ 2012-03-05 15:05 ` Stefan Monnier
2012-03-05 16:16 ` Leo
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-03-05 15:05 UTC (permalink / raw)
To: Leo; +Cc: 10946
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-05 15:05 ` Stefan Monnier
@ 2012-03-05 16:16 ` Leo
2012-03-05 21:33 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Leo @ 2012-03-05 16:16 UTC (permalink / raw)
To: 10946
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-05 16:16 ` Leo
@ 2012-03-05 21:33 ` Stefan Monnier
2012-03-06 15:29 ` Leo
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-03-05 21:33 UTC (permalink / raw)
To: Leo; +Cc: 10946
>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-05 21:33 ` Stefan Monnier
@ 2012-03-06 15:29 ` Leo
2012-03-06 20:57 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Leo @ 2012-03-06 15:29 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 10946
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-06 15:29 ` Leo
@ 2012-03-06 20:57 ` Stefan Monnier
2012-03-06 23:49 ` Leo
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-03-06 20:57 UTC (permalink / raw)
To: Leo; +Cc: 10946
>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-06 20:57 ` Stefan Monnier
@ 2012-03-06 23:49 ` Leo
2012-03-07 17:06 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Leo @ 2012-03-06 23:49 UTC (permalink / raw)
To: 10946
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-06 23:49 ` Leo
@ 2012-03-07 17:06 ` Stefan Monnier
2012-03-07 20:28 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-03-07 17:06 UTC (permalink / raw)
To: Leo; +Cc: 10946
>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-07 17:06 ` Stefan Monnier
@ 2012-03-07 20:28 ` Stefan Monnier
2012-03-08 3:21 ` Leo
2012-03-09 18:14 ` Glenn Morris
0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2012-03-07 20:28 UTC (permalink / raw)
To: Leo; +Cc: 10946
>>> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-07 20:28 ` Stefan Monnier
@ 2012-03-08 3:21 ` Leo
2012-03-09 18:14 ` Glenn Morris
1 sibling, 0 replies; 13+ messages in thread
From: Leo @ 2012-03-08 3:21 UTC (permalink / raw)
To: 10946
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-07 20:28 ` Stefan Monnier
2012-03-08 3:21 ` Leo
@ 2012-03-09 18:14 ` Glenn Morris
2012-03-10 2:40 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2012-03-09 18:14 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Leo, 10946
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))
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-09 18:14 ` Glenn Morris
@ 2012-03-10 2:40 ` Stefan Monnier
2012-03-16 1:29 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2012-03-10 2:40 UTC (permalink / raw)
To: Glenn Morris; +Cc: Leo, 10946
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#10946: 24.0.94; eval-after-load incompatible change
2012-03-10 2:40 ` Stefan Monnier
@ 2012-03-16 1:29 ` Glenn Morris
0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2012-03-16 1:29 UTC (permalink / raw)
To: 10946-done
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-03-16 1:29 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-05 10:57 bug#10946: 24.0.94; eval-after-load incompatible change Leo
2012-03-05 15:05 ` Stefan Monnier
2012-03-05 16:16 ` Leo
2012-03-05 21:33 ` Stefan Monnier
2012-03-06 15:29 ` Leo
2012-03-06 20:57 ` Stefan Monnier
2012-03-06 23:49 ` Leo
2012-03-07 17:06 ` Stefan Monnier
2012-03-07 20:28 ` Stefan Monnier
2012-03-08 3:21 ` Leo
2012-03-09 18:14 ` Glenn Morris
2012-03-10 2:40 ` Stefan Monnier
2012-03-16 1:29 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).