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: Sat, 28 Jan 2012 17:07:39 -0600 [thread overview]
Message-ID: <CADzxs1nBCWZz2dbX55vKQW3CAu7-uSFpJByr8ofQarT__fRF=Q@mail.gmail.com> (raw)
In-Reply-To: <87r4ykaez1.fsf@gmx.com>
>>
>> -----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---------
>>
>
> OK, I see what you mean. When I evaluate this buffer multiple times the
> results of the #+call: line *are* replaced as expected, but the final
> code block can not replace it's results because of the "raw" option to
> the :results header argument. The "raw" and "replace" header arguments
> are not compatible because with raw results there is no way to know
> where the results end. I believe this is mentioned in the manual, if
> not it should be.
Ok, I see. Ideally, incompatible arguments should trigger an error
condition that would be communicated to the user (at the very least,
by printing a message in the minibuffer). Silent failures are
annoying, even if documented :)
On a more practical note, is there _a_ method of achieving what I'm
trying to do here, namely, to place an image in the buffer in a way
that would be understood by Org and that would be properly imported in
HTML?
>> 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?
>>
>
> The only loss of functionality would be the ability in the existing
> model to have a call line and it's results live in separate locations.
> Given that call lines can not currently be named their results are named
> by the information on the call line (called function, header arguments,
> etc...) which will be identical for identical call lines, leading to the
> current confusing behavior.
>
> I think the best way forward would be to
>
> 1. stop auto-naming #+call: lines as we are currently and instead leave
> their results anonymous as with code blocks, and by default inserted
> immediately after the #+call: line.
>
> 2. allow names to be applied to call lines, which can then be used to
> identify their results and locate their results remotely in the
> buffer.
>
> If this sounds like a good way forward then I'll put it on my queue for
> some time in the when-I-have-more-time future. :)
Yes, I think it's a good long-term plan. Enqueue it :) In the
meantime, the current behavior (and the possible workaround) should
probably be mentioned in the docs if it isn't already.
--Leo
prev parent reply other threads:[~2012-01-28 23:07 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
2012-01-27 22:43 ` Eric Schulte
2012-01-28 23:07 ` Leo Alekseyev [this message]
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='CADzxs1nBCWZz2dbX55vKQW3CAu7-uSFpJByr8ofQarT__fRF=Q@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).