Re: [O] Macros [was: Re: ATTR_HTML for a clickable image, howto?]

[Nicolas Goaziou]

Hello,

"Sebastien Vauban"
<address@hidden> writes:

> Hi Nicolas,
>
> Nicolas Goaziou wrote:
>> Bastien <bzg-mXXj517/address@hidden> writes:
>>> François Pinard <address@hidden> writes:
>>>> If macros are there to stay in Org, it might be worth documenting a more
>>>> complete specification about how to define and use them.
>>>
>>> I'd welcome some improvement of the manual wrt macros -- any taker?
>>
>> Before documenting anything, we should first define them clearly.
>
> I think you're right here, seen the latest threads on this.
>
>> That is, we can define them through documentation, but we shouldn't write
>> documentation by looking at their current implementation.
>>
>> Should macros be allowed anywhere (which means that the user can shoot
>> himself in the foot) or should their expansion happen in a protected
>> environment (thus limiting their power)?
>
> If I had to choose, I would opt for the first case...
>
>> In the first case, can macros generate inline Babel code, that will be
>> executed before export?
>
> ... where macros would be pre-processed "à la M4" (or C preprocessing):
> replacing some keyword with some other expression.
>
>> In the second case, what types of elements are allowed in the protected
>> environment?
>>
>> Also, do we want to allow multiples macros definitions to stack up? I.e.
>>
>>   #+MACRO: a-macro First line of the macro.
>>   #+MACRO: a-macro Second line of the macro.
>>
>> If so, do we allow blank lines in them, meaning they can break document
>> structure even more?
>>
>> Can the macros be nested?
>>
>> Since macros arguments are comma-separated, how do one insert commas
>> within an argument?
>>
>> Are newline characters allowed in arguments? If not, what else is
>> forbidden there?
>>
>> There are probably other questions, but it should be a good start for
>> a correct implementation.
>
> An extra question is: the "replacing expression" of a macro, must it be pure
> text, or can it be anything (such as code that will be interpreted, in a
> further pass, by some back-end)?

The first option implies that the expression are inserted in the Org
buffer before being parsed. This is mostly what happens in the current
exporter.


Regards,

-- 
Nicolas Goaziou