Eric Schulte <[email protected]> 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
