emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] New patches WAS Re: [PATCH] inline src block results can be remo


From: Aaron Ecay
Subject: Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed
Date: Sun, 18 Jan 2015 17:55:04 -0500
User-agent: Notmuch/0.19+20~g2bbe5e0 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu)

Hi Nicolas,

2015ko urtarrilak 18an, Nicolas Goaziou-ek idatzi zuen:
> 
> Aaron Ecay <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]