From: Jarmo Hurri <jarmo.hurri@iki.fi>
To: emacs-orgmode@gnu.org
Subject: Re: Babel: RESULTS for no value
Date: Sat, 07 Mar 2015 19:36:26 +0200 [thread overview]
Message-ID: <87oao4zp45.fsf@iki.fi> (raw)
In-Reply-To: 87vbicnasn.fsf@gmail.com
Aaron Ecay <aaronecay@gmail.com> writes:
> It might be a little distracting to see it there, but it shouldn’t
> interfere with the functionality in any way (for example, it should be
> invisible on export). It the line’s presence causing any problems for
> your code?
It is a nuisance. To summarize, in my current implementation of
Processing support, whenever I execute a Processing code with C-c C-c to
view the resulting sketch in an external window, the following lines
appear in the org file:
#+RESULTS:
#+BEGIN_HTML
#+END_HTML
Furthermore, the HTML lines are replaced on every new execution of the
code, making the org buffer change on every execution. That is not very
convenient.
Let me try to explain how I have implemented support for
Processing. When Processing code is executed with C-c C-c, it does not
return any value: the sketch (graphics) is shown in an external
window. But when the results of the code are exported, the code is
written as html, embedded in a processing.js script. The html code then
draws the sketch when viewed in a browser. It works really well, and I
am mighty proud of that idea. ;-)
To achieve this behaviour, I have set
(defvar org-babel-default-header-args:processing
'((:results . "html") (:exports . "results"))
"Default arguments when evaluating a Processing source block.")
This yields correct behaviour when the results are exported. However,
this also causes for the #+BEGIN_HTML #+END_HTML lines to appear when no
value is returned.
In function org-babel-execute:processing I can identify whether
execution is done for exporting by checking whether
org-babel-exp-reference-buffer is null. If an export is not done, the
function launches the external viewer and returns nil. If an export is
done, the function returns the html code.
There might be other ways around the problem - that would not involve
removal of #+RESULTS: when no value is produced - but I have not been
able to figure out a solution.
Jarmo
next prev parent reply other threads:[~2015-03-07 17:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 11:40 Babel: RESULTS for no value Jarmo Hurri
2015-03-07 14:26 ` Aaron Ecay
2015-03-07 17:36 ` Jarmo Hurri [this message]
2015-03-07 21:53 ` Charles C. Berry
2015-03-09 10:43 ` Jarmo Hurri
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=87oao4zp45.fsf@iki.fi \
--to=jarmo.hurri@iki.fi \
--cc=emacs-orgmode@gnu.org \
/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).