From: Aaron Ecay <aaronecay@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>,
Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export
Date: Mon, 22 Sep 2014 23:25:02 -0400 [thread overview]
Message-ID: <87fvfjow6p.fsf@gmail.com> (raw)
In-Reply-To: <87bnqbv27b.fsf@nicolasgoaziou.fr>
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
next prev parent reply other threads:[~2014-09-23 3:33 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 [this message]
2014-09-23 16:59 ` Grant Rettke
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=87fvfjow6p.fsf@gmail.com \
--to=aaronecay@gmail.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).