Re: [PATCH] Possibility of using alternative separators in macros

[Christian Moe]

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?

Yours,
Christian