From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yasushi SHOJI Subject: Re: limitation for macro expansion Date: Mon, 6 Mar 2017 18:28:19 +0900 Message-ID: References: <87shmt7495.wl@dns1.atmark-techno.com> <87tw786lcs.fsf@nicolasgoaziou.fr> <87pohvqiai.wl@dns1.atmark-techno.com> <87shmq4xx0.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53682) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckowR-0004B5-1t for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 04:28:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckowN-0005ja-TY for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 04:28:31 -0500 Received: from p654789.hkidff01.ap.so-net.ne.jp ([121.101.71.137]:47640 helo=gw.atmark-techno.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckowN-0005ir-Jl for emacs-orgmode@gnu.org; Mon, 06 Mar 2017 04:28:27 -0500 Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) by gw.atmark-techno.com (Postfix) with ESMTPS id B317E20375 for ; Mon, 6 Mar 2017 18:28:21 +0900 (JST) Received: by mail-ua0-f197.google.com with SMTP id u81so69455492uau.6 for ; Mon, 06 Mar 2017 01:28:21 -0800 (PST) In-Reply-To: <87shmq4xx0.fsf@nicolasgoaziou.fr> 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Hi Nicolas, On Mon, Mar 6, 2017 at 5:22 PM, Nicolas Goaziou wrote: > Yasushi SHOJI writes: > 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. Yes. That's what I understand from your response. Thanks! >> 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. Sorry for the confusion. I just thought that you gave me a way to use macro with underscore. >> 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. I assume that the key phrase is "anywhere Org markup is recognized". Link format doesn't allow Org markup, right? >> 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 Ah! Great idea. That's what I'm looking for. Thanks. # I use file_name_with_underscore.txt more than subscripts # I'd be nice, at least for me, to have '\sub' and '\super' special keywords # but leave the underscores alone. >> 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'. hmm. just checked the source. org-use-sub-superscripts is only for display. org-export-with-sub-superscripts is just for exports. I was gonna just by-pass or disable subscript parser all together when org-use-sub-superscripts is nil but it doesn't seems to be a good idea, does it? >> - reverse the precedence order of subscript and macro > > This would only move the problem elsewhere. True. -- yashi