From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: evaluation context in call statements Date: Tue, 25 Jun 2013 16:41:39 -0600 Message-ID: <87ip11h2zq.fsf@gmail.com> References: <444ea6cff489e2adc97092bdac881aef@mail.rickster.com> <878v1y574d.fsf@Rainer.invalid> <874ncm55ma.fsf@Rainer.invalid> <87r4fq3ptf.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uri0J-0000pY-JR for emacs-orgmode@gnu.org; Wed, 26 Jun 2013 01:10:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uri0I-0007Gx-Af for emacs-orgmode@gnu.org; Wed, 26 Jun 2013 01:10:51 -0400 Received: from mail-pd0-x22e.google.com ([2607:f8b0:400e:c02::22e]:33674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uri0I-0007Gk-1x for emacs-orgmode@gnu.org; Wed, 26 Jun 2013 01:10:50 -0400 Received: by mail-pd0-f174.google.com with SMTP id 10so1287193pdc.19 for ; Tue, 25 Jun 2013 22:10:49 -0700 (PDT) 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: Achim Gratz Cc: emacs-orgmode@gnu.org >> 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