[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] evaluation context in call statements
From: |
Andreas Leha |
Subject: |
Re: [O] evaluation context in call statements |
Date: |
Thu, 27 Jun 2013 08:22:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Hi all
Achim Gratz <address@hidden> writes:
> Eric Schulte writes:
>>>> My vote is for adding #+name support to call lines, and then handling
>>>> their results in the same manner as code block results.
>>
>> Achim Gratz <address@hidden> writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its arguments with the name of the call in the results line. But yes,
>>> that'd be a step forward, although you'd have to be careful when copying
>>> calls.
>>>
>>
>> This could work exactly as named source blocks work. E.g.,
> [...]
>
> I see. The problem then really is that #+CALL lines are currently
> "implicitly named" by copying their arguments to the results line. If
> explicit naming is allowed, this implicit naming should go away or at
> least not be the default, IMHO.
>
[ ... ]
I did not follow this tread, so I just wanted to clarify: You are talking
about making me to replace
--8<---------------cut here---------------start------------->8---
#+call: number_of_sth(origin="dataset1") :results table
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---
with
--8<---------------cut here---------------start------------->8---
#+name: call_number_of_sth_with_origin_dataset1
#+call: number_of_sth(origin="dataset1") :results table
#+name: call_number_of_sth_with_origin_dataset2
#+call: number_of_sth(origin="dataset2") :results table
--8<---------------cut here---------------end--------------->8---
?
Such change would make (some of) my orgmode files look rather
complicated. The 'implicit' naming of call lines does make sense IMO,
as all that may distinguish two call lines really are the arguments.
I understand that there are problems with the current implementation of
call lines. But I just want to say, that I would vote for not dropping
the implicit naming of call lines -- but for fixing their problems
instead. An explicit name overriding the default implicit name would
be the preferable solution to me.
Regards,
Andreas
- Re: [O] evaluation context in call statements, (continued)
- Re: [O] evaluation context in call statements, Achim Gratz, 2013/06/25
- Re: [O] evaluation context in call statements, Achim Gratz, 2013/06/25
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/26
- Re: [O] evaluation context in call statements, Achim Gratz, 2013/06/26
- Re: [O] evaluation context in call statements, Rick Frankel, 2013/06/26
- Re: [O] evaluation context in call statements, Nicolas Goaziou, 2013/06/26
- Re: [O] evaluation context in call statements, Rick Frankel, 2013/06/26
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/26
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/26
- Re: [O] evaluation context in call statements, Achim Gratz, 2013/06/27
- Re: [O] evaluation context in call statements,
Andreas Leha <=
- Re: [O] evaluation context in call statements, Achim Gratz, 2013/06/27
- Re: [O] evaluation context in call statements, Andreas Leha, 2013/06/27
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/30
- Re: [O] evaluation context in call statements, Michael Brand, 2013/06/26
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/26
- Re: [O] evaluation context in call statements, Michael Brand, 2013/06/26
- Re: [O] evaluation context in call statements, Eric Schulte, 2013/06/26