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

[Grant Rettke]

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 <address@hidden> 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
address@hidden | 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