From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarmo Hurri Subject: Re: Babel: RESULTS for no value Date: Sat, 07 Mar 2015 19:36:26 +0200 Message-ID: <87oao4zp45.fsf@iki.fi> References: <87y4n9yr0a.fsf@iki.fi> <87vbicnasn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56141) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUIeU-0006pa-Qy for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 12:36:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUIeR-0006wz-K9 for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 12:36:38 -0500 Received: from plane.gmane.org ([80.91.229.3]:54724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUIeR-0006wv-Cz for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 12:36:35 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YUIeO-0006DK-K0 for emacs-orgmode@gnu.org; Sat, 07 Mar 2015 18:36:32 +0100 Received: from 62-78-164-169.bb.dnainternet.fi ([62.78.164.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Mar 2015 18:36:32 +0100 Received: from jarmo.hurri by 62-78-164-169.bb.dnainternet.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Mar 2015 18:36:32 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: emacs-orgmode@gnu.org Aaron Ecay 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