emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Babel questions for finalising Processing support
@ 2015-03-06 10:29 Jarmo Hurri
  2015-03-07 14:47 ` Aaron Ecay
  0 siblings, 1 reply; 3+ messages in thread
From: Jarmo Hurri @ 2015-03-06 10:29 UTC (permalink / raw)
  To: emacs-orgmode


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.) Is
   there for example a hook I could use to set buffer-file-name to some
   temporary value?

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

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?

Jarmo

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

* Re: Babel questions for finalising Processing support
  2015-03-06 10:29 Babel questions for finalising Processing support Jarmo Hurri
@ 2015-03-07 14:47 ` Aaron Ecay
  2015-03-07 18:00   ` Jarmo Hurri
  0 siblings, 1 reply; 3+ messages in thread
From: Aaron Ecay @ 2015-03-07 14:47 UTC (permalink / raw)
  To: Jarmo Hurri, emacs-orgmode

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

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

* Re: Babel questions for finalising Processing support
  2015-03-07 14:47 ` Aaron Ecay
@ 2015-03-07 18:00   ` Jarmo Hurri
  0 siblings, 0 replies; 3+ messages in thread
From: Jarmo Hurri @ 2015-03-07 18:00 UTC (permalink / raw)
  To: emacs-orgmode


Aaron Ecay <aaronecay@gmail.com> writes:

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

Ok. On hold.

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

I am trying to be unselfish. :-) I have processing-mode.el in my system,
but an average org mode user, who will byte compile org, will not have
processing-mode.el in their system. A require would result in an error
for this average user during the byte compilation of org. I can program,
but I am no elisp expert, so this is just my understanding.

Should I do something like:

(if (null (require 'processing-mode nil :noerror))
  (declare-function processing-sketch-run "processing-mode.el" nil))

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

Ahem. After some greps I found out today that I had myself specified a
java hook which the processing hook inherited, and the reference to
buffer-file-name was there. Issue solved.

Jarmo

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

end of thread, other threads:[~2015-03-07 18:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-06 10:29 Babel questions for finalising Processing support Jarmo Hurri
2015-03-07 14:47 ` Aaron Ecay
2015-03-07 18:00   ` Jarmo Hurri

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).