Re: Improving org-macro.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> It seems to work on Org's own manual, but other than that I haven't gone
>> out of my way to test it.
> There were a few problems reported by the test suite that I tried to
> address. I also updated `org-lint', which didn't handle macro
> definitions as functions.

Thanks.

>> - It also changes the behavior when $N appears elsewhere than an
>>   "expression context".  E.g.:
>>       #+macro: <name> (eval (let (($1 foo)) (bar)))
> This is not a valid macro definition anyway since placeholders are
> strings.

Indeed for this specific example it was invalid anyway, but I can
imagine some variations on the theme where it still lead to valid code.

>>       #+macro: <name> (eval (fun-with "code $1"))
> I don't think this was valid previously either, for the same reason.

I'm pretty sure this could be made to do interesting things, tho it does
feel a bit like "exploiting a security hole" ;-)

>> I don't think it requires changes to the manual because the semantics
>> described in the manual is sufficiently incomplete that both the old and
>> the new semantics satisfy it.
>
> One noticeable effect is that empty or missing placeholders in macro
> call are now nil, instead of the empty string. This broke our internal
> macros (e.g., {{{n}}} and {{{property}}}) so I updated them.

Ah, indeed, that was indeed a more serious difference which I had missed
(I see in one of my tests failed to catch it just because `concat`
treats nil and "" in the same way).

> I mentioned it in the ORG-NEWS file, and applied your changes. We'll see
> how it goes.

Great, thanks.

BTW, macros of the form

    #+macro FOO (lambda ...)

would lead to much simpler code on `org-macro.el` ;-)


        Stefan