Michael Brand writes:
> Hi Eric
>
> On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte wrote:
>> The export function (used by `org-test-with-expanded-babel-code') hadn't
>> been updated to use call line names. I've just pushed up a fix.
>
> Thanks, attached the adapted patch to have my ERT again test
Hi Eric
On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte wrote:
> The export function (used by `org-test-with-expanded-babel-code') hadn't
> been updated to use call line names. I've just pushed up a fix.
Thanks, attached the adapted patch to have my ERT again testing.
Michael
From 22633dd583f2a62
Michael Brand writes:
> Hi Eric
>
> On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte wrote:
>> I've just pushed up a patch which implements this change. Call lines
>> should now work exactly as named code blocks providing clarity,
>> uniformity and the flexibility to run multiple identical call li
Hi Eric
On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte wrote:
> I've just pushed up a patch which implements this change. Call lines
> should now work exactly as named code blocks providing clarity,
> uniformity and the flexibility to run multiple identical call lines.
This is very useful for me
Achim Gratz 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 writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its argument
Achim Gratz writes:
> Andreas Leha writes:
>> I did not follow this tread, so I just wanted to clarify: You are talking
>> about making me to replace
>>
>> #+call: number_of_sth(origin="dataset1") :results table
>> #+call: number_of_sth(origin="dataset2") :results table
>>
>> with
>>
>> #+name:
Andreas Leha writes:
> I did not follow this tread, so I just wanted to clarify: You are talking
> about making me to replace
>
> #+call: number_of_sth(origin="dataset1") :results table
> #+call: number_of_sth(origin="dataset2") :results table
>
> with
>
> #+name: call_number_of_sth_with_origin_da
Hi all
Achim Gratz 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 writes:
>>> I'm not sure what this would entail other than replacing the call with
>>> its
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 writes:
>> I'm not sure what this would entail other than replacing the call with
>> its arguments with the name of the call in
> I am sorry, I wanted to say that I want to do something like
> (note: not current behavior)
>
> ---
> #+NAME: i_am_curious_how_this_works
> #+BEGIN_SRC emacs-lisp
> (format "%s" org-babel-current-src-block-location)
> #+END_SRC
>
>
Hi Eric
On Wed, Jun 26, 2013 at 4:54 PM, Eric Schulte wrote:
>> http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547
>
> They will overwrite eachother's results.
I do not understand. In order to avoid that they will overwrite
eachother's results I added `dummy_name="osx"' and `dummy_nam
Rick Frankel writes:
> Nicolas-
>
> On 2013-06-26 11:13, Nicolas Goaziou wrote:
>>
>> Rick Frankel writes:
>>
>> At the time (late 2012) I found Nicolases changes (named results
>> blocks, attributes and captions on the results block and not the
>> source, etc) confusing. I still find it odd tha
Nicolas-
On 2013-06-26 11:13, Nicolas Goaziou wrote:
Rick Frankel writes:
At the time (late 2012) I found Nicolases changes (named results
blocks, attributes and captions on the results block and not the
source, etc) confusing. I still find it odd that you need to evaluate
a source block befo
Hello,
Rick Frankel writes:
> At the time (late 2012) I found Nicolases changes (named results
> blocks, attributes and captions on the results block and not the
> source, etc) confusing. I still find it odd that you need to evaluate
> a source block before you can e.g, add a caption or attribut
Michael Brand writes:
> Hi Eric
>
> On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte wrote:
>> I think we could be well served by discussing how people use call lines,
>> how they would use call lines (if this behavior changed), and what
>> behavior would best support these existing and potential
>> 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 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,
On 2013-06-26 02:29, Achim Gratz wrote:
Eric Schulte writes:
In defense of the existing behavior, I don't see the benefit of calling
a code block with the same arguments from multiple locations and
subsequently littering a file with multiple identical results blocks.
I agree that this didn't mak
Hi Eric
On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte wrote:
> I think we could be well served by discussing how people use call lines,
> how they would use call lines (if this behavior changed), and what
> behavior would best support these existing and potential use cases.
You did not yet answ
Eric Schulte writes:
> In defense of the existing behavior, I don't see the benefit of calling
> a code block with the same arguments from multiple locations and
> subsequently littering a file with multiple identical results blocks.
I agree that this didn't make all that much sense in the past, b
>> Is it a bug?
>
> I think so, but Eric has the last word on this. The results should come
> after the call, but the current implementation would look for the
> results line from the beginning of the buffer.
>
The current behavior is the expected behavior and is not a bug. That
said, I don't be
Achim Gratz writes:
> Anyway, more testing shows my patch will prefer the results line after
> the call, but if you then insert another call before that (without an
> existing result) the result from the now second call will still be
> clobbered, so there needs to be some more fixing by limiting th
Michael Brand writes:
> Is it a bug?
I think so, but Eric has the last word on this. The results should come
after the call, but the current implementation would look for the
results line from the beginning of the buffer.
> I also noticed this when I was writing an ERT. First it confused me
> bu
Hi Achim
On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz wrote:
> Achim Gratz writes:
>> Executing Call#2 will update the #+RESULTS for Call#1 (or actually the
>> first matching #+RESULTS cookie in the whole document). I'd think it
>> should also start looking for the results line from the point of
Achim Gratz writes:
> I'd think this should fix it.
Please discard the first hunk of this patch.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Achim Gratz writes:
> Rick Frankel writes:
Your lucky day is becoming a streak.
> Executing Call#2 will update the #+RESULTS for Call#1 (or actually the
> first matching #+RESULTS cookie in the whole document). I'd think it
> should also start looking for the results line from the point of call.
Rick Frankel writes:
> The arguments to a `#+call' line are evaluated in the context of the
> called block and not the calling block. This seems like a bug to me. For
> example, in the following i would expect the `call' to return "Call" and
> not "Source" as the results:
Tody's your lucky day bec
FThe arguments to a `#+call' line are evaluated in the context of the
called block and not the calling block. This seems like a bug to me. For
example, in the following i would expect the `call' to return "Call" and
not "Source" as the results:
╭
│ * Source
│ #+name: message
│ #+BEGIN_SRC eli
27 matches
Mail list logo
