From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: limitation for macro expansion Date: Mon, 06 Mar 2017 09:22:35 +0100 Message-ID: <87shmq4xx0.fsf@nicolasgoaziou.fr> References: <87shmt7495.wl@dns1.atmark-techno.com> <87tw786lcs.fsf@nicolasgoaziou.fr> <87pohvqiai.wl@dns1.atmark-techno.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cknui-0008VG-7m for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 03:22:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cknuh-000488-2V for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 03:22:40 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:50042) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cknug-00047Q-T5 for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 03:22:39 -0500 In-Reply-To: <87pohvqiai.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Mon, 06 Mar 2017 10:56:53 +0900") 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" To: Yasushi SHOJI Cc: emacs-orgmode@gnu.org Hello, Yasushi SHOJI writes: > Ah, you mean the parser is unable to distinguish the macro and > subscript? It's not the parser, but the syntax. Subscript is a_{...} whereas macro is {{{macro(...)}}} so, when you see a_{{{something}}} there are two ways to interpret it: the one you expect and a_{CONTENTS} where CONTENTS is {{something}}. Since subscript syntax started first, it has precedence over the macro. > Doesn't seems to work. When I export 'a_{{{{author}}}}', it > generates: > > a_{Yasushi SHOJI} > > I was expecting to see: > > a_Yasushi SHOJI This is correct if you use `ascii' back-end. How could you tell the difference between a_{Yasushi SHOJI} and a_Yasushi SHOJI otherwise? OTOH, `latex' back-end produces a\(_{\text{Yasushi SHOJI}}\) which means the parser and the export process correctly handle it. >> > - Link doesn't work like this: [[file:{{{input-file}}}][Bad link]] >> >> Indeed. This kind of link is not supported as you cannot follow it >> (macros are an export-only feature). > > Hmm, that's true that you can't follow it. > > Would it be OK to say that it's a design decision to ignore the macro > expansion in the link field at export time? It is. Actually, macros are not allowed in many places, as a design decision. See (info "(org) Macro replacement") for more details. >> Feel free to provide a documentation patch if you think this needs to be >> made explicit. > > Will do once I fully understand. > > Now, what I'm trying to achieve with a macro is to generate a > filename-like string with a timestamp in it in my doc. > > ie) > > #+MACRO: timestamp {{{date(%Y%m%d)}}} > > Please open log_{{{timestamp}}}.txt > > Would it be possible for org to do this? You could try #+MACRO: timestamp {{{time(%Y%m%d)}}} Please open log\under{}{{{timestamp()}}}.txt > If not, would it be possible for me to modify the code to achieve this? > My stupid idea is to: > > - disable sub / superscript parser when org-use-sub-superscripts is nil See `org-export-with-sub-superscripts'. > - reverse the precedence order of subscript and macro This would only move the problem elsewhere. Regards, -- Nicolas Goaziou 0x80A93738