eval-after-load confusion

eval-after-load confusion

[Eric Abrahamsen]

I have the following in a library that is required at startup:

;; (eval-after-load 'message
;;   (let ((ign-headers-list
;; 	 (split-string message-ignored-mail-headers
;; 		       "|"))
;; 	(our-val (concat gnorb-mail-header "\\")))
;;     (unless (member our-val ign-headers-list)
;;       (setq ign-headers-list
;; 	    `(,@(butlast ign-headers-list 1) ,our-val
;; 	      ,@(last ign-headers-list 1)))
;;       (setq message-ignored-mail-headers
;; 	    (mapconcat
;; 	     'identity ign-headers-list "|")))))

If I leave this block uncommented, I get a "void variable" error on
startup, referencing 'message-ignored-mail-headers.

I thought the whole point of `eval-after-load' was to avoid this: the
block should only be run *after* message.el is loaded, and
'message-ignored-mail-headers is defined. I've also tried with "message"
as a string, though that shouldn't matter.

Is it because it's referenced inside a `let' form? What am I not
understanding?!

emacs-version -> "24.3.1"

Thanks,
Eric

Re: eval-after-load confusion

[Nicolas Richard]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> ;; (eval-after-load 'message
> ;;   (let ((ign-headers-list
> ;; 	 (split-string message-ignored-mail-headers
> ;; 		       "|"))
> ;; 	(our-val (concat gnorb-mail-header "\\")))
> ;;     (unless (member our-val ign-headers-list)
> ;;       (setq ign-headers-list
> ;; 	    `(,@(butlast ign-headers-list 1) ,our-val
> ;; 	      ,@(last ign-headers-list 1)))
> ;;       (setq message-ignored-mail-headers
> ;; 	    (mapconcat
> ;; 	     'identity ign-headers-list "|")))))
>
> If I leave this block uncommented, I get a "void variable" error on
> startup, referencing 'message-ignored-mail-headers.

eval-after-load is a (normal) function, which means that each of its
argument is evaluated first, then eval-after-load is called with those
values. Adding a single quote before the (let ...) form should help.

-- 
Nico.

Re: eval-after-load confusion

[Eric Abrahamsen]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>> ;; (eval-after-load 'message
>> ;;   (let ((ign-headers-list
>> ;; 	 (split-string message-ignored-mail-headers
>> ;; 		       "|"))
>> ;; 	(our-val (concat gnorb-mail-header "\\")))
>> ;;     (unless (member our-val ign-headers-list)
>> ;;       (setq ign-headers-list
>> ;; 	    `(,@(butlast ign-headers-list 1) ,our-val
>> ;; 	      ,@(last ign-headers-list 1)))
>> ;;       (setq message-ignored-mail-headers
>> ;; 	    (mapconcat
>> ;; 	     'identity ign-headers-list "|")))))
>>
>> If I leave this block uncommented, I get a "void variable" error on
>> startup, referencing 'message-ignored-mail-headers.
>
> eval-after-load is a (normal) function, which means that each of its
> argument is evaluated first, then eval-after-load is called with those
> values. Adding a single quote before the (let ...) form should help.

Gah, I knew it was something stupid, thank you. And apologies for
wasting the internet...

Re: eval-after-load confusion

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

() Eric Abrahamsen <eric@ericabrahamsen.net>
() Wed, 30 Apr 2014 16:36:50 +0800

   ;; (eval-after-load 'message
   ;;   (let ...)

   What am I not understanding?!

If you ‘C-h f eval-after-load’, you will see the template:

 (eval-after-load FILE FORM)

and can match symbol ‘eval-after-load’ to the first element
of the same name, the expression

 'message

to the second element FILE, and the expression

 (let ...)

to the third element FORM.  So order seems to be correct.  No easy
answers in this life!  Trundle on!  Next step, do the "types" match?
The first element is for dispatch so we ignore it.  The second one,
FILE, seems to be correct per this fragment:

 Alternatively, FILE can be a feature (i.e. a symbol),

and the expression does indeed evaluate to a symbol, i.e.,

 (quote SYMBOL) => SYMBOL

That leaves the third element, FORM.  It appears the ‘(let ...)’ does
not evaluate to a proper FORM.  Hmm...

"But ttn, why all this "evaluate to" noise?  Why didn't you just say
that ‘(quote message)’ *is* a symbol?  Same for "does not evaluate to"
for the third arg!  What, are you getting old and crufty?!"

Well, yes!  Everything has its time.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: eval-after-load confusion

[Eric Abrahamsen]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> () Eric Abrahamsen <eric@ericabrahamsen.net>
> () Wed, 30 Apr 2014 16:36:50 +0800
>
>    ;; (eval-after-load 'message
>    ;;   (let ...)
>
>    What am I not understanding?!
>
> If you ‘C-h f eval-after-load’, you will see the template:
>
>  (eval-after-load FILE FORM)
>
> and can match symbol ‘eval-after-load’ to the first element
> of the same name, the expression
>
>  'message
>
> to the second element FILE, and the expression
>
>  (let ...)
>
> to the third element FORM.  So order seems to be correct.  No easy
> answers in this life!  Trundle on!  Next step, do the "types" match?
> The first element is for dispatch so we ignore it.  The second one,
> FILE, seems to be correct per this fragment:
>
>  Alternatively, FILE can be a feature (i.e. a symbol),
>
> and the expression does indeed evaluate to a symbol, i.e.,
>
>  (quote SYMBOL) => SYMBOL
>
> That leaves the third element, FORM.  It appears the ‘(let ...)’ does
> not evaluate to a proper FORM.  Hmm...
>
> "But ttn, why all this "evaluate to" noise?  Why didn't you just say
> that ‘(quote message)’ *is* a symbol?  Same for "does not evaluate to"
> for the third arg!  What, are you getting old and crufty?!"
>
> Well, yes!  Everything has its time.

If a fellow's got to be schooled (in something he already should have
known), one might hope for worse than to be schooled by Thien-Thi
Nguyen. If only the question had been more worthy of the answer!

Re: eval-after-load confusion

[Stefan Monnier]

> I thought the whole point of `eval-after-load' was to avoid this: the

In 24.4, we have finally introduced the with-eval-after-load macro,
which works the way you expected eval-after-load to work.


        Stefan

Re: eval-after-load confusion

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I thought the whole point of `eval-after-load' was to avoid this: the
>
> In 24.4, we have finally introduced the with-eval-after-load macro,
> which works the way you expected eval-after-load to work.

Ooh, further idiot-proofing! Good news for all us... ahem.