[Top][All Lists]

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

Re: [O] Babel: the disappearing hline

From: Rick Frankel
Subject: Re: [O] Babel: the disappearing hline
Date: Tue, 12 Nov 2013 14:22:46 -0500
User-agent: Roundcube Webmail/0.9.0

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

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

| 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

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


* hline pruning in output
:hlines:   yes

I will look at the other stuff you sent a bit later.

All the best,


# ----------------------------------------------------------------------

* hline pruning in output

# test org version
#+BEGIN_SRC emacs-lisp

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

#+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()


| a |
| b |
| c |

# case 3: but hlines are removed by default when source code is
# called by #+CALL
#+CALL: func()

| a |
| b |
| c |

reply via email to

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