From: Achim Gratz <Stromeko@Nexgo.DE>
To: emacs-orgmode@gnu.org
Subject: Re: [ox-publish] handling of white space in arguments of macros, named arguments?
Date: Thu, 28 Mar 2013 18:44:11 +0100 [thread overview]
Message-ID: <kj1vfp$rhm$1@ger.gmane.org> (raw)
In-Reply-To: <87ehezxzng.fsf@gmail.com>
Am 28.03.2013 17:22, schrieb Nicolas Goaziou:
> My point is that macro templates have to fit in a single line, no
> newline character allowed. As a consequence, macro arguments are
> implicitly expected to fit in a single line. So a newline character in
> an argument is probably wrong.
My point is that the form of the template really doesn't tell you much
about the (possibly recursive) expansion and since the feature is
relatively new there is absolutely no data to determine if such an
assumption would restrict macros too much. I can certainly see good
uses of linebreaks in macro expansions.
> The current trend for macros is to be really simple so that advanced
> (and not-so advanced) tasks are done with Babel instead. IOW, macros are
> only useful if they are simpler than the simplest form of Babel usage.
In this case, you probly can't or how do you get linebreaks into
arguments of a Babel call (not using escape sequences)?
> In every other case, Babel is a superior choice.
I think that there is some middle ground to cover here. There is no
reason to ask for confirmation in the example you gave for the vcard
insertion, for example. All it does is a simple template expansion, in
other words it acts like a multi-line macro definition with named
parameters.
> Your suggestion is interesting, but I think it would go backwards wrt
> this.
Babel is very nice, but I don't think we should foist it onto everyone,
there are good reasons to stick to plain Org in some situations. The
evaluation confirmation should get a bit smarter, too, but I don't see
how to do that easily (I've already looked). The way things work at the
moment you have to globally switch off confirmation for all but the most
simple uses of Babel.
Regards,
--
Achim.
(on the road :-)
next prev parent reply other threads:[~2013-03-28 17:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 20:08 [ox-publish] handling of white space in arguments of macros, named arguments? Stefan Vollmar
2013-03-27 16:26 ` Nicolas Goaziou
2013-03-28 6:59 ` Achim Gratz
2013-03-28 16:22 ` Nicolas Goaziou
2013-03-28 17:44 ` Achim Gratz [this message]
2013-03-28 9:18 ` Stefan Vollmar
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='kj1vfp$rhm$1@ger.gmane.org' \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/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).