From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Yasushi SHOJI <yashi@atmark-techno.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: limitation for macro expansion
Date: Wed, 08 Mar 2017 12:30:22 +0100 [thread overview]
Message-ID: <87bmtc0zw1.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87pohtvccq.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Tue, 07 Mar 2017 15:18:29 +0900")
Hello,
Yasushi SHOJI <yashi@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
prev parent reply other threads:[~2017-03-08 11:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 9:58 limitation for macro expansion Yasushi SHOJI
2017-03-05 10:58 ` Nicolas Goaziou
2017-03-06 1:56 ` Yasushi SHOJI
2017-03-06 8:22 ` Nicolas Goaziou
2017-03-06 9:28 ` Yasushi SHOJI
2017-03-06 16:41 ` Nicolas Goaziou
2017-03-07 6:18 ` Yasushi SHOJI
2017-03-08 11:30 ` Nicolas Goaziou [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bmtc0zw1.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=yashi@atmark-techno.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).