[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}

From: Nicolas Goaziou
Subject: Re: [O] #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}}
Date: Wed, 19 Mar 2014 16:02:21 +0100


Bastien <address@hidden> writes:

> Luke Crook <address@hidden> 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.


Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]