Hi Nicolas,
2015ko urtarrilak 18an, Nicolas Goaziou-ek idatzi zuen:
>
> Aaron Ecay <aarone...@gmail.com> writes:
>
>> 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen:
>>> It would be more flexible, but it would also defeat the whole point of
>>> the "results" macro, that is to be able to mark /unambiguously/ the
>>> output of an inline block. Indeed, even if you can get the name of the
>>> macro from the parameter, you cannot be sure the macro was generated by
>>> the code block, unlike to a results macro.
>>
>> Well, you could examine the code block’s :wrap header arg to determine
>> what kind of macro it generates, rather than hardcoding “results.”
>> (This would break when :wrap’s value was changed, though).
>
> As I said above, even if you read :wrap parameter, this is ambiguous,
> since the use can insert any "foo" macro after a ":wrap foo":
>
> src_emacs-lisp[:wrap foo]{(+ 1 1)} {{{foo(this is something else)}}}
>
>> Probably a better solution is that the results macro could wrap the
>> custom macro:
>>
>> {{{results({{{mymacro(foo)}}})}}}
>
> You cannot nest macros.
OK, I didn’t know that.
>
[...]
> You probably can use some Babel code instead.
Indeed, it looks like the system I had in mind wouldn’t work very well.
Thanks for this suggestion, I’ll look into it.
Thanks,
--
Aaron Ecay
