emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] evaluation context in call statements


From: Eric Schulte
Subject: Re: [O] evaluation context in call statements
Date: Tue, 25 Jun 2013 16:41:39 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]