emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

  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).