From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Charles C. Berry" <ccberry@ucsd.edu>
Subject: Re: Babel: RESULTS for no value
Date: Sat, 7 Mar 2015 13:53:35 -0800
Message-ID: <alpine.OSX.2.00.1503071316310.984@charles-berrys-macbook.local>
References: <87y4n9yr0a.fsf@iki.fi> <87vbicnasn.fsf@gmail.com>
	<87oao4zp45.fsf@iki.fi>
Mime-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-603428608-1425765216=:984"
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35559)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1YUMfe-0001Dj-Ad
	for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 16:54:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1YUMfa-0004BQ-6H
	for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 16:54:06 -0500
Received: from iport-acv5-out.ucsd.edu ([132.239.0.10]:52596)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ccberry@ucsd.edu>) id 1YUMfZ-00048R-TU
	for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 16:54:02 -0500
In-Reply-To: <87oao4zp45.fsf@iki.fi>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Jarmo Hurri <jarmo.hurri@iki.fi>
Cc: emacs-orgmode@gnu.org

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-603428608-1425765216=:984
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Sat, 7 Mar 2015, Jarmo Hurri wrote:

>
> 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.")


I think you can replace

: (:results . "html")

with

: (:results . (or (and org-export-current-backend "html")  "none"))


in your defvar and get the desired result.

If you want export to succeed under other backends, you can replace "html" 
with (symbol-name org-export-current-backend) and then the result will be 
wrapped if (say) latex or ascii is used.

HTH,

Chuck

--0-603428608-1425765216=:984--