From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: limitation for macro expansion Date: Wed, 08 Mar 2017 12:30:22 +0100 Message-ID: <87bmtc0zw1.fsf@nicolasgoaziou.fr> References: <87shmt7495.wl@dns1.atmark-techno.com> <87tw786lcs.fsf@nicolasgoaziou.fr> <87pohvqiai.wl@dns1.atmark-techno.com> <87shmq4xx0.fsf@nicolasgoaziou.fr> <87k2824atd.fsf@nicolasgoaziou.fr> <87pohtvccq.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]:47762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clZnc-000877-0n for emacs-orgmode@gnu.org; Wed, 08 Mar 2017 06:30:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clZna-0005XF-RH for emacs-orgmode@gnu.org; Wed, 08 Mar 2017 06:30:32 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:54080) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1clZna-0005X6-Ky for emacs-orgmode@gnu.org; Wed, 08 Mar 2017 06:30:30 -0500 In-Reply-To: <87pohtvccq.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Tue, 07 Mar 2017 15:18:29 +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: > Are you saying that it's possible to generate "a_20170307.txt" from > "a_{{{timestamp}}}.txt" if I set those variables mentioned above > correctly? without using '\under'? Not at all. Sorry about the confusion. The mentioned variables allow writing, e.g., a_b without worrying about any subscript, if you don't use it. > I know you said it's ambiguous. So let me clarify what I said. What I > said above was to change the syntax (or lex / parser's behavior) when > some variable, let's say 'org-do-not-parse-sub-superscripts', is set > to nil. > > So that a) org leaves '_' in "a_{{{somemacro}}}" as-is and the macro > parser will pickup the "{{{somemacro}}}, b) when I want to use > subscript, I can write "a\sub{someword or two}" to make a subscript. > > People like me don't use subscript much (to be honest, I've never > wanted to use subscript since I started use Org, seven years?), but > use '_' many times in a doc. Hence, (setq org-use-sub-superscripts > nil) in my init.el. But for someone wanting to use subscripts in rare > occasion, '\sub' would serve. > > I can understand if you say it's not good idea to change the _syntax_ > by a variable. Actually, I strictly opposed to any variable controlling syntax. So the above is not an option. >> This is exactly what a nil `org-export-with-sub-superscripts' does. > > If that's the case, why doesn't macro parser pickup the > "{{{timestamp}}}" in "a_{{{timestamp}}}"? My bad. My sentence is inaccurate: it should be "more or less" instead of "exactly". Actually `org-export-with-sub-superscripts' doesn't alter the syntax, and doesn't mess with parsers. The sub/superscript is parsed the usual way, but then is turned back into plain Org syntax, i.e., a string, in the parse tree. See `org-export--remove-uninterpreted-data' for details. In most cases, the result is the same as if the sub/superscript never had been parsed. Unfortunately, in this case, it differs. This variable triggers way after macros have been expanded so it cannot help with macros. > Maybe this is my confusing point? The component resposible defining > the org "syntax" is different from the parser? No, it isn't. > Even if sub/super parser is by-passed, because the "syntax" is > subscript, the macro parser won't be called on this substring? No parser is by-passed, but its work may be undone, per above. So, indeed, the macro parser isn't called. > Is the syntax defined in org-element--object-regexp and > org-element--object-lex? The latter controls precedence among parsed objects. Anyway, I think a simple solution to your problem is to 1. Write a function turning _{{{...}}} into _{{{{...}}}} and add it to `org-export-before-processing-hook'. 2. Depending on the back-end, write a function removing the spurious brackets. Note that I pushed a fix in maint that should limit them in ASCII back-end. Regards, -- Nicolas Goaziou 0x80A93738