From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: evaluation context in call statements Date: Tue, 25 Jun 2013 21:53:49 +0200 Message-ID: <874ncm55ma.fsf@Rainer.invalid> References: <444ea6cff489e2adc97092bdac881aef@mail.rickster.com> <878v1y574d.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrZJT-0002pC-Fa for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 15:54:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrZJS-0004zX-3a for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 15:54:03 -0400 Received: from plane.gmane.org ([80.91.229.3]:46208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrZJR-0004zS-Sc for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 15:54:02 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UrZJQ-0005bM-Ob for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 21:54:00 +0200 Received: from pd9eb0ccd.dip0.t-ipconnect.de ([217.235.12.205]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jun 2013 21:54:00 +0200 Received: from Stromeko by pd9eb0ccd.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jun 2013 21:54:00 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain 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. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-ob-core-insert-results-at-the-point-of-call.patch >From 945d7d25a63077bae18c656768939f292b52bb44 Mon Sep 17 00:00:00 2001 From: Achim Gratz 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 --=-=-= Content-Type: text/plain 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 --=-=-=--