Re: [PATCH] inline src block results can be removed

[Andreas Leha <andreas.leha@med.uni-goettingen.de>]

Hi Daniele,

Daniele Pizzolli <dan@toel.it> 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