From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aaron Ecay <aaronecay@gmail.com>
Subject: Re: [RFC] new :post header argument for post-processing of code
 block results
Date: Mon, 01 Apr 2013 01:30:46 -0400
Message-ID: <87bo9yvmux.fsf@gmail.com>
References: <87bo9zoxqd.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([208.118.235.92]:35675)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1UMXKW-0006ym-RG
	for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:30:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1UMXKS-0006Je-Kq
	for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:30:52 -0400
Received: from mail-qe0-f41.google.com ([209.85.128.41]:62573)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1UMXKS-0006Ja-FD
	for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 01:30:48 -0400
Received: by mail-qe0-f41.google.com with SMTP id 7so1057649qeb.14
	for <emacs-orgmode@gnu.org>; Sun, 31 Mar 2013 22:30:48 -0700 (PDT)
In-Reply-To: <87bo9zoxqd.fsf@gmail.com>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Eric Schulte <schulte.eric@gmail.com>
Cc: Org Mode Mailing List <emacs-orgmode@gnu.org>

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 guess you=E2=80=99d have to take special care to handle things like ":po=
st
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 stipul=
ating the
*this* variable at the lisp level.

Also, I=E2=80=99m unclear on whether elisp is supported (or should be).  Do=
 we
want to allow ":post (message *this*)"?

--=20
Aaron Ecay