Hi Eric 2013ko martxoak 31an, Eric Schulte-ek idatzi zuen: > > Hi, > > 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! > > 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=\"the result\"" into the call? That way users could just write :post add-width(width=5cm), which would be automatically transformed into add-width(width=5cm,data="[[graph.png]]") before being passed to o-b-ref-resolve. (I guess you’d 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’t think that’s more onerous than stipulating the *this* variable at the lisp level. Also, I’m unclear on whether elisp is supported (or should be). Do we want to allow ":post (message *this*)"? -- Aaron Ecay
