[Top][All Lists]

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

Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export

From: Nicolas Goaziou
Subject: Re: [O] [RFC] [PATCH] Warn about unexpanded macros on export
Date: Tue, 23 Sep 2014 22:24:01 +0200


Aaron Ecay <address@hidden> 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’re saying the code ought to block this at a lower/earlier
> level.

Yes, at "org-macro.el" level.

> I think error is better than obnoxious message, because it’s possible
> for the latter to slip through into a “production” document.  (We ought
> to proofread our documents carefully, of course...but no one’s
> perfect).

Sounds good.

> One issue is that the exporter does two macro expansion passes – one
> for garden-variety macros, and the second for author, date, email, and
> title.  So, we can’t 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 “blessed” macros like author, and error
>    on any other undefined macro
> 2. add an optional “final” arg to org-macro-replace-all, which will
>    activate the undefined checking only if non-nil, and pass this flag
>    in the exporter’s second (and last) call to org-macro-replace-all
> 3. in ‘org-export-as’, manually walk the parse tree after expanding
>    macros, and make sure no 'macro type objects are left

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.


Nicolas Goaziou

reply via email to

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