Re: Babel questions for finalising Processing support

[Aaron Ecay <aaronecay@gmail.com>]

Hi Jarmo,

It’s good to hear of your progress!

2015ko martxoak 6an, Jarmo Hurri-ek idatzi zuen:
> 
> Greetings.
> 
> My implementation of Processing support in Babel is proceeding really
> well! I have now both external viewing of sketches and export to html
> (sketches drawn by browser) working.
> 
> There are a number of details to fix, though.
> 
> 1. When editing Processing code with C-c ' I get an error from
>    processing-mode. Editing with C-c ' works just fine, but the error is
>    annoying. It seems to me the error is caused by the fact that
>    processing-mode refers to buffer-file-name, which is not valid in a
>    temporary buffer. Any ideas on how to fix this inside org? (Wouldn't
>    want to get involved with processing-mode if it can be avoided.)

Why not?  It sounds like their code is causing the problem.

> Is
>    there for example a hook I could use to set buffer-file-name to some
>    temporary value?

You could look at the first answer here for inspiration:
<https://emacs.stackexchange.com/questions/7844/org-mode-have-flycheck-resolve-relative-config-while-editing-code-blocks>.
I’d say you should try to have processing-mode made more robust before
pursuing hacky solutions.

> 
> 2. When processing code is executed with C-c C-c, it shows the sketch in
>    an external viewer. When exported, the results are html code. To this
>    end I have set default header arguments for Processing to be
>    ":results html" and ":exports results". With C-c C-c execution,
>    org-babel-execute:processing returns nil.
> 
>    This works fine otherwise, but even C-c C-c execution produces an
>    empty results section:
> 
>    #+RESULTS:
>    #+BEGIN_HTML
>    #+END_HTML
> 
>    This is a nuisance, since C-c C-c execution always also changes the
>    current file (even though nothing changes). Is there a way to avoid
>    this?

I think your org-babel-execute:processing should return nil (the elisp
value).  This should be caught by the first branch of the cond below the
comment “;; insert results based on type” in org-babel-insert-result,
leading to the begin/end not being inserted.  (Maybe you already figured
this out, based on your later email.)

>    
> 3. In ob-processing.el I (require 'ob). However, to avoid a compiler
>    warning about a free variable I still need to declare
> 
>    (eval-when-compile (defvar org-babel-temporary-directory))
> 
>    Is this ok?

This looks bogus.  The defvar for org-babel-temporary-directory is not
evaluated when noninteractive is true.  I think the defvar should be
unconditional, but I also don’t understand why the code is like that in
the first place, so let’s see if someone knows why before changing it.

> 
> 4. Processing support in Babel will depend on processing2-emacs module,
>    which contains the function processing-sketch-run. Again, to avoid
>    compiler warnings, I am declaring this by
> 
>    (declare-function processing-sketch-run "processing-mode.el" nil)
> 
>    Is this ok?

Are you not doing (require 'processing-mode)?  If you do that, I don’t
understand why the declare-function is also needed.

-- 
Aaron Ecay