From: Jarmo Hurri <jarmo.hurri@syk.fi>
To: emacs-orgmode@gnu.org
Subject: Re: Babel: the disappearing hline
Date: Tue, 12 Nov 2013 08:16:55 +0200 [thread overview]
Message-ID: <87r4amb0vc.fsf@syk.fi> (raw)
In-Reply-To: 87ppq6hlye.fsf@gmail.com
Eric Schulte <schulte.eric@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
next prev parent reply other threads:[~2013-11-12 6:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 14:35 Babel: the disappearing hline Jarmo Hurri
2013-11-11 14:53 ` Thorsten Jolitz
2013-11-11 15:11 ` Jarmo Hurri
2013-11-11 15:31 ` Thorsten Jolitz
2013-11-11 16:19 ` Eric Schulte
2013-11-11 17:26 ` Jarmo Hurri
2013-11-11 17:44 ` Eric Schulte
2013-11-12 6:16 ` Jarmo Hurri [this message]
2013-11-12 15:45 ` Rick Frankel
2013-11-12 16:09 ` Jarmo Hurri
2013-11-12 19:22 ` Rick Frankel
2013-11-13 6:19 ` Jarmo Hurri
2013-11-13 14:17 ` Eric Schulte
2013-11-13 18:52 ` Rick Frankel
2013-11-13 23:27 ` Eric Schulte
2013-11-15 6:50 ` Jarmo Hurri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4amb0vc.fsf@syk.fi \
--to=jarmo.hurri@syk.fi \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).