Re: debug declaration.

[Lute Kamstra]

Stefan Monnier <address@hidden> writes:

[...]

>>> Another option is to evaluate those arguments before you plug them
>>> in the body of your major mode function, so they're only evaluated
>>> once, when the major mode is defined, thus reproducing the
>>> "pre-macro" behavior.
>
>> Considering backward compatibility, that's probably the right thing
>> to do.
>
> It also moves more work to macro-expansion time which is good.  But
> beware, it can also break backward compatibility, because now
> evaluation can take place at byte-compile time.
>
> OTOH it's closer to what I meant by "turn it into a macro" (in the
> comment that prompted you to look into this whole thing).  Ideally
> define-generic-mode should (just like define-derived-mode does)
> generate stand-alone code which does not require generic.el.

I considered this when I started to work on generic.el, but moving all
the code into define-generic-mode would lead to some code duplication.
Especially generic-mode-set-comments is a bit long.

The body of generic-mode-internal could be moved to
define-generic-mode as it is short.  This would also make the code
clearer, IMO.  If define-generic-mode would then evaluate its argument
COMMENT-LIST during macro expansion, it could generate stand-alone
code if COMMENT-LIST is nil.

Maybe it's a good thing if define-generic-mode evaluated all it's
arguments during macro expansion.  For all the examples in
generic-x.el at least, it didn't matter if the arguments were
evaluated during compilation or during the loading of generic-x.elc.
Actually, I made all the arguments of calls to define-generic-mode
either constant or I eval-when-compile'd them to speed up the loading
of generic-x.elc.

Lute.