From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Re: debug declaration. Date: Wed, 30 Mar 2005 10:12:42 +0200 Message-ID: <87zmwlsgat.fsf@xs4all.nl> References: <87br9a8ijc.fsf@xs4all.nl> <87wtrwf0iq.fsf@xs4all.nl> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112170627 11626 80.91.229.2 (30 Mar 2005 08:17:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 30 Mar 2005 08:17:07 +0000 (UTC) Cc: "Richard M. Stallman" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 30 10:17:02 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DGYNi-0008D1-88 for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2005 10:16:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DGYeA-0004Qn-DL for ged-emacs-devel@m.gmane.org; Wed, 30 Mar 2005 03:33:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DGYao-0003QR-EW for emacs-devel@gnu.org; Wed, 30 Mar 2005 03:30:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DGYad-0003LZ-N4 for emacs-devel@gnu.org; Wed, 30 Mar 2005 03:30:17 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DGYac-0003Jf-39 for emacs-devel@gnu.org; Wed, 30 Mar 2005 03:30:14 -0500 Original-Received: from [194.109.24.31] (helo=smtp-vbr11.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DGYJi-0000BP-0k; Wed, 30 Mar 2005 03:12:48 -0500 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr11.xs4all.nl (8.12.11/8.12.11) with ESMTP id j2U8ChJU081398; Wed, 30 Mar 2005 10:12:43 +0200 (CEST) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1DGYJe-00016z-00; Wed, 30 Mar 2005 10:12:42 +0200 Original-To: Stefan Monnier In-Reply-To: (Stefan Monnier's message of "Fri, 25 Mar 2005 10:14:38 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 40 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:35347 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35347 Stefan Monnier 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.