emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rick Frankel <rick@rickster.com>
To: emacs-orgmode@gnu.org
Subject: Re: Babel: the disappearing hline
Date: Tue, 12 Nov 2013 14:22:46 -0500	[thread overview]
Message-ID: <de550ca416e1d97777ff27805753ad0b@mail.rickster.com> (raw)
In-Reply-To: <87ob5pmwkf.fsf@syk.fi>

On 2013-11-12 11:09, Jarmo Hurri wrote:
> Rick Frankel <rick@rickster.com> writes:
> 
> Greetings Rick.
> 
> Note that in versions of org-mode prior to commit 6857d139 of
> 2013-09-28 (below), this was overridden in the setting of
> `org-babel-default-header-args:emacs-lisp, so this may be why you are
> seeing and "inconsistency" between the call line and the emacs-lisp
> source block.
> 
> If I understand correctly, you are referring to the possibility that 
> the
> inconsistency would be caused by an old version of org. I do not think
> that this is the case: I have been pulling the newest version every
> day. Below is the output of the test, including a printout of my org
> version number.

I don't think 8.2.3a is the lastest version from git, containing the
change eric made to the header args:

% git diff release_8.2.3a..6857d139 lisp/ob-emacs-lisp.el|cat
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 886645d..4505129 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,8 +28,7 @@
;;; Code:
(require 'ob)

-(defvar org-babel-default-header-args:emacs-lisp
-  '((:hlines . "yes") (:colnames . "no"))
+(defvar org-babel-default-header-args:emacs-lisp nil
"Default arguments for evaluating an emacs-lisp source block.")

(declare-function orgtbl-to-generic "org-table" (table params))

what is the output of:

#+BEGIN_SRC emacs-lisp
(mapcar 'list
org-babel-default-header-args:emacs-lisp))
#+END_SRC

Regardless, I get the same results you do. I think the issue is this:

hlines are stripped in the input to a block and added back after
depending on the value of the :hlines header argument. Since your code
is outputting literal hlines, there is no processing on output from
the literal block as there where no inputs.

However, if you do the following you will see that the hlines follow
the header rules (stripping the hlines by default:

#+BEGIN_SRC emacs-lisp :var data=func()
data
#+END_SRC

#+RESULTS:
| a |
| b |
| c |

As to the "call" lines, think of the output of the "called" block as
being input to an anonymous block (the #+call), so the hlines are
stripped.

> Or is there something weird in my setup? Do you get a different output
> with my test cases?

No, nothing weird, but the issue is not specific to "call" lines, it's
just related to the way babel processes input and output tablular data.

It's not entirely obvious (and affects colnames as well as hlines).

Again, the solution is to globally set the :hline property to =yes=
instead of the default =no=, and you will get the results you want.
Change the value of `org-babel-default-header-args' in your startup
or just change the :hlines property on a file or headline basis:

#+PROPERTY: hlines yes

or

* hline pruning in output
:PROPERTIES:
:hlines:   yes
:END:

> I will look at the other stuff you sent a bit later.
> 
> All the best,
> 
> Jarmo
> 
> # 
> ----------------------------------------------------------------------
> 
> * hline pruning in output
> 
> # test org version
> #+BEGIN_SRC emacs-lisp
> (org-version)
> #+END_SRC
> 
> #+RESULTS:
> : 8.2.3a
> 
> # 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 |

  reply	other threads:[~2013-11-12 19:22 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
2013-11-12 15:45               ` Rick Frankel
2013-11-12 16:09                 ` Jarmo Hurri
2013-11-12 19:22                   ` Rick Frankel [this message]
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=de550ca416e1d97777ff27805753ad0b@mail.rickster.com \
    --to=rick@rickster.com \
    --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).