From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rainer M Krug <Rainer@krugs.de>
Cc: Alan Schmitt <alan.schmitt@polytechnique.org>,
emacs-orgmode <emacs-orgmode@gnu.org>,
Rainer M Krug <r.m.krug@gmail.com>
Subject: Re: two sets of default header arguments for one language
Date: Fri, 11 Sep 2015 18:27:12 +0200 [thread overview]
Message-ID: <87oah8vs4f.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <m2bnd9mnzm.fsf@krugs.de> (Rainer M. Krug's message of "Fri, 11 Sep 2015 09:09:01 +0200")
Rainer M Krug <Rainer@krugs.de> writes:
> That's a pity.
>
> It would be really great if one could define different sets of
> hearer-args and then, at thr beginning of a code block, simply use:
>
> #+MACRO: forTangle :tangle ./test.R :export none
> #+MACRO: forExecution :tangle no :export both :session Test14
> #+MACRO: forNoSession :tangle no :export both
It might be great. Probably hackish too.
Anyway simplicity of macros is one of its features, IMO. They are
limited, yet useful for simple things.
Fortunately, there are other ways to achieve what you want without them.
> Would it be difficult to include this feature?
Probably not. The most permissive model for macros is even simpler to
implement than the current one, i.e., something like
(replace-regexp-in-string macro-regexp macro-template buffer)
However macros actually follow a different paradigm, in which they are
required to be parsed. As a consequence they cannot really break the
structure of their container, which turns them into "safe" tools. For
example, you can compare the model above and the current one in the
following document
A paragraph Paragraph{{{this(arg
#+name: table
| cell | )}}} |
Your proposal in to allow them where the parser doesn't look, e.g.,
Babel header arguments, but probably also other places (node properties,
keywords...). It is difficult to draw a line. In any case, I'm not sure
macros would benefit from it. Babel can already do a lot of
destructuring in a document, not every tool needs to be as versatile as
Babel.
Regards,
next prev parent reply other threads:[~2015-09-11 16:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 13:54 two sets of default header arguments for one language Alan Schmitt
2015-09-10 21:00 ` Thomas S. Dye
2015-09-11 9:30 ` Alan Schmitt
2015-09-10 21:16 ` Rainer M Krug
2015-09-10 21:25 ` Nicolas Goaziou
2015-09-11 7:09 ` Rainer M Krug
2015-09-11 9:33 ` Alan Schmitt
2015-09-11 16:27 ` Nicolas Goaziou [this message]
2015-09-18 10:17 ` Rainer M Krug
2015-09-10 22:28 ` Charles C. Berry
2015-09-10 22:39 ` Charles C. Berry
2015-09-11 9:36 ` Alan Schmitt
2015-09-14 14:39 ` Alan Schmitt
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=87oah8vs4f.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=Rainer@krugs.de \
--cc=alan.schmitt@polytechnique.org \
--cc=emacs-orgmode@gnu.org \
--cc=r.m.krug@gmail.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).