all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Babel: RESULTS for no value
@ 2015-03-07 11:40 Jarmo Hurri
  2015-03-07 14:26 ` Aaron Ecay
  0 siblings, 1 reply; 5+ messages in thread
From: Jarmo Hurri @ 2015-03-07 11:40 UTC (permalink / raw)
  To: emacs-orgmode


Greetings.

Would it be feasible to change Babel so that it would *not* output
#+RESULTS: into the org buffer in case there is absolutely no value for
a block?  Consider the following example, which draws an Asymptote
picture in an external viewer.

# ------------------------------------------------------------------
#+BEGIN_SRC asymptote 
size (5cm);
filldraw (unitcircle, red);
#+END_SRC

#+RESULTS:
# ------------------------------------------------------------------

The #+RESULTS: line is produced even though there is no output from the
block.

Making this change would make my life a bit simpler in finalising
Processing support for Babel.

Jarmo

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Babel: RESULTS for no value
  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
  0 siblings, 1 reply; 5+ messages in thread
From: Aaron Ecay @ 2015-03-07 14:26 UTC (permalink / raw)
  To: Jarmo Hurri, emacs-orgmode

Hi Jarmo,

The results line is needed to store the hash value when the :cache
header arg is set.  (See (info "(org) cache"))

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?

-- 
Aaron Ecay

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Babel: RESULTS for no value
  2015-03-07 14:26 ` Aaron Ecay
@ 2015-03-07 17:36   ` Jarmo Hurri
  2015-03-07 21:53     ` Charles C. Berry
  0 siblings, 1 reply; 5+ messages in thread
From: Jarmo Hurri @ 2015-03-07 17:36 UTC (permalink / raw)
  To: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Babel: RESULTS for no value
  2015-03-07 17:36   ` Jarmo Hurri
@ 2015-03-07 21:53     ` Charles C. Berry
  2015-03-09 10:43       ` Jarmo Hurri
  0 siblings, 1 reply; 5+ messages in thread
From: Charles C. Berry @ 2015-03-07 21:53 UTC (permalink / raw)
  To: Jarmo Hurri; +Cc: emacs-orgmode

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1807 bytes --]

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Babel: RESULTS for no value
  2015-03-07 21:53     ` Charles C. Berry
@ 2015-03-09 10:43       ` Jarmo Hurri
  0 siblings, 0 replies; 5+ messages in thread
From: Jarmo Hurri @ 2015-03-09 10:43 UTC (permalink / raw)
  To: emacs-orgmode


Greetings Charles.

"Charles C. Berry" <ccberry@ucsd.edu> writes:

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

Yes indeed, brilliant. Not being familiar with all the internals it was
difficult for me to know what to check and when the test can be
evaluated.

Thanks!

Jarmo

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-03-09 10:43 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2015-03-07 21:53     ` Charles C. Berry
2015-03-09 10:43       ` Jarmo Hurri

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.