From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export Date: Tue, 23 Sep 2014 22:24:01 +0200 Message-ID: <87lhpaf5lq.fsf@nicolasgoaziou.fr> References: <87k34zqv9r.fsf@gmail.com> <87bnqbv27b.fsf@nicolasgoaziou.fr> <87fvfjow6p.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWWcY-0003H8-Ar for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 16:23:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWWcO-0006gD-6c for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 16:23:34 -0400 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:55857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWWcO-0006dv-0C for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 16:23:24 -0400 Received: from mfilter36-d.gandi.net (mfilter36-d.gandi.net [217.70.178.167]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id E9457A80AC for ; Tue, 23 Sep 2014 22:23:17 +0200 (CEST) Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter36-d.gandi.net (mfilter36-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id uBjKuh9biIeK for ; Tue, 23 Sep 2014 22:23:16 +0200 (CEST) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 78E6EA8092 for ; Tue, 23 Sep 2014 22:23:16 +0200 (CEST) In-Reply-To: <87fvfjow6p.fsf@gmail.com> (Aaron Ecay's message of "Mon, 22 Sep 2014 23:25:02 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org-mode Hello, Aaron Ecay writes: > Um...but the patch I sent works precisely by defining a macro translator, > which does get called for any unexpanded (because undefined) macros. Macros are not expected to be seen by export back-ends. It happens when a macro is undefined, but this is not a reliable feature. > I guess you=E2=80=99re saying the code ought to block this at a lower/ear= lier > level. Yes, at "org-macro.el" level. > I think error is better than obnoxious message, because it=E2=80=99s poss= ible > for the latter to slip through into a =E2=80=9Cproduction=E2=80=9D docume= nt. (We ought > to proofread our documents carefully, of course...but no one=E2=80=99s > perfect). Sounds good. > One issue is that the exporter does two macro expansion passes =E2=80=93 = one > for garden-variety macros, and the second for author, date, email, and > title. So, we can=E2=80=99t make the macro expansion unconditionally bar= f on > undefined macros (since for the first pass e.g. author is undefined). > I see three options: > 1. explicitly whitelist the few =E2=80=9Cblessed=E2=80=9D macros like aut= hor, and error > on any other undefined macro > 2. add an optional =E2=80=9Cfinal=E2=80=9D arg to org-macro-replace-all, = which will > activate the undefined checking only if non-nil, and pass this flag > in the exporter=E2=80=99s second (and last) call to org-macro-replace-= all > 3. in =E2=80=98org-export-as=E2=80=99, manually walk the parse tree after= expanding > macros, and make sure no 'macro type objects are left > > WDYT? I have no strong opinion here but I lean towards option 2 as the error stays internal to "org-macro.el" and is only triggered with an optional argument. It also doesn't require to hardcode special macro names. Regards, --=20 Nicolas Goaziou