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

[Aaron Ecay]

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