From: Leo Alekseyev <dnquark@gmail.com>
To: Eric Schulte <eric.schulte@gmx.com>
Cc: Emacs orgmode <emacs-orgmode@gnu.org>
Subject: Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Date: Tue, 24 Jan 2012 17:35:31 -0600 [thread overview]
Message-ID: <CADzxs1nptfUX8dxK50HCTpV1MTjJJsH=zLbdxM1iDh_Bw2t8Lg@mail.gmail.com> (raw)
In-Reply-To: <87k44hhy7c.fsf@gmx.com>
>
> If /inline blocks/ above don't replace their results above then that is
> expected. If you can find instances where call lines or blocks don't
> replace their results then that is a bug.
Yes, I was finding that neither inline nor regular blocks replace: run
the following with C-c C-v b a few times and look at the block output
-----snip------
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var a="a1.png"
#+BEGIN_SRC R :results output silent
cat("in foo block\n")
cat.a <- function() { cat(a,"\n",sep="") }
cat.a()
#+END_SRC
#+call: foo(a="a1.png")
#+begin_src R :results output raw replace :exports results
cat.a()
#+end_src
----------snip---------
>
>>
>> Finally, in the last file of my original message I try to use #+call's
>> everywhere instead of source blocks. Cleaned up example is pasted
>> below. It looks broken (the first #+call bar is out of order, the
>> second and third #+call bar's don't run), see
>> http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
>> broken
>>
>
> Ah, this is a different issue, but one which should be discussed. I'm
> happy we're working through all of these before the Emacs24 release.
>
> The problem below is not order of evaluation but rather insertion of
> results. The elements are evaluated in order, but the results from the
> bar() call lines are all inserted in the same place. In the current
> code the raw text of the call line is used to insert the results, so
> identical call lines replace each other's results.
.......
>> Although the above is a workaround, it may be cumbersome. I'm on the
> fence about whether to try to change the existing behavior. If each
> identical call line is thought of as a token of the same call then maybe
> it makes sense to have only one location in which to insert the results
> of that call (also it is possible that some users are relying on the
> current behavior). That said it is certainly confusing...
I see no reason why we should think of each call line as a token of
the same call; do you? In fact, it's probably a fundamentally flawed
way of thinking, because nothing guarantees that the global state of
the session hasn't changed between call invocations. In fact, in that
sense, we can't even technically regard the _same_ call line as being
a token of the same call, if we consider it at different times :)
Referring to what I said in another thread ("the principle of least
surprise"): it makes a lot of sense for the call lines to behave the
same way a function call, or a source() statement would behave in the
interpreter session of the original language. From that perspective,
the current behavior seems wrong. Can you come up with a scenario /
usage pattern where the current behavior is more desirable?
--Leo
next prev parent reply other threads:[~2012-01-24 23:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-21 0:25 [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails Leo Alekseyev
2012-01-23 17:58 ` Eric Schulte
2012-01-24 3:50 ` Leo Alekseyev
2012-01-24 4:05 ` Eric Schulte
2012-01-24 4:53 ` Leo Alekseyev
2012-01-24 14:52 ` Eric Schulte
2012-01-24 23:35 ` Leo Alekseyev [this message]
2012-01-27 22:43 ` Eric Schulte
2012-01-28 23:07 ` Leo Alekseyev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADzxs1nptfUX8dxK50HCTpV1MTjJJsH=zLbdxM1iDh_Bw2t8Lg@mail.gmail.com' \
--to=dnquark@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=eric.schulte@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).