[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Babel questions for finalising Processing support

From: Jarmo Hurri
Subject: Re: [O] Babel questions for finalising Processing support
Date: Sat, 07 Mar 2015 20:00:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Aaron Ecay <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]