* evaluation context in call statements @ 2013-06-25 17:34 Rick Frankel 2013-06-25 19:21 ` Achim Gratz 0 siblings, 1 reply; 27+ messages in thread From: Rick Frankel @ 2013-06-25 17:34 UTC (permalink / raw) To: emacs-orgmode 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 elisp :var m="foo" │ m │ #+END_SRC │ │ #+RESULTS: message │ : foo │ │ * Call │ #+call: message(m=(nth 4 (org-heading-components))) │ │ #+RESULTS: message(m=(nth 4 (org-heading-components))) │ : Source ╰──── is there any way to reference the current context in a `call' line? rick ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 17:34 evaluation context in call statements Rick Frankel @ 2013-06-25 19:21 ` Achim Gratz 2013-06-25 19:53 ` Achim Gratz 0 siblings, 1 reply; 27+ messages in thread From: Achim Gratz @ 2013-06-25 19:21 UTC (permalink / raw) To: emacs-orgmode 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 Eric just fixed this. There's a bug with finding the #+RESULTS line though: --8<---------------cut here---------------start------------->8--- * Babel LOC ** Source #+name: message #+BEGIN_SRC elisp :var m="foo" m #+END_SRC #+RESULTS: message : foo ** Call 1 #+call: message(m=(nth 4 (org-heading-components))) #+RESULTS: message(m=(nth 4 (org-heading-components))) : Call 2 ** Call 2 #+call: message(m=(nth 4 (org-heading-components))) --8<---------------cut here---------------end--------------->8--- 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 don't really get why it does this, maybe Eric knows where to look. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 19:21 ` Achim Gratz @ 2013-06-25 19:53 ` Achim Gratz 2013-06-25 20:06 ` Achim Gratz 2013-06-25 20:07 ` Michael Brand 0 siblings, 2 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-25 19:53 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 403 bytes --] 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 don't really get why it does this, maybe Eric knows where to look. I'd think this should fix it. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-ob-core-insert-results-at-the-point-of-call.patch --] [-- Type: text/x-patch, Size: 1775 bytes --] From 945d7d25a63077bae18c656768939f292b52bb44 Mon Sep 17 00:00:00 2001 From: Achim Gratz <Stromeko@Stromeko.DE> Date: Tue, 25 Jun 2013 21:51:07 +0200 Subject: [PATCH] ob-core: insert results at the point of call * lisp/ob-core.el (org-babel-execute-src-block): Ensure that head is set to location of call if it is known. Pass through head to `org-babel-find-named-result' so that it doesn't search from the beginning of the file. --- lisp/ob-core.el | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 4115912..36f42e1 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -662,8 +662,8 @@ (defun org-babel-execute-src-block (&optional arg info params) (when (cdr (assoc :file params)) (setq result-params (remove "file" result-params))))) - (org-babel-insert-result - result result-params info new-hash indent lang)) + (org-babel-insert-result + result result-params info new-hash indent lang)) (run-hooks 'org-babel-after-execute-hook) result) (setq call-process-region @@ -1839,7 +1839,11 @@ (defun org-babel-where-is-src-block-result (&optional insert info hash indent) ;; - return t if it is found, else return nil ;; - if it does not need to be rebuilt, then don't set end ;; - if it does need to be rebuilt then do set end - name (setq beg (org-babel-find-named-result name)) + name (setq beg (org-babel-find-named-result + name + (or org-babel-current-src-block-location + (nth 6 info) + (org-babel-where-is-src-block-head)))) (prog1 beg (when (and hash (not (string= hash (match-string 5)))) (goto-char beg) (setq end beg) ;; beginning of result -- 1.8.3.1 [-- Attachment #3: Type: text/plain, Size: 187 bytes --] Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 19:53 ` Achim Gratz @ 2013-06-25 20:06 ` Achim Gratz 2013-06-25 20:07 ` Michael Brand 1 sibling, 0 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-25 20:06 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 19:53 ` Achim Gratz 2013-06-25 20:06 ` Achim Gratz @ 2013-06-25 20:07 ` Michael Brand 2013-06-25 20:20 ` Achim Gratz 1 sibling, 1 reply; 27+ messages in thread From: Michael Brand @ 2013-06-25 20:07 UTC (permalink / raw) To: Achim Gratz; +Cc: Org Mode Hi Achim On Tue, Jun 25, 2013 at 9:53 PM, Achim Gratz <Stromeko@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 the point of call. >> I don't really get why it does this, maybe Eric knows where to look. > > I'd think this should fix it. Is it a bug? I also noticed this when I was writing an ERT. First it confused me but then I thought that this is intended to make it possible to have #+BEGIN_SRC and #+RESULT at independent locations, possibly in reverse order. For how to address several similar calls to different results see my ERT patch here http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655 and the messages before. I used :session for emacs-lisp and a workaround with :var dummy_name for Babel languages that do not support :session like shell. Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 20:07 ` Michael Brand @ 2013-06-25 20:20 ` Achim Gratz 2013-06-25 20:55 ` Achim Gratz 2013-06-25 22:41 ` Eric Schulte 0 siblings, 2 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-25 20:20 UTC (permalink / raw) To: emacs-orgmode 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 then I thought that this is intended to make it possible to > have #+BEGIN_SRC and #+RESULT at independent locations, possibly in > reverse order. I can't see how it would be much more difficult to have a #+CALL where you want the result (independently of where the source block is), but it seems pretty limiting to allow only a single result. > For how to address several similar calls to different results see my > ERT patch here > http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73655 and the > messages before. I used :session for emacs-lisp and a workaround with > :var dummy_name for Babel languages that do not support :session like > shell. I didn't get what you were trying to do there, but it's pretty obvious now. 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 search to not extend across other calls or source blocks. Or this really is a feature, although I don't really see much use for it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 20:20 ` Achim Gratz @ 2013-06-25 20:55 ` Achim Gratz 2013-06-25 22:41 ` Eric Schulte 1 sibling, 0 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-25 20:55 UTC (permalink / raw) To: emacs-orgmode 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 search > to not extend across other calls or source blocks. Or this really is a > feature, although I don't really see much use for it. If this feature turns out to be useful, how about a :target header argument to specify a named result block? Then it would also be possible to eliminate those rather unsightly appendices. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 20:20 ` Achim Gratz 2013-06-25 20:55 ` Achim Gratz @ 2013-06-25 22:41 ` Eric Schulte 2013-06-26 6:29 ` Achim Gratz 2013-06-26 8:38 ` Michael Brand 1 sibling, 2 replies; 27+ messages in thread From: Eric Schulte @ 2013-06-25 22:41 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode >> 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 the current behavior is necessarily the best behavior, rather it was the obvious choice at the time of implementation and there has never been a successful push to change it. 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. 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. If we do want to change this behavior it would be nice to check the email list archives to see if/when the existing behavior has been defended in the past. > > 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 search > > to not extend across other calls or source blocks. Or this really is a > > feature, although I don't really see much use for it. > If this feature turns out to be useful, how about a :target header > argument to specify a named result block? Then it would also be > possible to eliminate those rather unsightly appendices. My only thought about a :target header argument is that it would need to be implemented for other types of code blocks as well, which could lead to very confusing behavior if we have a named code block with a :target header argument which differs from the name. Also, if the target is referenced, would the #+call line be re-run? My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 22:41 ` Eric Schulte @ 2013-06-26 6:29 ` Achim Gratz 2013-06-26 14:38 ` Rick Frankel 2013-06-26 15:06 ` Eric Schulte 2013-06-26 8:38 ` Michael Brand 1 sibling, 2 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-26 6:29 UTC (permalink / raw) To: emacs-orgmode 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 with property evaluation and elisp argument evaluation now anchored to the point of call, the hierarchical position of the call could and (as the test case from Rick) will be used to distinguish between invocations with the same arguments. Since the current way to find the results doesn't know anything about this, it will generally not do the right thing anymore. Note that calls using a session had that property all the time: multiple calls with the same arguments into the same session are useful, but Babel would only keep the last result. > If we do want to change this behavior it would be nice to check the > email list archives to see if/when the existing behavior has been > defended in the past. If you'd happen to know when that was introduced? > My only thought about a :target header argument is that it would need to > be implemented for other types of code blocks as well, which could lead > to very confusing behavior if we have a named code block with a :target > header argument which differs from the name. Oh yes, the specification of that would be interesting. I'll try to see how this "beam the result anywhere" functionality sprang into existence and what the intended use case was (I expect something to do with sessions). My current suggestion is however to limit the results block search to the same subtree and stop searching at later #+CALL and #+BEGIN_SRC line. We could make this conditional on a :[no]clobber argument to keep compatibility with the current behaviour (clobbering the first result would be the current and perhaps default behaviour). > Also, if the target is referenced, would the #+call line be re-run? Not any more that a reference to a named result would re-run its source block. > My vote is for adding #+name support to call lines, and then handling > their results in the same manner as code block results. 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 6:29 ` Achim Gratz @ 2013-06-26 14:38 ` Rick Frankel 2013-06-26 15:13 ` Nicolas Goaziou 2013-06-26 15:06 ` Eric Schulte 1 sibling, 1 reply; 27+ messages in thread From: Rick Frankel @ 2013-06-26 14:38 UTC (permalink / raw) To: emacs-orgmode 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 make all that much sense in the past, but with > property evaluation and elisp argument evaluation now anchored to the > point of call, the hierarchical position of the call could and (as the > test case from Rick) will be used to distinguish between invocations > with the same arguments. Since the current way to find the results > doesn't know anything about this, it will generally not do the right > thing anymore. Note that calls using a session had that property all > the time: multiple calls with the same arguments into the same session > are useful, but Babel would only keep the last result. Agreed. The only way to know that the arguments are the "same" is to evaluated them :). > My only thought about a :target header argument is that it would need > to > be implemented for other types of code blocks as well, which could lead > to very confusing behavior if we have a named code block with a :target > header argument which differs from the name. > > Oh yes, the specification of that would be interesting. I'll try to > see > how this "beam the result anywhere" functionality sprang into existence > and what the intended use case was (I expect something to do with > sessions). I believe the ability to replace named results anywhere was added by Nicolas in commit 2f2a80fe (quick look at ob-core w/ vc-annotate). > My current suggestion is however to limit the results block search to > the same subtree and stop searching at later #+CALL and #+BEGIN_SRC > line. We could make this conditional on a :[no]clobber argument to > keep > compatibility with the current behaviour (clobbering the first result > would be the current and perhaps default behaviour). These search bounds make sense, but i think this should be the default behavior. I don't see the current behavior as making sense---at least to me. 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 attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) Also, i think a new value for :replace ("original"?) would make more sense than a new :clobber option. > My vote is for adding #+name support to call lines, and then handling > their results in the same manner as code block results. > > 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. It seems inconsistent to add #+name support to call lines but not the other block modifiers (#+header :var ..., etc). I think call lines are a special case, so would be ok with the new :target option. rick ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 14:38 ` Rick Frankel @ 2013-06-26 15:13 ` Nicolas Goaziou 2013-06-26 15:29 ` Rick Frankel 0 siblings, 1 reply; 27+ messages in thread From: Nicolas Goaziou @ 2013-06-26 15:13 UTC (permalink / raw) To: Rick Frankel; +Cc: emacs-orgmode Hello, Rick Frankel <rick@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 caption or attributes to the > results (previous behavior was that header arguments on the source > block were used for the results in exporting.) But you couldn't provide different captions (or attributes) to source code and results (or no caption/attribute to one of them only). If you think about it, it's not very odd that captions and attributes apply to the text located just below, instead of some remote or yet to be generated piece of text. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 15:13 ` Nicolas Goaziou @ 2013-06-26 15:29 ` Rick Frankel 2013-06-26 15:49 ` Eric Schulte 0 siblings, 1 reply; 27+ messages in thread From: Rick Frankel @ 2013-06-26 15:29 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode Nicolas- On 2013-06-26 11:13, Nicolas Goaziou wrote: > > Rick Frankel <rick@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 caption or attributes to the > results (previous behavior was that header arguments on the source > block were used for the results in exporting.) > > But you couldn't provide different captions (or attributes) to source > code and results (or no caption/attribute to one of them only). > > If you think about it, it's not very odd that captions and attributes > apply to the text located just below, instead of some remote or yet to > be generated piece of text. > I agree now (as i did then), with the functionality and understand why and how it works, but i still find having to execute a source block before being able to attribute the results counter-intuitive (as have others). It's kind of like having to wait for the house to be built before you can decide/buy the paint to finish it: ) But I also, don't see any better way to provide the useful functionality of being able to attribute the code block and results separately --- although in my normal use cases, i don't usually export both code and results together. rick ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 15:29 ` Rick Frankel @ 2013-06-26 15:49 ` Eric Schulte 0 siblings, 0 replies; 27+ messages in thread From: Eric Schulte @ 2013-06-26 15:49 UTC (permalink / raw) To: Rick Frankel; +Cc: emacs-orgmode, Nicolas Goaziou Rick Frankel <rick@rickster.com> writes: > Nicolas- > > On 2013-06-26 11:13, Nicolas Goaziou wrote: >> >> Rick Frankel <rick@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 caption or attributes to the >> results (previous behavior was that header arguments on the source >> block were used for the results in exporting.) >> >> But you couldn't provide different captions (or attributes) to source >> code and results (or no caption/attribute to one of them only). >> >> If you think about it, it's not very odd that captions and attributes >> apply to the text located just below, instead of some remote or yet to >> be generated piece of text. >> > > I agree now (as i did then), with the functionality and understand why > and how it works, but i still find having to execute a source block > before being able to attribute the results counter-intuitive (as have > others). You are free to type a #+RESULTS: line manually. If you use yasnippets you could define a snippet for a named code block which inserts the #+RESULTS line concurrently with the code block. -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 6:29 ` Achim Gratz 2013-06-26 14:38 ` Rick Frankel @ 2013-06-26 15:06 ` Eric Schulte 2013-06-27 4:55 ` Achim Gratz 1 sibling, 1 reply; 27+ messages in thread From: Eric Schulte @ 2013-06-26 15:06 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 467 bytes --] >> 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 <Stromeko@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 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., [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: named-calls.org --] [-- Type: text/x-org, Size: 432 bytes --] Unnamed code block. #+begin_src emacs-lisp 'bar #+end_src #+RESULTS: : bar Named code block. #+name: foo-block #+begin_src emacs-lisp 'foo #+end_src can have text between itself and its results #+RESULTS: foo-block : foo Unnamed call line. #+call: foo-block() #+RESULTS: foo-block() : foo Named call line. #+name: foo-call #+call: foo-block() Can have text between itself and its results. #+RESULTS: foo-call : foo [-- Attachment #3: Type: text/plain, Size: 2311 bytes --] Rick Frankel <rick@rickster.com> writes: > It seems inconsistent to add #+name support to call lines but not the > other block modifiers (#+header :var ..., etc). I think call lines are > a special case, so would be ok with the new :target option. See above. This is not inconsistent, it is equivalent with how names and code block already work, which means it is less for new users to learn and old users to keep track of. Also, the existing code block results handling has not caused much confusion, and seems to be powerful enough to deal with every use case. Achim Gratz <Stromeko@nexgo.de> and Rick Frankel <rick@rickster.com> write: >> My current suggestion is however to limit the results block search to >> the same subtree and stop searching at later #+CALL and #+BEGIN_SRC >> line. We could make this conditional on a :[no]clobber argument to >> keep compatibility with the current behaviour (clobbering the first >> result would be the current and perhaps default behaviour). > > These search bounds make sense, but i think this should be the > default behavior. I don't see the current behavior as making > sense---at least to me. I agree that the current behavior is confusing, but I don't like this suggestion. I expect people will be mystified when calls replace results in the same subtree and don't replace blocks elsewhere in the same Org-mode file. No other parts of Org-mode's code block support work this way. > 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 attributes to the > results (previous behavior was that header arguments on the source > block were used for the results in exporting.) > I think this behavior works well and I don't think it will change. I see how it could be nice to automatically apply attributes (e.g., captions, labels etc...) of a code block to that blocks results, but then what if I want to export the code block body and not the results, what if I want to export both. I think Nicolas was right to unify, simplify and clarify the Org-mode attribute semantics. Thanks for the feedback. -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 15:06 ` Eric Schulte @ 2013-06-27 4:55 ` Achim Gratz 2013-06-27 6:22 ` Andreas Leha 2013-06-30 22:24 ` Eric Schulte 0 siblings, 2 replies; 27+ messages in thread From: Achim Gratz @ 2013-06-27 4:55 UTC (permalink / raw) To: emacs-orgmode 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 <Stromeko@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 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 agree that the current behavior is confusing, but I don't like this > suggestion. I expect people will be mystified when calls replace > results in the same subtree and don't replace blocks elsewhere in the > same Org-mode file. No other parts of Org-mode's code block support > work this way. If the results stop being implicitly named, then that problem (and its clumsy solution, which doesn't even work correctly yet) is not needed (I think). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-27 4:55 ` Achim Gratz @ 2013-06-27 6:22 ` Andreas Leha 2013-06-27 14:27 ` Achim Gratz 2013-06-30 22:24 ` Eric Schulte 1 sibling, 1 reply; 27+ messages in thread From: Andreas Leha @ 2013-06-27 6:22 UTC (permalink / raw) To: emacs-orgmode Hi all Achim Gratz <Stromeko@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 <Stromeko@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 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-27 6:22 ` Andreas Leha @ 2013-06-27 14:27 ` Achim Gratz 2013-06-27 23:12 ` Andreas Leha 0 siblings, 1 reply; 27+ messages in thread From: Achim Gratz @ 2013-06-27 14:27 UTC (permalink / raw) To: emacs-orgmode 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 > #+call: number_of_sth(origin="dataset1") :results table > #+name: call_number_of_sth_with_origin_dataset2 > #+call: number_of_sth(origin="dataset2") :results table No. What I'm talking about is that this behaviour is sensible only for #+CALL lines that have functional semantics (i.e. always produce the same result as long as the arguments stay the same) and therefore shouldn't be the (unconditional) default. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-27 14:27 ` Achim Gratz @ 2013-06-27 23:12 ` Andreas Leha 0 siblings, 0 replies; 27+ messages in thread From: Andreas Leha @ 2013-06-27 23:12 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@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: 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 > > No. [...] Thanks for that reassuring clarification. - Andreas ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-27 4:55 ` Achim Gratz 2013-06-27 6:22 ` Andreas Leha @ 2013-06-30 22:24 ` Eric Schulte 2013-07-01 10:23 ` Michael Brand 1 sibling, 1 reply; 27+ messages in thread From: Eric Schulte @ 2013-06-30 22:24 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1029 bytes --] Achim Gratz <Stromeko@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 <Stromeko@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 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. > Exactly. 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. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: named-call.org --] [-- Type: text/x-org, Size: 248 bytes --] #+name: bar #+BEGIN_SRC emacs-lisp :baz #+END_SRC #+call: bar() #+RESULTS: : :baz #+call: bar() #+RESULTS: : :baz #+name: foo #+call: bar() #+RESULTS: foo : :baz #+name: foo2 #+call: bar() #+RESULTS: foo2 : :baz #+name: foo #+call: bar() [-- Attachment #3: Type: text/plain, Size: 55 bytes --] Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-30 22:24 ` Eric Schulte @ 2013-07-01 10:23 ` Michael Brand 2013-07-01 13:11 ` Eric Schulte 0 siblings, 1 reply; 27+ messages in thread From: Michael Brand @ 2013-07-01 10:23 UTC (permalink / raw) To: Eric Schulte; +Cc: Org Mode Hi Eric On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte <schulte.eric@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 is very useful for me sometimes, thank you. I am now adapting my recent ERT that you disabled in the meantime due to your changes and therefore have a question. With C-c C-c on this call line #+NAME: src_block_location_shell sect call #+CALL: src_block_location_shell() the result is #+RESULTS: src_block_location_shell sect call : shell a:1, b:0, c:3, d:0, e:0 as expected. With org-test-with-expanded-babel-code I would expect the same but get #+RESULTS: : shell a:1, b:0, c:3, d:0, e:0 Should the behavior of org-test-with-expanded-babel-code not be aligned? Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-07-01 10:23 ` Michael Brand @ 2013-07-01 13:11 ` Eric Schulte 2013-07-01 13:52 ` Michael Brand 0 siblings, 1 reply; 27+ messages in thread From: Eric Schulte @ 2013-07-01 13:11 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode Michael Brand <michael.ch.brand@gmail.com> writes: > Hi Eric > > On Mon, Jul 1, 2013 at 12:24 AM, Eric Schulte <schulte.eric@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 is very useful for me sometimes, thank you. > > I am now adapting my recent ERT that you disabled in the meantime due > to your changes and therefore have a question. With C-c C-c on this > call line > > #+NAME: src_block_location_shell sect call > #+CALL: src_block_location_shell() > > the result is > > #+RESULTS: src_block_location_shell sect call > : shell a:1, b:0, c:3, d:0, e:0 > > as expected. With org-test-with-expanded-babel-code I would expect the > same but get > > #+RESULTS: > : shell a:1, b:0, c:3, d:0, e:0 > > Should the behavior of org-test-with-expanded-babel-code not be > aligned? > Thanks for catching this. 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. Best, -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-07-01 13:11 ` Eric Schulte @ 2013-07-01 13:52 ` Michael Brand 2013-07-01 14:10 ` Eric Schulte 0 siblings, 1 reply; 27+ messages in thread From: Michael Brand @ 2013-07-01 13:52 UTC (permalink / raw) To: Eric Schulte; +Cc: Org Mode [-- Attachment #1: Type: text/plain, Size: 303 bytes --] Hi Eric On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte <schulte.eric@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 [-- Attachment #2: 0001-Babel-use-NAME-for-src-block-calls-in-ERT.patch.txt --] [-- Type: text/plain, Size: 5966 bytes --] From 22633dd583f2a6270bff4e28eed81f1f0d6a36f5 Mon Sep 17 00:00:00 2001 From: Michael Brand <michael.ch.brand@gmail.com> Date: Mon, 1 Jul 2013 15:50:15 +0200 Subject: [PATCH] Babel: use NAME for src block calls in ERT * testing/examples/babel.org(use case of reading entry properties): Adapt to use the new introduced #+NAME for src block calls. * testing/lisp/test-ob-exp.el(ob-exp/use-case-of-reading-entry-properties): Adapt to use the new introduced #+NAME for src block calls. --- testing/examples/babel.org | 42 ++++++++++++++++++++++++++++-------------- testing/lisp/test-ob-exp.el | 13 ++++++------- 2 files changed, 34 insertions(+), 21 deletions(-) diff --git a/testing/examples/babel.org b/testing/examples/babel.org index de1980e..b1f1702 100644 --- a/testing/examples/babel.org +++ b/testing/examples/babel.org @@ -365,7 +365,10 @@ Here is a call line with more than just the results exported. :ID: cc5fbc20-bca5-437a-a7b8-2b4d7a03f820 :END: -If overriden by caller then use :var from header else use entry property. +Use case checked and documented with this test: During their +evaluation the source blocks read values from properties from the +entry where the call has been made unless the value is overridden with +the optional argument of the caller. ** section :PROPERTIES: @@ -375,10 +378,14 @@ If overriden by caller then use :var from header else use entry property. Note: Just export of a property can be done with a macro: {{{property(a)}}}. -#+CALL: src_block_location_shell(dummy_name="sect call") -#+CALL: src_block_location_elisp[:session sect call]() -- sect inline call_src_block_location_shell(dummy_name="sect inline") -- sect inline call_src_block_location_elisp[:session sect inline]() +#+NAME: src_block_location_shell sect call +#+CALL: src_block_location_shell() + +#+NAME: src_block_location_elisp sect call +#+CALL: src_block_location_elisp() + +- sect inline call_src_block_location_shell() +- sect inline call_src_block_location_elisp() *** subsection :PROPERTIES: @@ -386,20 +393,27 @@ Note: Just export of a property can be done with a macro: {{{property(a)}}}. :c: 4 :END: -#+CALL: src_block_location_shell(dummy_name="sub0 call") -#+CALL: src_block_location_elisp[:session sub0 call]() -- sub0 inline call_src_block_location_shell(dummy_name="sub0 inline") -- sub0 inline call_src_block_location_elisp[:session sub0 inline]() +#+NAME: src_block_location_shell sub0 call +#+CALL: src_block_location_shell() + +#+NAME: src_block_location_elisp sub0 call +#+CALL: src_block_location_elisp() + +- sub0 inline call_src_block_location_shell() +- sub0 inline call_src_block_location_elisp() + +#+NAME: src_block_location_shell sub1 call +#+CALL: src_block_location_shell(c=5, e=6) + +#+NAME: src_block_location_elisp sub1 call +#+CALL: src_block_location_elisp(c=5, e=6) -#+CALL: src_block_location_shell(dummy_name="sub1 call", c=5, e=6) -#+CALL: src_block_location_elisp[:session sub1 call](c=5, e=6) -- sub1 inline call_src_block_location_shell(dummy_name="sub1 inline", c=5, e=6) -- sub1 inline call_src_block_location_elisp[:session sub1 inline](c=5, e=6) +- sub1 inline call_src_block_location_shell(c=5, e=6) +- sub1 inline call_src_block_location_elisp(c=5, e=6) **** function definition #+NAME: src_block_location_shell -#+HEADER: :var dummy_name="workaround to get different result blocks" #+HEADER: :var a=(or (org-entry-get org-babel-current-src-block-location "a" t) "0") #+HEADER: :var b=(or (org-entry-get org-babel-current-src-block-location "b" t) "0") #+HEADER: :var c=(or (org-entry-get org-babel-current-src-block-location "c" t) "0") diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el index 416e229..d2541d3 100644 --- a/testing/lisp/test-ob-exp.el +++ b/testing/lisp/test-ob-exp.el @@ -217,7 +217,6 @@ Here is one at the end of a line. =2= (should-not (string-match (regexp-quote "i=\"10\"") result))))) (ert-deftest ob-exp/use-case-of-reading-entry-properties () - :expected-result :failed ;; TODO: update for new call line result insertion (org-test-at-id "cc5fbc20-bca5-437a-a7b8-2b4d7a03f820" (org-narrow-to-subtree) (let* ((case-fold-search nil) @@ -227,27 +226,27 @@ Here is one at the end of a line. =2= (sub1 "a:1, b:2, c:5, d:0, e:6") (func sub0)) ;; entry "section" - (should (string-match (concat "\"sect call\".*)\n: shell " sect "\n") + (should (string-match (concat "_shell sect call\n: shell " sect "\n") result)) - (should (string-match (concat "sect call\\](.*)\n: elisp " sect "\n") + (should (string-match (concat "_elisp sect call\n: elisp " sect "\n") result)) (should (string-match (concat "\n- sect inline =shell " sect "=\n") result)) (should (string-match (concat "\n- sect inline =elisp " sect "=\n") result)) ;; entry "subsection", call without arguments - (should (string-match (concat "\"sub0 call\".*)\n: shell " sub0 "\n") + (should (string-match (concat "_shell sub0 call\n: shell " sub0 "\n") result)) - (should (string-match (concat "sub0 call\\](.*)\n: elisp " sub0 "\n") + (should (string-match (concat "_elisp sub0 call\n: elisp " sub0 "\n") result)) (should (string-match (concat "\n- sub0 inline =shell " sub0 "=\n") result)) (should (string-match (concat "\n- sub0 inline =elisp " sub0 "=\n") result)) ;; entry "subsection", call with arguments - (should (string-match (concat "\"sub1 call\".*)\n: shell " sub1 "\n") + (should (string-match (concat "_shell sub1 call\n: shell " sub1 "\n") result)) - (should (string-match (concat "sub1 call\\](.*)\n: elisp " sub1 "\n") + (should (string-match (concat "_elisp sub1 call\n: elisp " sub1 "\n") result)) (should (string-match (concat "\n- sub1 inline =shell " sub1 "=\n") result)) -- 1.8.3 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-07-01 13:52 ` Michael Brand @ 2013-07-01 14:10 ` Eric Schulte 0 siblings, 0 replies; 27+ messages in thread From: Eric Schulte @ 2013-07-01 14:10 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode, Eric Schulte Michael Brand <michael.ch.brand@gmail.com> writes: > Hi Eric > > On Mon, Jul 1, 2013 at 3:11 PM, Eric Schulte <schulte.eric@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 > Applied, Thanks -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-25 22:41 ` Eric Schulte 2013-06-26 6:29 ` Achim Gratz @ 2013-06-26 8:38 ` Michael Brand 2013-06-26 14:54 ` Eric Schulte 1 sibling, 1 reply; 27+ messages in thread From: Michael Brand @ 2013-06-26 8:38 UTC (permalink / raw) To: Eric Schulte; +Cc: Achim Gratz, Org Mode Hi Eric On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte <schulte.eric@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. You did not yet answer to what I asked you about more than one call with the same arguments: http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547 > 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. Such result blocks do not have to be necessarily identical. What would you suggest for these examples?: 1) It could be just me feeling like to be on the playground: ------------------------------------------------------------------- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format "%s" org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #<marker at 124 in tmp.org> #+CALL: i_am_curious_how_this_works() (Here I expect to see the result "#<marker at 235 in tmp.org>".) ------------------------------------------------------------------- 2) My use case mentioned at the beginning of this message. Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 8:38 ` Michael Brand @ 2013-06-26 14:54 ` Eric Schulte 2013-06-26 16:53 ` Michael Brand 0 siblings, 1 reply; 27+ messages in thread From: Eric Schulte @ 2013-06-26 14:54 UTC (permalink / raw) To: Michael Brand; +Cc: Achim Gratz, Org Mode Michael Brand <michael.ch.brand@gmail.com> writes: > Hi Eric > > On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte <schulte.eric@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. > > You did not yet answer to what I asked you about more than one call > with the same arguments: > http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547 > They will overwrite eachother's results. We are currently discussing alternatives which would change this behavior. > >> 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. > > Such result blocks do not have to be necessarily identical. What would > you suggest for these examples?: > > 1) It could be just me feeling like to be on the playground: > ------------------------------------------------------------------- > #+NAME: i_am_curious_how_this_works > #+BEGIN_SRC emacs-lisp > (format "%s" org-babel-current-src-block-location) > #+END_SRC > > #+CALL: i_am_curious_how_this_works() > > #+RESULTS: i_am_curious_how_this_works() > : #<marker at 124 in tmp.org> > #+CALL: i_am_curious_how_this_works() > > (Here I expect to see the result "#<marker at 235 in tmp.org>".) > ------------------------------------------------------------------- > This works as expected. Depending on the call line executed, I get different points in the second results. > > 2) My use case mentioned at the beginning of this message. > Currently if you want have separate results for call lines with the same variables you will need to use a dummy variable. I'd suggest an OS variable if you are running them on different operating systems. > > Michael -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 14:54 ` Eric Schulte @ 2013-06-26 16:53 ` Michael Brand 2013-06-26 17:11 ` Eric Schulte 0 siblings, 1 reply; 27+ messages in thread From: Michael Brand @ 2013-06-26 16:53 UTC (permalink / raw) To: Eric Schulte; +Cc: Org Mode Hi Eric On Wed, Jun 26, 2013 at 4:54 PM, Eric Schulte <schulte.eric@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 `dummy_name="osx"' and `dummy_name="gnu"' to the call arguments. What did you mean? > We are currently discussing > alternatives which would change this behavior. My suggestions to this discussion have been two alternatives that already work now and that I already used, see my use case "unicode_normal_form_c" and my patch with the ERT in the other thread mentioned above: 1) use :session where supported like for emacs-lisp source blocks 2) use ":var dummy_name" as a workaround where :session is not supported like for shell source blocks >> ------------------------------------------------------------------- >> #+NAME: i_am_curious_how_this_works >> #+BEGIN_SRC emacs-lisp >> (format "%s" org-babel-current-src-block-location) >> #+END_SRC >> >> #+CALL: i_am_curious_how_this_works() >> >> #+RESULTS: i_am_curious_how_this_works() >> : #<marker at 124 in tmp.org> >> #+CALL: i_am_curious_how_this_works() >> >> (Here I expect to see the result "#<marker at 235 in tmp.org>".) >> ------------------------------------------------------------------- > > This works as expected. Depending on the call line executed, I get > different points in the second results. 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: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #<marker at 124 in tmp.org> #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #<marker at 236 in tmp.org> ------------------------------------------------------------------- and would like the yet to be defined solution in discussion here to make also this possible, together with the appropriate change if necessary to the example given above. Currently working alternative with the change to use ":session": ------------------------------------------------------------------- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format "%s" org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works[:session upper]() #+RESULTS: i_am_curious_how_this_works[:session upper]() : #<marker at 124 in tmp.org> #+CALL: i_am_curious_how_this_works[:session lower]() #+RESULTS: i_am_curious_how_this_works[:session lower]() : #<marker at 267 in tmp.org> ------------------------------------------------------------------- Currently working alternative with the change to use ":var dummy_name": ------------------------------------------------------------------- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp :var dummy_name="" (format "%s" org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works(dummy_name="upper") #+RESULTS: i_am_curious_how_this_works(dummy_name="upper") : #<marker at 143 in tmp.org> #+CALL: i_am_curious_how_this_works(dummy_name="lower") #+RESULTS: i_am_curious_how_this_works(dummy_name="lower") : #<marker at 290 in tmp.org> ------------------------------------------------------------------- > Currently if you want have separate results for call lines with the same > variables you will need to use a dummy variable. Ok, this answers one of my questions in the other thread and confirms my expectation. Does it mean that my patch with the ERT as of 2013-06-19 from the other thread is ok for now and can be applied just to reflect what is currently supported? Or should I change something else in the patch? Michael ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: evaluation context in call statements 2013-06-26 16:53 ` Michael Brand @ 2013-06-26 17:11 ` Eric Schulte 0 siblings, 0 replies; 27+ messages in thread From: Eric Schulte @ 2013-06-26 17:11 UTC (permalink / raw) To: Michael Brand; +Cc: Org Mode > 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: i_am_curious_how_this_works() > > #+RESULTS: i_am_curious_how_this_works() > : #<marker at 124 in tmp.org> > #+CALL: i_am_curious_how_this_works() > > #+RESULTS: i_am_curious_how_this_works() > : #<marker at 236 in tmp.org> > > ------------------------------------------------------------------- > > and would like the yet to be defined solution in discussion here to > make also this possible, If we do add #+names to call lines, and have them adopt the existing code block result behavior, then the above will work without modification. [...] >> Currently if you want have separate results for call lines with the same >> variables you will need to use a dummy variable. > > Ok, this answers one of my questions in the other thread and confirms > my expectation. Does it mean that my patch with the ERT as of > 2013-06-19 from the other thread is ok for now and can be applied just > to reflect what is currently supported? Or should I change something > else in the patch? > Yes, I've just applied this patch. Sorry for the delay. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-07-01 14:12 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-25 17:34 evaluation context in call statements Rick Frankel 2013-06-25 19:21 ` Achim Gratz 2013-06-25 19:53 ` Achim Gratz 2013-06-25 20:06 ` Achim Gratz 2013-06-25 20:07 ` Michael Brand 2013-06-25 20:20 ` Achim Gratz 2013-06-25 20:55 ` Achim Gratz 2013-06-25 22:41 ` Eric Schulte 2013-06-26 6:29 ` Achim Gratz 2013-06-26 14:38 ` Rick Frankel 2013-06-26 15:13 ` Nicolas Goaziou 2013-06-26 15:29 ` Rick Frankel 2013-06-26 15:49 ` Eric Schulte 2013-06-26 15:06 ` Eric Schulte 2013-06-27 4:55 ` Achim Gratz 2013-06-27 6:22 ` Andreas Leha 2013-06-27 14:27 ` Achim Gratz 2013-06-27 23:12 ` Andreas Leha 2013-06-30 22:24 ` Eric Schulte 2013-07-01 10:23 ` Michael Brand 2013-07-01 13:11 ` Eric Schulte 2013-07-01 13:52 ` Michael Brand 2013-07-01 14:10 ` Eric Schulte 2013-06-26 8:38 ` Michael Brand 2013-06-26 14:54 ` Eric Schulte 2013-06-26 16:53 ` Michael Brand 2013-06-26 17:11 ` Eric Schulte
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).