From: Grant Rettke <gcr@wisdomandwonder.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export
Date: Tue, 23 Sep 2014 11:59:49 -0500 [thread overview]
Message-ID: <CAAjq1mcgj+=Fd=M6df9LTVLD=h8OaL8jmKaOk4TLZi69M0_khA@mail.gmail.com> (raw)
In-Reply-To: <87fvfjow6p.fsf@gmail.com>
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 <aaronecay@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
gcr@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
next prev parent reply other threads:[~2014-09-23 17:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 19:12 [RFC] [PATCH] Warn about unexpanded macros on export Aaron Ecay
2014-09-19 19:29 ` Nicolas Goaziou
2014-09-23 3:25 ` Aaron Ecay
2014-09-23 16:59 ` Grant Rettke [this message]
2014-09-23 17:18 ` Aaron Ecay
2014-09-23 17:29 ` Jacob Gerlach
2014-09-23 21:10 ` Nicolas Goaziou
2014-09-23 20:24 ` Nicolas Goaziou
2014-09-28 3:53 ` Aaron Ecay
2014-09-28 6:59 ` Nicolas Goaziou
2014-10-12 15:48 ` Aaron Ecay
2014-09-23 20:26 ` Rasmus
2014-09-28 4:00 ` Aaron Ecay
2014-09-28 7:03 ` Nicolas Goaziou
2014-10-12 15:49 ` Aaron Ecay
2014-10-12 17:19 ` Nicolas Goaziou
2015-03-12 2:55 ` Jacob Gerlach
2015-03-15 8:44 ` Nicolas Goaziou
2015-03-17 16:20 ` Jacob Gerlach
2015-03-17 22:38 ` Nicolas Goaziou
2015-03-18 20:25 ` Jacob Gerlach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAjq1mcgj+=Fd=M6df9LTVLD=h8OaL8jmKaOk4TLZi69M0_khA@mail.gmail.com' \
--to=gcr@wisdomandwonder.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).