[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13813: 24.3.50; eval-and-compile in macro inhibits let-binding of va
From: |
David Engster |
Subject: |
bug#13813: 24.3.50; eval-and-compile in macro inhibits let-binding of variable |
Date: |
Mon, 25 Feb 2013 22:17:53 +0100 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.93 (gnu/linux) |
Stefan Monnier writes:
> OK, you got me, I admit it,
Ha! No one can escape the EIEIO testsuite!
> I changed recently eval-and-compile to be (in effect)
> eval-during-load-and-compile. I could turn it into a
> eval-during-eval-load-and-compile, but then your above test would run
> `mytestfun' twice (once with myflag=nil and then once with myflag=t)
> which I don't think would please everyone either.
Yep, my gut says that would create problems in EIEIO, too.
>> * Note the following:
>> - It works if you just 'setq' the 'myflag' variable
>
> But not if you (progn (setq myflag t) (mytestmacro)).
True. I didn't test that.
>> And yes, Stefan, this bug turned up in the EIEIO test suite. :-)
>
> Could you give some details, so we can better assess the best solution?
There is a flag called `eieio-error-unsupported-class-tags' which makes
`eieio-defclass' signal an error if a tag is unsupported. Since
`eieio-defclass' is the implementation of the `defclass' macro (wrapped
in `eval-and-comopile'), this flag has no effect if it is set in a
let-binding. To be specific, the test checks that this
(let ((eieio-error-unsupported-class-tags t))
(defclass class-error ()
((error-slot :initarg :error-slot
:badslottag 1))
"A class with a bad slot tag."))
is throwing an error.
> BTW, I think eval-and-compile should only be used to wrap definitions.
> Anything else is asking for trouble.
As I said: I can't wrap my head around that stuff. But the Emacs Lisp
manual specifically mentions this use case for `eval-and-compile'.
Out of curiosity I removed the `eval-and-compile' and everything seems
to work fine, which just adds to my confusion.
-David