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 22:20:28 +0200 Message-ID: <87r4fq3ptf.fsf@Rainer.invalid> References: <444ea6cff489e2adc97092bdac881aef@mail.rickster.com> <878v1y574d.fsf@Rainer.invalid> <874ncm55ma.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrZjH-0002Yi-K9 for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 16:20:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UrZjF-0005zd-Ig for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 16:20:43 -0400 Received: from plane.gmane.org ([80.91.229.3]:49241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UrZjF-0005zX-CX for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 16:20:41 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UrZjD-0000h6-2c for emacs-orgmode@gnu.org; Tue, 25 Jun 2013 22:20:39 +0200 Received: from pd9eb3514.dip0.t-ipconnect.de ([217.235.53.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jun 2013 22:20:39 +0200 Received: from Stromeko by pd9eb3514.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Jun 2013 22:20:39 +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 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