emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jarmo Hurri <jarmo.hurri@iki.fi>
To: emacs-orgmode@gnu.org
Subject: Re: PATCH: Processing language support in Babel
Date: Tue, 31 Mar 2015 10:32:16 +0300	[thread overview]
Message-ID: <87a8ytzkov.fsf@iki.fi> (raw)
In-Reply-To: 87oans1uh7.fsf@nicolasgoaziou.fr


Greetings.

Nicolas Goaziou <mail@nicolasgoaziou.fr> 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	other threads:[~2015-03-31  7:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 12:51 PATCH: Processing language support in Babel Jarmo Hurri
2015-03-16 21:51 ` Nicolas Goaziou
2015-03-31  7:32   ` Jarmo Hurri [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a8ytzkov.fsf@iki.fi \
    --to=jarmo.hurri@iki.fi \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).