From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarmo Hurri Subject: Re: PATCH: Processing language support in Babel Date: Tue, 31 Mar 2015 10:32:16 +0300 Message-ID: <87a8ytzkov.fsf@iki.fi> References: <8761a5ys9q.fsf@iki.fi> <87oans1uh7.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycqf2-0003fH-O8 for emacs-orgmode@gnu.org; Tue, 31 Mar 2015 03:32:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ycqez-0004cQ-Hc for emacs-orgmode@gnu.org; Tue, 31 Mar 2015 03:32:32 -0400 Received: from plane.gmane.org ([80.91.229.3]:49666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ycqez-0004cG-6q for emacs-orgmode@gnu.org; Tue, 31 Mar 2015 03:32:29 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ycqes-0001DR-RH for emacs-orgmode@gnu.org; Tue, 31 Mar 2015 09:32:22 +0200 Received: from 62-78-164-169.bb.dnainternet.fi ([62.78.164.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 09:32:22 +0200 Received: from jarmo.hurri by 62-78-164-169.bb.dnainternet.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Mar 2015 09:32:22 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Greetings. Nicolas Goaziou 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