Re: [O] Babel: the disappearing hline

[Rick Frankel]

On 2013-11-12 11:09, Jarmo Hurri wrote:
> Rick Frankel <address@hidden> 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 |