From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Luke Crook <luke@balooga.com>
Subject: Re: #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Date: Wed, 19 Mar 2014 16:02:21 +0100 [thread overview]
Message-ID: <87bnx2cjuq.fsf@gmail.com> (raw)
In-Reply-To: <87ppljck4w.fsf@bzg.ath.cx> (Bastien's message of "Tue, 18 Mar 2014 21:43:59 +0100")
Hello,
Bastien <bzg@gnu.org> writes:
> Luke Crook <luke@balooga.com> writes:
>
>> It would be great if org-mode added support for substitution to the #+
>> fields.
>
> Nicolas, what do you think?
In the current model, macros are considered part of Org syntax, like,
e.g., text markup. One advantage is that they can be parsed, so you can
get information about them with tools like `org-element-context'.
Though,, the obvious limitation is that they can only exist wherever Org
syntax is defined. In particular, you wouldn't (at least, I hope) expect
bold text in a LATEX keyword (or an example block...) to be recognized.
There is no macro here either, and macros behaviour is consistent with
other Org syntax.
It wasn't always the case. Before Org 8.0, as already written on this
ML, macros were, in some sense, more powerful as you could write one
almost anywhere (even though "almost" was hard to define and explain).
The manual also specified that they could be used to build complex
constructs. I changed the model.
Indeed, since Babel was introduced in Org, macros have been, at best, an
awkward way to hack an Org document (e.g., definition are only one line
long, they are hard to edit). Nowadays, Babel is really the way to go
for this task: you can use the language of your choice, definitions are
easily editable, and so on. Thus, it is acceptable to limit a bit macros
as no user is deprived from total control over its documents. In that
scheme, macros are still useful in the most simple cases, e.g., as small
placeholders in the middle of the document, so they are still
implemented, in a limited and somewhat protected environment.
I think it somehow strikes a balance between ease of use and power, as
both needs are covered. I understand that it is tempting to merge the
two concepts, and it is partly possible since macros can contain Babel
code themselves, but I strongly believe that these tools must focus on
their own niche. Or, to put it differently, I don't think that macros
should overlap too much with Babel.
Here, the OP wants to build conditional LaTeX code within the Org
document. This is far beyond macros' scope. I suggest to rely on Babel
code for the task, or even a filter, instead. In any case, there's no
need to extend macros past their current limitation.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2014-03-19 15:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 1:14 #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Luke Crook
2014-03-18 15:22 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Bastien
2014-03-18 17:14 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Luke Crook
2014-03-18 20:33 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Luke Crook
2014-03-18 20:43 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Bastien
2014-03-19 15:02 ` Nicolas Goaziou [this message]
2014-03-19 15:35 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Bastien
2014-03-19 16:00 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Nicolas Goaziou
2014-03-19 16:10 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Bastien
2014-03-19 21:23 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Nicolas Goaziou
2014-03-21 9:04 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Bastien
2014-03-19 8:34 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Eric S Fraga
2014-03-19 10:30 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Rasmus
2014-03-19 17:03 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Luke Crook
2014-03-19 23:25 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Rasmus
2014-03-19 16:51 ` #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Luke Crook
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=87bnx2cjuq.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=luke@balooga.com \
/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).