From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export Date: Mon, 22 Sep 2014 23:25:02 -0400 Message-ID: <87fvfjow6p.fsf@gmail.com> References: <87k34zqv9r.fsf@gmail.com> <87bnqbv27b.fsf@nicolasgoaziou.fr> 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]:49381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWGrD-00034k-Eb for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 23:33:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWGr3-0005CM-O9 for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 23:33:39 -0400 Received: from mail-qg0-x234.google.com ([2607:f8b0:400d:c04::234]:58180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWGr3-0005C4-Hg for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 23:33:29 -0400 Received: by mail-qg0-f52.google.com with SMTP id j5so2980789qga.25 for ; Mon, 22 Sep 2014 20:33:24 -0700 (PDT) In-Reply-To: <87bnqbv27b.fsf@nicolasgoaziou.fr> 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: Nicolas Goaziou , Org-mode Hi Nicolas, 2014ko irailak 19an, Nicolas Goaziou-ek idatzi zuen: >=20 > Certainly not a message, due to asynchronous export. Very good point. >=20 >> 2. Since this is a feature that many backends will want to use, should >> we introduce a new =E2=80=9Cabstract=E2=80=9D backend from which other b= ackends can >> inherit, which incorporates this feature, and others like it in the >> future? The idea would be similar to prog-mode in emacs, the major >> mode from which programming-language modes can derive. The >> alternative is adding the (macro . org-export-macro-warn) entry >> manually to all the relevant backends, and relying on future backend >> authors to do the same. >>=20 >> 3. Should this even be implemented as part of the backend=E2=80=99s >> translate-alist, or at a lower level? >=20 > Don't bother with export back-ends, they never get to see macros, which > are expanded very early in the export process. This explains, for > example, why there is no `macro' translator. Um...but the patch I sent works precisely by defining a macro translator, which does get called for any unexpanded (because undefined) macros. I guess you=E2=80=99re saying the code ought to block this at a lower/earlier= level. >=20 > You have two options. Either report an error, as you suggested, or > insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", =C3=A0 = la > "DEFINITION NOT FOUND." for footnote definitions. In any case, this > should happen in "org-macro.el", not in the export framework. I think error is better than obnoxious message, because it=E2=80=99s possib= le for the latter to slip through into a =E2=80=9Cproduction=E2=80=9D document= . (We ought to proofread our documents carefully, of course...but no one=E2=80=99s perf= ect). 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 barf = 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 autho= r, and error on any other undefined macro 2. add an optional =E2=80=9Cfinal=E2=80=9D arg to org-macro-replace-all, wh= ich 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 e= xpanding macros, and make sure no 'macro type objects are left WDYT? --=20 Aaron Ecay