emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Christian Moe <mail@christianmoe.com>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Possibility of using alternative separators in macros
Date: Mon, 17 May 2021 20:51:43 +0200	[thread overview]
Message-ID: <87k0nxry68.fsf@christianmoe.com> (raw)
In-Reply-To: <s7u7kh$bm8$1@ciao.gmane.io>

Maxim Nikulin writes:

> On 17/05/2021 02:21, Christian Moe wrote:
>> Maxim Nikulin writes:
>>> On 03/05/2021 04:08, Christian Moe wrote:
>> [snip]
>>> #+MACRO: allargshack (eval (format "- /%s/ :: %s" $1 (mapconcat
>>> #'identity _ ",")))
>>> {{{allargshack(one, two, three)}}}
>>> I do not know if Eric can swap order of arguments of his credits
>>> macro. Extracting namely last argument requires a bit more lisp code.
>> Yes, I didn't think that far. This would provide a comprehensive
>> backwards-compatible solution to the comma-escaping problem, though
>> perhaps not the most newbie-friendly one. It would also make macros more
>> flexible and powerful in the bargain (I'm sure people will think of
>> other uses for this than commas).
> I agree that it would abuse arguments syntax, but I expect that namely
> newbies would not bother since it would "just work":
> #+MACRO definition  - $1 ::$_
> {{{definition(one, two, three}}}
> It is more experienced users who may be confused why it works.

That's not what I was trying to say. I don't think your suggestion
abuses the argument syntax - it would extend it, in a way that is likely
to prove helpful for multiple purposes.

When I said it was probably not the most newbie-friendly solution for
the comma-escaping problem, I thought that it required including a bit
of lisp in their macros to add the commas back in (the mapconcat
expression in your "allargshack" example above).

But if the "definition" macro above "just works", I suppose that in your
solution, the list of arguments $_ would by default expand to the same
string as the mapconcat expression would, i.e. the commas would be added
back in. That makes sense. The mapconcat expression would not even be
needed, then, unless one wants the macro to do anything else than
preserve commas. Or am I misunderstanding something?


  reply	other threads:[~2021-05-17 19:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 13:26 Juan Manuel Macías
2021-05-01  8:30 ` Bastien
2021-05-01 10:04   ` Nicolas Goaziou
2021-05-01 10:17     ` Bastien
2021-05-01 10:18     ` Bastien
2021-05-01 21:50     ` Juan Manuel Macías
2021-05-02 21:08       ` Christian Moe
2021-05-12 11:49         ` Maxim Nikulin
2021-05-16 19:21           ` Christian Moe
2021-05-17 17:03             ` Maxim Nikulin
2021-05-17 18:51               ` Christian Moe [this message]
2021-05-02 12:13     ` Eric S Fraga
2021-05-11 11:01 ` Eric S Fraga
2021-05-11 16:12   ` Juan Manuel Macías
     [not found]     ` <87im3prvz8.fsf@ucl.ac.uk>
2021-05-11 18:25       ` Juan Manuel Macías
2021-05-15 13:29         ` Bastien
2021-05-15 20:14           ` Juan Manuel Macías
2021-05-15 20:25             ` Bastien
2021-05-15 21:05               ` Juan Manuel Macías
2021-05-16 12:17                 ` Bastien
2021-05-16 16:48                   ` Maxim Nikulin

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:

  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=87k0nxry68.fsf@christianmoe.com \
    --to=mail@christianmoe.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    --subject='Re: [PATCH] Possibility of using alternative separators in macros' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


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).