From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: [PATCH] inline src block results can be removed Date: Tue, 25 Nov 2014 09:52:35 +0000 Message-ID: References: <8fd5459682651e00af0f99df81319db3@toel.it> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtCnj-0005ms-AK for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 04:52:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtCnd-0004ss-62 for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 04:52:51 -0500 Received: from plane.gmane.org ([80.91.229.3]:45642) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtCnc-0004se-R9 for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 04:52:45 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XtCnb-0002ic-4x for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 10:52:43 +0100 Received: from 193.63.222.27 ([193.63.222.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Nov 2014 10:52:43 +0100 Received: from andreas.leha by 193.63.222.27 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Nov 2014 10:52:43 +0100 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 Hi Daniele, Daniele Pizzolli writes: > On 2014-11-24 12:12, Daniele Pizzolli wrote: >> On 2014-11-24 11:18, Andreas Leha wrote: >>> Hi Daniele, >>> >>> I think your wishlist is somewhere further down the road. I usually >>> implement some of your points in the src_language. I see that it >>> would >>> be nice if org supported these use cases, but I would see them as part >>> of the LOB or maybe in some package in contrib rather than in core >>> org/babel. >>> >>> For that, I'd argue removable inline results that can be exported >>> without special formatting would be all that is needed to support your >>> wishlist. >> >> Hi Andreas, >> >> sure, I think I will start getting the string I needed from >> src_language. But in some language is really hard to get facilities >> for text manipulation while the output as table generally supported. >> And I also think that the fine grained control of the layout of the >> inline sentence pertains to the org layer. > > Hi Andreas, > > Yesterday I forgot to mention another reason because I think that the > formatting of the results pertains to the org layer and not to the > original language. > > It's about proper boundaries and untrusted or limited trust of the > babel code. By default I wish to run untrusted code and display in a > safely manner the result. This is already possible by remote code > evaluation (but I not really checked if the output is always safely > escaped before the insertion in the org buffer). I agree in principle. But there are limits. Org cannot be expected to know how to format any object I am creating to my liking. So, in my opinion there are 'standard objects' (like tables) that can be passed to org and org can format them appropriately. For more special and targeted things I have to provide the formatting myself. I also agree that it is much cleaner to separate the formatting from the generation. And whenever that is possible that's the way to go. For instance, I can pass my object as a table and have some custom code to do the formatting. That custom code does not have to be the same language that generated the object, but can be any language with babel support. I can then even make this very transparent by using the :post header argument. Simple (non-inline) example with a function to add hlines to tables (the function is old and ugly, though...) --8<---------------cut here---------------start------------->8--- * Example Add hlines to tables at arbitrary rows ignoring already existing hlines. #+name: add-hlines #+begin_src emacs-lisp :var x=(quote (("parameter" "value") ("amount" 1) ("margin" 12))) :var below=1 (labels ((p-cumsum (boolean-list) (if (not boolean-list) 0 (if (not (sequencep boolean-list)) 1 (if (equal 1 (length boolean-list)) (list (if (car boolean-list) 1 0)) (let ((firstsum (p-cumsum (car boolean-list))) (lastsum (p-cumsum (cdr boolean-list)))) (cons firstsum (mapcar '(lambda (x) (+ firstsum x)) lastsum)))))))) (let* ((h (mapcar (lambda(a) (not (equal a 'hline))) x)) (hs (p-cumsum h)) (below-list (if (listp below) below (list below))) (below-rows (reverse (sort below-list '<)))) (message "%S" x) (message "%S" h) (message "%S" hs) (dolist (below-row below-rows) (let ((after-row (apply #'+ (mapcar '(lambda (x) (if (<= x below-row) 1 0)) hs)))) (message "%S" after-row) (setq x (append (cl-subseq x 0 after-row) (list 'hline) (cl-subseq x after-row))))) x)) #+end_src #+begin_src R :results table replace :post add-hlines[:results table](below='(2 3),x=*this*) data.frame(a=1:10, b=11:20) #+end_src #+results: | 1 | 11 | | 2 | 12 | |----+----| | 3 | 13 | |----+----| | 4 | 14 | | 5 | 15 | | 6 | 16 | | 7 | 17 | | 8 | 18 | | 9 | 19 | | 10 | 20 | --8<---------------cut here---------------end--------------->8--- > > Using the source language for outputting org-code is a viable > workaround for my needs but in the long run I will prefer to not > include some potential harmful generated org code. > > I double checked about the output escaping right now. I guessed that > the output in the raw mode was safely escaped. But it really seems > the opposite: [[info:org#Results]]. However it seems that the RESULTS > code are not subsequently evaluated even with: I do not think that style of 'recursive' evaluation is possible. But there is the :post header argument, see above. > > #+BEGIN_SRC elisp > (org-babel-do-load-languages > 'org-babel-load-languages > '((sh . t))) > > (setq org-export-babel-evaluate t) > #+END_SRC > > > Example: > > #+NAME: is-this-safe-or-not > #+BEGIN_SRC sh :result output raw > > printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && > echo true; echo false}' > #+END_SRC > > # TODO: the pipe causes a bug... > > #+RESULTS: is-this-safe-or-not > : Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo > > true; echo false} > > So now I am more confused than before... Has anybody a proof or a > counterexample that is (im)possible to run safely untrusted code on > (untrusted) remote host and still have the local buffer trusted? > > By the way I really wanted to write: > > #+NAME: problem-with-pipes... > #+BEGIN_SRC sh :result output raw > > printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && > echo true || echo false}' > #+END_SRC > > #+RESULTS: problem-with-pipes... > | Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo > > true | | echo false} | > > I guess that something is wrong here: > Org-mode version 8.3beta (release_8.3beta-485-gf70439 @ > /home/user/.emacs.d/el-get/org-mode/lisp/) > > Maybe we need a new result format for safe output or am I missing > something? > > Thanks in advance, > Daniele Best, Andreas