[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debug declaration.

From: Lute Kamstra
Subject: Re: debug declaration.
Date: Wed, 30 Mar 2005 10:12:42 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]