From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [RFC] new :post header argument for post-processing of code block results Date: Wed, 03 Apr 2013 08:30:36 -0600 Message-ID: <87li8zwsov.fsf@gmail.com> References: <87bo9zoxqd.fsf@gmail.com> <87bo9yvmux.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:37843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNPQc-0002lR-DW for emacs-orgmode@gnu.org; Wed, 03 Apr 2013 11:16:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNPQU-0007tB-Dk for emacs-orgmode@gnu.org; Wed, 03 Apr 2013 11:16:46 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:65044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNPQT-0007sZ-Jy for emacs-orgmode@gnu.org; Wed, 03 Apr 2013 11:16:38 -0400 Received: by mail-pa0-f49.google.com with SMTP id kp14so958435pab.36 for ; Wed, 03 Apr 2013 08:16:37 -0700 (PDT) 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: Org Mode Mailing List Aaron Ecay writes: > Hi Eric > > 2013ko martxoak 31an, Eric Schulte-ek idatzi zuen: >>=20 >> Hi, >>=20 >> I've been wanting to add the ability to post-process the results of a >> code block for some time, and some recent threads (e.g., [1] and [2]) >> could both have benefited from post-processing of code block output. > > This looks very nice! > >>=20 >> Does this new header argument seem useful? Any suggestions for better >> syntax which don't add too much conceptual or code complexity? > > See below. > >> @@ -625,6 +626,11 @@ block." >> (not (listp result))) >> (list (list result)) result)) >> (funcall cmd body params))) >> + ;; possibly perform post process provided its appropriate >> + (when (cdr (assoc :post params)) >> + (let ((*this* result)) >> + (setq result (org-babel-ref-resolve >> + (cdr (assoc :post params)))))) > > What if you did some string surgery on the :post string, to insert > ",data=3D\"the result\"" into the call? That way users could just write > :post add-width(width=3D5cm), which would be automatically transformed > into add-width(width=3D5cm,data=3D"[[graph.png]]") before being passed to > o-b-ref-resolve. > I don't like this idea, because then it becomes "magic" which value is assigned the result of the current code block, rather than the current case in which it is very explicit. > > (I guess you=E2=80=99d have to take special care to handle things like ":= post > no-args()" and ":post no-args" properly, stripping the initial comma in > the first case and adding parens in the second.) > > This requires that all :post code blocks take a data > argument, but I don=E2=80=99t think that=E2=80=99s more onerous than stip= ulating the > *this* variable at the lisp level. > I think it is more onerous, I also think it reduces flexibility (the writing of the called block needs to know exactly which argument will want to be set by later code blocks). > > Also, I=E2=80=99m unclear on whether elisp is supported Yes it is > (or should be) Yes again > . Do we want to allow ":post (message *this*)"? Yes again If your issue is that (identity *this*) is cumbersome, then I would agree. What about if we change `org-babel-read' as with the attached patch s.t. *any* variable with ear-muffs will be read as Emacs Lisp, allowing this simpler alternative. #+name: val-wrap #+begin_src sh :input=3D"" :results verbatim echo "--------------------" echo "$input" echo "--------------------" #+end_src #+begin_src sh :post val-wrap(input=3D*this*) echo "foo" #+end_src #+RESULTS: : -------------------- : foo : -------------------- Cheers, --=20 Eric Schulte http://cs.unm.edu/~eschulte