emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Babel: the disappearing hline


From: Jarmo Hurri
Subject: Re: [O] Babel: the disappearing hline
Date: Tue, 12 Nov 2013 08:16:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Eric Schulte <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]