Hi Eric
On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte schulte.e...@gmail.com 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
Michael Brand michael.ch.br...@gmail.com writes:
Hi Eric
On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte schulte.e...@gmail.com 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
Hi Eric
On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte schulte.e...@gmail.com 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
Michael Brand michael.ch.br...@gmail.com writes:
Hi Eric
On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte schulte.e...@gmail.com 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
Achim Gratz strom...@nexgo.de 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 strom...@nexgo.de writes:
I'm not sure what this would entail other than replacing the call
Hi all
Achim Gratz strom...@nexgo.de 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 strom...@nexgo.de writes:
I'm not sure what this would entail other than replacing
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_dataset1
Achim Gratz strom...@nexgo.de 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:
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, but
Hi Eric
On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte schulte.e...@gmail.com 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.
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
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 strom...@nexgo.de 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
Michael Brand michael.ch.br...@gmail.com writes:
Hi Eric
On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte schulte.e...@gmail.com 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
Hello,
Rick Frankel r...@rickster.com 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
Nicolas-
On 2013-06-26 11:13, Nicolas Goaziou wrote:
Rick Frankel r...@rickster.com 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
Rick Frankel r...@rickster.com writes:
Nicolas-
On 2013-06-26 11:13, Nicolas Goaziou wrote:
Rick Frankel r...@rickster.com 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
Hi Eric
On Wed, Jun 26, 2013 at 4:54 PM, Eric Schulte schulte.e...@gmail.com 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
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
#+CALL:
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 strom...@nexgo.de writes:
I'm not sure what this would entail other than replacing the call with
its arguments with the name of the
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 because
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.
I
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
Hi Achim
On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz strom...@nexgo.de 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
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
but
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 the
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 believe
26 matches
Mail list logo
