From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: #+LATEX_HEADER:\newcommand{\orgtitle}{{{{TITLE}}}} Date: Wed, 19 Mar 2014 16:02:21 +0100 Message-ID: <87bnx2cjuq.fsf@gmail.com> References: <87y507fs5b.fsf@bzg.ath.cx> <87ppljck4w.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQI0G-0001Z2-Cg for emacs-orgmode@gnu.org; Wed, 19 Mar 2014 11:02:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQI0B-0006fE-KO for emacs-orgmode@gnu.org; Wed, 19 Mar 2014 11:02:00 -0400 In-Reply-To: <87ppljck4w.fsf@bzg.ath.cx> (Bastien's message of "Tue, 18 Mar 2014 21:43:59 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org, Luke Crook Hello, Bastien writes: > Luke Crook 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