Stefan Monnier <[EMAIL PROTECTED]> 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. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
