Aaron may I trouble you to add a flag so that if such errors occur then the export fails?
>From my perspective, if the document doesn't "compile", then nothing should succeed. Compile includes export from my perspective. On Mon, Sep 22, 2014 at 10:25 PM, Aaron Ecay <aarone...@gmail.com> wrote: > Hi Nicolas, > > 2014ko irailak 19an, Nicolas Goaziou-ek idatzi zuen: >> >> Certainly not a message, due to asynchronous export. > > Very good point. > >> >>> 2. Since this is a feature that many backends will want to use, should >>> we introduce a new “abstract” backend from which other backends 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. >>> >>> 3. Should this even be implemented as part of the backend’s >>> translate-alist, or at a lower level? >> >> 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’re saying the code ought to block this at a lower/earlier level. > >> >> You have two options. Either report an error, as you suggested, or >> insert an obnoxious message in the output, e.g., "UNKNOWN MACRO", à 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’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). > > 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? > > -- > Aaron Ecay > -- Grant Rettke g...@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson
