Re: [O] limitation for macro expansion

[Nicolas Goaziou]

Hello,

Yasushi SHOJI <address@hidden> 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