Hello,
Yasushi SHOJI <ya...@atmark-techno.com> 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
