Eric Schulte <schulte.e...@gmail.com> writes: Greetings Eric.
> There are two paces to specify header arguments in a call line, the > arguments in the [] are applied to the input-table function, *not* to > the call line, so they change the inputs. The trailing header > arguments are applied to the call line. So there is an implicit post-processing function that takes the result of the called block as input, and hline pruning is applied in this function? I put on the table a suggestion that the default behaviour of #+CALL w.r.t. the handling of hlines is changed from removing hlines in output to not removing them. I am suggesting this partly because I don't understand why the default behaviour is as it is now, and secondly because the current behavious differs from the way hlines are handled in other block evaluations: # --------------------------------------------------------------------- * hline pruning in output # case 1: hlines are retained by default when a source code block is # defined and evaluated #+NAME: func #+BEGIN_SRC emacs-lisp (list '(a) '(b) 'hline '(c)) #+END_SRC #+RESULTS: func | a | | b | |---| | c | # case 2: hlines are retained by default when source code is called # by post #+BEGIN_SRC emacs-lisp :post func() #+END_SRC #+RESULTS: | a | | b | |---| | c | # case 3: but hlines are removed by default when source code is # called by #+CALL #+CALL: func() #+RESULTS: | a | | b | | c | # --------------------------------------------------------------------- All the best, Jarmo