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