emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] PATCH: Processing language support in Babel


From: Jarmo Hurri
Subject: Re: [O] PATCH: Processing language support in Babel
Date: Tue, 31 Mar 2015 10:32:16 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Greetings.

Nicolas Goaziou <address@hidden> writes:

>> +;; This differs from most standard languages in that
>> +;;
>> +;; 1) there is no such thing as a "session" in processing
>> +;;
>> +;; 2) results can only be exported as html; in this case, the
>> +;;    processing code is embedded via a file into a javascript block
>> +;;    using the processing.js module; the script then draws the
>> +;;    resulting output when the web page is viewed in a browser
>> +;;
>> +;; 3) when not exporting html, evaluation of processing code results
>> +;;    in interactive viewing of the results via Processing 2.0 Emacs
>> +;;    mode; note that the user is responsible for making sure that
>> +;;    processing.js is available on the website
>
> It is awkward (and fragile) to guess the current export back-end used.
> Wouldn't it be simpler to do "2" if :results is html and "3" otherwise?

What the user will want is to view the sketch in an external viewer when
not exporting, so (s)he can see what will eventually be exported. So the
user would have :results html set, but would still like to do "3" in the
buffer.

I think what I could try to do is to bind some key combination so that
it will do "3" when inside a Processing block. That is, remove "3" from
org-babel-execute-processing. What would also solve some other issues
you mention below. Would that be ok?

>> +;; declaration needed because requiring ob does not define the variable
>> +(eval-when-compile (defvar org-babel-temporary-directory))
>
> Isn't
>
>   (defvar org-babel-temporary-directory)
>
> sufficient?

Could be, but it would mean that that variable would be defvar'd
multiple times (when not compiling). Maybe that is ok in elisp, but it
sounds weird programming practice to me. Or?

>> +;; default header tags depend on whether exporting html or not; if not
>> +;; exporting html, then no results are produced; otherwise results are
>> +;; html
>
> It shouldn't.

Ok, this was addressed in the suggestion above.

>> +;; a running index for producing unique ids for processing sketches
>> +(defvar org-babel-processing-sketch-number 0)
>> +(add-hook 'org-export-before-processing-hook
>> +      (lambda (backend) (setq org-babel-processing-sketch-number 0)))
>
> It pollutes `org-export-before-processing-hook'. What about using sha1
> of the contents of the code block instead?

I'll do that.

>> +(defun org-babel-execute:processing (body params)
>> +  "Execute a block of Processing code.
>> +This function is called by `org-babel-execute-src-block'."
>> +  (let ((sketch-code
>> +     (org-babel-expand-body:generic
>> +      body
>> +      params
>> +      (org-babel-variable-assignments:processing params))))
>> +    (if (and (not (null org-babel-exp-reference-buffer))
>> +         (string= org-export-current-backend "html"))
>
> This will not work if current back-end is derived from "html".

Addressed above.

>> +    ;; results are html if exporting html
>> +    (let ((sketch-canvas-id
>> +           (concat "org-processing-canvas-"
>> +                   (number-to-string org-babel-processing-sketch-number))))
>
>   (format "org-processing-canvas-%d" org-babel-processing-sketch-number)
>
>> +      (setq org-babel-processing-sketch-number
>> +            (1+ org-babel-processing-sketch-number))
>
>   (incf org-babel-processing-sketch-number)
>
>> +(defun org-babel-processing-define-type (data)
>> +  "Determine type of DATA.
>> +
>> +DATA is a list.  Return type as a symbol.
>> +
>> +The type is `String' if any element in DATA is
>> +a string.  Otherwise, it is either `float', if some elements are
>> +floats, or `int'."
>> +  (let* ((type 'int)
>> +     find-type                      ; for byte-compiler
>> +     (find-type
>> +      (function
>
> Not needed.

Which part is not needed? This was adapted directly from
ob-asymptote.el. Is it unnecessary there as well?

>> +       (lambda (row)
>> +         (catch 'exit
>> +           (mapc (lambda (el)
>> +                   (cond ((listp el) (funcall find-type el))
>> +                         ((stringp el) (throw 'exit (setq type 'String)))
>> +                         ((floatp el) (setq type 'float))))
>> +                 row))))))
>
>   (lambda (row)
>     (dolist (el row type)
>       (cond ...)))
>
>> +    (funcall find-type data) type))
>                                 ^^^^
>                               not needed

Unnecessary in ob-asymptote.el as well?

I'll proceed to implement the changes once I get an ok from you.

All the best,

Jarmo




reply via email to

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