Hi Nicolas, Thanks for the feedback. 2014ko irailak 23an, Nicolas Goaziou-ek idatzi zuen: > > 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’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 >> >> 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. Attached is a revised patch. WDYT?