[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
`eval-after-load' broken for symbols?
From: |
Daniel Brockman |
Subject: |
`eval-after-load' broken for symbols? |
Date: |
Tue, 1 Nov 2011 16:17:58 +0100 |
The ubiquitous function `eval-after-load` seems to be broken.
The following code causes the message to be displayed:
(require 'dired)
(eval-after-load "dired"
'(message "String works!"))
But the following code doesn’t:
(require 'dired)
(eval-after-load 'dired
'(message "Symbol works!"))
From the docstring of `eval-after-load`:
Arrange that if FILE is loaded, FORM will be run immediately afterwards.
If FILE is already loaded, evaluate FORM right now.
[…]
Alternatively, FILE can be a feature (i.e. a symbol), in which case FORM
is evaluated at the end of any file that `provide's this feature.
I guess that _could_ be trying to say that "when FILE is a symbol"
it *shouldn’t* "evaluate FORM right now", but if you look at the source
code for `eval-after-load` it doesn’t actually avoid evaluating FORM,
it just happens for an unrelated reason to wrap it in a false conditional:
(when (symbolp regexp-or-feature)
;; For features, the after-load-alist elements get run when `provide' is
;; called rather than at the end of the file. So add an indirection to
;; make sure that `form' is really run "after-load" in case the provide
;; call happens early.
(setq form
`(when load-file-name
…
So, is this actually a bug? The behavior sure seems broken anyway.
--
Daniel Brockman, partner & developer
Go Interactive <http://gointeractive.se>
Twitter: http://twitter.com/dbrock
Telephone: +46706880739
- `eval-after-load' broken for symbols?,
Daniel Brockman <=