From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: [RFC] [PATCH] Warn about unexpanded macros on export
Date: Tue, 23 Sep 2014 22:24:01 +0200 [thread overview]
Message-ID: <87lhpaf5lq.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87fvfjow6p.fsf@gmail.com> (Aaron Ecay's message of "Mon, 22 Sep 2014 23:25:02 -0400")
Hello,
Aaron Ecay <aaronecay@gmail.com> writes:
> Um...but the patch I sent works precisely by defining a macro translator,
> which does get called for any unexpanded (because undefined) macros.
Macros are not expected to be seen by export back-ends. It happens when
a macro is undefined, but this is not a reliable feature.
> I guess you’re saying the code ought to block this at a lower/earlier
> level.
Yes, at "org-macro.el" level.
> 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).
Sounds good.
> 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?
I have no strong opinion here but I lean towards option 2 as the error
stays internal to "org-macro.el" and is only triggered with an optional
argument. It also doesn't require to hardcode special macro names.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-09-23 20:23 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
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 [this message]
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=87lhpaf5lq.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
/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).