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