Hello, Aaron Ecay <aarone...@gmail.com> 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. Regards, -- Nicolas Goaziou
