emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Babel: the disappearing hline
@ 2013-11-11 14:35 Jarmo Hurri
  2013-11-11 14:53 ` Thorsten Jolitz
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-11 14:35 UTC (permalink / raw)
  To: emacs-orgmode


Greetings.

While taking my first long tour in the land of Babel, I bumped into a
minor hline issue. Can someone tell me why the hline has disappeared
from the second table?

# ------------------------------------------------------------------
* test
  #+NAME: table-one
  #+BEGIN_SRC emacs-lisp
    (list '(a) '(b) 'hline '(c))
  #+END_SRC

  #+RESULTS: table-one
  | a |
  | b |
  |---|
  | c |


  #+NAME: table-two
  #+CALL: table-one()

  #+RESULTS: table-two
  | a |
  | b |
  | c |

  #+NAME: table-three
  #+CALL: table-one[:results raw]()

  #+RESULTS: table-three
  : ((a) (b) hline (c))

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

Jarmo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  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
  0 siblings, 1 reply; 16+ messages in thread
From: Thorsten Jolitz @ 2013-11-11 14:53 UTC (permalink / raw)
  To: emacs-orgmode

Jarmo Hurri <jarmo.hurri@syk.fi> writes:

> Greetings.
>
> While taking my first long tour in the land of Babel, I bumped into a
> minor hline issue. Can someone tell me why the hline has disappeared
> from the second table?

Because you use CALL without arguments and argument :hlines defaults to
'no'?

> # ------------------------------------------------------------------
> * test
>   #+NAME: table-one
>   #+BEGIN_SRC emacs-lisp
>     (list '(a) '(b) 'hline '(c))
>   #+END_SRC
>
>   #+RESULTS: table-one
>   | a |
>   | b |
>   |---|
>   | c |
>
>
>   #+NAME: table-two
>   #+CALL: table-one()
>   #+RESULTS: table-two
>   | a |
>   | b |
>   | c |
>
>   #+NAME: table-three
>   #+CALL: table-one[:results raw]()
>   #+RESULTS: table-three
>   : ((a) (b) hline (c))
>
> # ------------------------------------------------------------------




-- 
cheers,
Thorsten

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 14:53 ` Thorsten Jolitz
@ 2013-11-11 15:11   ` Jarmo Hurri
  2013-11-11 15:31     ` Thorsten Jolitz
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-11 15:11 UTC (permalink / raw)
  To: emacs-orgmode


>> While taking my first long tour in the land of Babel, I bumped into a
>> minor hline issue. Can someone tell me why the hline has disappeared
>> from the second table?
>
> Because you use CALL without arguments and argument :hlines defaults
> to 'no'?

Ok, but why is there then a hline in the raw output in table-three?
Furthermore, setting hlines to yes makes no difference:

* test
  #+NAME: table-one
  #+BEGIN_SRC emacs-lisp
    (list '(a) '(b) 'hline '(c))
  #+END_SRC

  #+RESULTS: table-one
  | a |
  | b |
  |---|
  | c |

  #+NAME: table-two
  #+CALL: table-one[:hlines yes]()

  #+RESULTS: table-two
  | a |
  | b |
  | c |

  #+NAME: table-three
  #+CALL: table-one[:results raw]()

  #+RESULTS: table-three
  : ((a) (b) hline (c))

Jarmo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 15:11   ` Jarmo Hurri
@ 2013-11-11 15:31     ` Thorsten Jolitz
  2013-11-11 16:19       ` Eric Schulte
  0 siblings, 1 reply; 16+ messages in thread
From: Thorsten Jolitz @ 2013-11-11 15:31 UTC (permalink / raw)
  To: emacs-orgmode

Jarmo Hurri <jarmo.hurri@syk.fi> writes:

>>> While taking my first long tour in the land of Babel, I bumped into a
>>> minor hline issue. Can someone tell me why the hline has disappeared
>>> from the second table?
>>
>> Because you use CALL without arguments and argument :hlines defaults
>> to 'no'?
>
> Ok, but why is there then a hline in the raw output in table-three?
> Furthermore, setting hlines to yes makes no difference:

* test
  #+NAME: table-one
#+BEGIN_SRC emacs-lisp
    (list '(a) '(b) 'hline '(c))
#+END_SRC

  #+results: table-one
  | a |
  | b |
  |---|
  | c |


  #+NAME: table-two
  #+CALL: table-one[:hlines yes]()

  #+results: table-two
  | a |
  | b |
  | c |

but 

#+begin_src emacs-lisp :var table=table-one :hlines yes
 table
#+end_src

#+results:
| a |
| b |
|---|
| c |

seems to be a problem with #+CALL then ...

-- 
cheers,
Thorsten

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 15:31     ` Thorsten Jolitz
@ 2013-11-11 16:19       ` Eric Schulte
  2013-11-11 17:26         ` Jarmo Hurri
  0 siblings, 1 reply; 16+ messages in thread
From: Eric Schulte @ 2013-11-11 16:19 UTC (permalink / raw)
  To: Thorsten Jolitz; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Jarmo Hurri <jarmo.hurri@syk.fi> writes:
>
>>>> While taking my first long tour in the land of Babel, I bumped into a
>>>> minor hline issue. Can someone tell me why the hline has disappeared
>>>> from the second table?
>>>
>>> Because you use CALL without arguments and argument :hlines defaults
>>> to 'no'?
>>
>> Ok, but why is there then a hline in the raw output in table-three?
>> Furthermore, setting hlines to yes makes no difference:
>
> * test
>   #+NAME: table-one
> #+BEGIN_SRC emacs-lisp
>     (list '(a) '(b) 'hline '(c))
> #+END_SRC
>
>   #+results: table-one
>   | a |
>   | b |
>   |---|
>   | c |
>
>
>   #+NAME: table-two
>   #+CALL: table-one[:hlines yes]()
>   #+results: table-two
>   | a |
>   | b |
>   | c |
>
> but 
>
> #+begin_src emacs-lisp :var table=table-one :hlines yes
>  table
> #+end_src
>
> #+results:
> | a |
> | b |
> |---|
> | c |
>
> seems to be a problem with #+CALL then ...

The ":hlines yes" header argument must be set on the call line itself.
See (info "(org)Evaluating code blocks").


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: call.org --]
[-- Type: text/x-org, Size: 340 bytes --]

* test
#+NAME: table-one
#+BEGIN_SRC emacs-lisp
    (list '(a) '(b) 'hline '(c))
#+END_SRC

#+results: table-one
| a |
| b |
|---|
| c |


#+NAME: table-two-without
#+CALL: table-one()

#+results: table-two-without
| a |
| b |
| c |

#+NAME: table-two-with
#+CALL: table-one() :hlines yes

#+results: table-two-with
| a |
| b |
|---|
| c |

[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 16:19       ` Eric Schulte
@ 2013-11-11 17:26         ` Jarmo Hurri
  2013-11-11 17:44           ` Eric Schulte
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-11 17:26 UTC (permalink / raw)
  To: emacs-orgmode


Eric Schulte <schulte.eric@gmail.com> writes:

> The ":hlines yes" header argument must be set on the call line itself.

Thanks, that works!

Since this works differently for org results and raw results, can you
explain whether I understand this correctly: a ":hlines yes" at the end
of the line is needed to keep hlines in the output of a #+CALL if the
result is in org-mode, but a ":hlines yes" is not needed if the output
is raw.

In fact, a ":hlines no" keeps hlines in raw output; see a summarizing
example below.

From the documentation I got the impression that if hlines are pruned,
they are pruned from the _input_:

"The :hlines argument to a code block accepts the values yes or no, with
a default value of no.
- no Strips horizontal lines from the input table."

Jarmo

# ---------------------------------------------------------------
* hlines behaviour demo for org and raw output
  #+NAME: input-table
  #+BEGIN_SRC emacs-lisp
    (list '(a) '(b) 'hline '(c))
  #+END_SRC

  #+RESULTS: input-table
  | a |
  | b |
  |---|
  | c |

  #+NAME: table-org-results
  #+CALL: input-table() :hlines yes

  #+RESULTS: table-org-results
  | a |
  | b |
  |---|
  | c |

  #+NAME: table-raw-results
  #+CALL: input-table[:results raw]() :hlines no

  #+RESULTS: table-raw-results
  : ((a) (b) hline (c))
# ---------------------------------------------------------------

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 17:26         ` Jarmo Hurri
@ 2013-11-11 17:44           ` Eric Schulte
  2013-11-12  6:16             ` Jarmo Hurri
  0 siblings, 1 reply; 16+ messages in thread
From: Eric Schulte @ 2013-11-11 17:44 UTC (permalink / raw)
  To: Jarmo Hurri; +Cc: emacs-orgmode

>
> In fact, a ":hlines no" keeps hlines in raw output; see a summarizing
> example below.
>
> From the documentation I got the impression that if hlines are pruned,
> they are pruned from the _input_:
>

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.

[...]
>   #+NAME: table-raw-results
>   #+CALL: input-table[:results raw]() :hlines no
>   #+RESULTS: table-raw-results
>   : ((a) (b) hline (c))

In this case the "[:results raw]" means that the input is a string, so
hline processing is not performed.

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-11 17:44           ` Eric Schulte
@ 2013-11-12  6:16             ` Jarmo Hurri
  2013-11-12 15:45               ` Rick Frankel
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-12  6:16 UTC (permalink / raw)
  To: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-12  6:16             ` Jarmo Hurri
@ 2013-11-12 15:45               ` Rick Frankel
  2013-11-12 16:09                 ` Jarmo Hurri
  0 siblings, 1 reply; 16+ messages in thread
From: Rick Frankel @ 2013-11-12 15:45 UTC (permalink / raw)
  To: Jarmo Hurri; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On 2013-11-12 01:16, Jarmo Hurri wrote:
> Eric Schulte <schulte.eric@gmail.com> writes:
> 
> 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:

This behavior is controlled globally by the value of
`org-babel-default-header-args'. This is overriden by the value of
`org-babel-default-header-args:{lang}' and of course, the setting on
individual source blocks and call lines. As you can see from the below
output, the default is =:hlines no=. 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 you want hlines to be included by default, you can modify the value
of `org-babel-default-header-args'.

I have attached an org file i have been working on to see the results
of various settings of =colnames= and =hlines= on table evaluation in
various languages, you may find it useful.

rick

------
commit 6857d139e1b5ea5c235e3555dbe15aeab227aaef
Author: Eric Schulte <schulte.eric@gmail.com>
Date:   Sat Sep 28 06:37:54 2013 -0600

set default emacs-lisp header args to nil

The difference between elisp and every other language was causing
confusion, so simpler just to set these to nil.

* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
Set to nil.

1 file changed, 1 insertion(+), 2 deletions(-)
lisp/ob-emacs-lisp.el | 3 +--

	Modified   lisp/ob-emacs-lisp.el
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))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: colnames.org --]
[-- Type: text/x-lisp; name=colnames.org, Size: 5123 bytes --]

#+TITLE: Colnames handling
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+AUTHOR: Rick Frankel
#+EMAIL: ut0598@rtasdv12
#+OPTIONS: ':nil *:t -:t ::t <:t H:3 \n:nil ^:t arch:headline
#+OPTIONS: author:t c:nil creator:comment d:(not LOGBOOK) date:t
#+OPTIONS: e:t email:nil f:t inline:t num:nil p:nil pri:nil stat:t
#+OPTIONS: tags:t tasks:t tex:t timestamp:nil toc:t todo:t |:t
#+DESCRIPTION:
#+EXCLUDE_TAGS: noexport
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export

Evaluate the subtree [[Test generator]] with =org-babel-execute-subtree= (=C-c C-v C-s=).
It will:

1. Run [[generate-colnames-and-hlines-tests]] to create the [[colnames and
   hlines]] tests.
2. Run the tests.

Note that it will automatically require the file "ob-{lang}" for
each language block specified in [[Language functions]] below.

* Language functions
:PROPERTIES:
:results:  silent
:exports:  code
:var:      table=table
:ID:       LANGUAGES
:END:
This function should modify each cell of the input table by appending
/-o/ to the value of the cell and convert ='hline= rows in the
input to the literal /hline/, so it appears in the output table.

Create one for each babel language to be tested.

#+CAPTION: emacs-lisp
#+BEGIN_SRC emacs-lisp
  (mapcar
   (lambda (r)
     (if (sequencep r)
         (mapcar
          (lambda (c)
            (if (integerp c)
                (format "%d-o" c)
              (concat c "-o")))
          r)
       (list r)))
   table)
#+END_SRC

#+CAPTION: perl
#+BEGIN_SRC perl :results value
  return [map {
      ref $_ ? [map { $_ . "-o" } @$_] : $_
  } @$table];
#+END_SRC

#+CAPTION: python
#+name: python
#+BEGIN_SRC python
  return [isinstance(r,list) and [str(c)+"-o" for c in r] or [r] for r in table]
#+END_SRC

#+CAPTION: ruby
#+BEGIN_SRC ruby
  table.collect do |r|
    r.instance_of?(Array) ? r.collect { |c| "#{c}-o" } : [r]
  end
#+END_SRC

* Test generator
#+CAPTION: Input table
#+name: table
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
|---+---+---|
| 7 | 8 | 9 |

#+CAPTION: Function to list default header args by language
#+name: list-defaults
#+HEADER:  :var val='org-babel-default-header-args :eval never :exports code
#+BEGIN_SRC emacs-lisp :colnames '(option value)
  (or
   (mapcar
    (lambda (x) (list (car x) (cdr x))) (eval val)) '(("" "")))
#+END_SRC

#+name: generate-colnames-and-hlines-tests
#+BEGIN_SRC emacs-lisp :results raw :exports results
  (condition-case nil
      (progn
        (widen)
        (org-id-goto "COLNAMES-AND-HLINES")
        (org-cut-subtree))
    (error t))
  (concat
   "* Test results\n"
   ":PROPERTIES:\n"
   ":ID: COLNAMES-AND-HLINES\n"
   ":END:\n"
   (let ((data ()) (defaults '("org-babel-default-header-args")))
     (save-excursion
       (save-restriction
         (widen)
         (org-id-goto "LANGUAGES")
         (org-narrow-to-subtree)
         (org-babel-map-executables nil
           (let* ((info (org-babel-get-src-block-info 'light))
                  (lang (nth 0 info)))
             (push (format "org-babel-default-header-args:%s" lang) defaults)
             (require (intern (format "ob-%s" lang)))
             (push
              (concat
               (format "#+name: %s-%%s\n" lang)
               "#+HEADER: :results value :colnames %s :hlines %s\n"
               (format "#+BEGIN_SRC %s :var table=table\n" lang)
               (replace-regexp-in-string
                "^" "   "
                (replace-regexp-in-string "%" "%%" (nth 1 info)))
               "\n#+END_SRC\n"
               "#+ATTR_LATEX: :placement [H]"
               (format "\n#+CAPTION: %s" lang)
               (format "\n#+RESULTS: %s-%%s\n" lang))
              data)))))
     (concat
      "** Default header args\n"
      ":PROPERTIES:\n"
      ":colnames: yes\n"
      ":END:\n"
      "#+LaTeX: \\begin{multicols}{3}\n"
      (mapconcat
       (lambda (arg)
         (format "#+call: list-defaults[:eval yes]('%s)\n\n#+CAPTION: %s\n#+RESULTS:\n"
                 arg arg)) (reverse defaults) "\n") 
      "#+LaTeX: \\end{multicols}\n"
      (mapconcat
       'identity
       (mapcar
        (lambda (arg)
          (let* ((colname (car arg))
                 (hlines (nth 1 arg))
                 (argname (format "%s-%s"
                                  (if (symbolp colname)
                                      (symbol-name colname)
                                    (replace-regexp-in-string "[' ()]" "" colname))
                                  hlines)))
            (concat
             (format "** colnames %s, hlines %s\n" colname hlines)
             "#+LaTeX: \\begin{multicols}{3}\n"
             (mapconcat
              (lambda (block)
                (format block argname colname hlines argname))
              (reverse data) "\n")
             "#+LaTeX: \\end{multicols}\n")))
        (let ((l ()))
          (mapc (lambda (hline)
                  (mapc
                   (lambda (colname) (setq l (cons (list colname hline) l)))
                   (list "'nil" 'yes 'no "'t" "'(d e f)")))
                '(yes no))
          (reverse l))) "\n"))))
#+END_SRC

#+RESULTS: generate-colnames-and-hlines-tests

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-12 15:45               ` Rick Frankel
@ 2013-11-12 16:09                 ` Jarmo Hurri
  2013-11-12 19:22                   ` Rick Frankel
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-12 16:09 UTC (permalink / raw)
  To: emacs-orgmode


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.

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

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 |

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-12 16:09                 ` Jarmo Hurri
@ 2013-11-12 19:22                   ` Rick Frankel
  2013-11-13  6:19                     ` Jarmo Hurri
  0 siblings, 1 reply; 16+ messages in thread
From: Rick Frankel @ 2013-11-12 19:22 UTC (permalink / raw)
  To: emacs-orgmode

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 |

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-12 19:22                   ` Rick Frankel
@ 2013-11-13  6:19                     ` Jarmo Hurri
  2013-11-13 14:17                       ` Eric Schulte
  0 siblings, 1 reply; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-13  6:19 UTC (permalink / raw)
  To: emacs-orgmode

Rick Frankel <rick@rickster.com> writes:

Greetings again.

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

The issue I am trying to raise here is the consistency of the system,
not the way to solve this particular problem. Personally I think it
would be clearer if the handling of hlines in _output_ were consistent
_by default_, regardless of whether the call is made by direct
evaluation of a block; by a post(); or by a #+CALL. I found it very
weird when I bumped into this discrepancy - in a much more complicated
context than the examples I have shown here.

But it is your system and you know what kind of qualities you want it to
have. I am just learning the ropes and sending you a message from the
trenches.

All the best,

Jarmo

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-13  6:19                     ` Jarmo Hurri
@ 2013-11-13 14:17                       ` Eric Schulte
  2013-11-13 18:52                         ` Rick Frankel
  2013-11-15  6:50                         ` Jarmo Hurri
  0 siblings, 2 replies; 16+ messages in thread
From: Eric Schulte @ 2013-11-13 14:17 UTC (permalink / raw)
  To: Jarmo Hurri; +Cc: emacs-orgmode

Jarmo Hurri <jarmo.hurri@syk.fi> writes:

> Rick Frankel <rick@rickster.com> writes:
>
> Greetings again.
>
>> 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.
>
> The issue I am trying to raise here is the consistency of the system,
> not the way to solve this particular problem. Personally I think it
> would be clearer if the handling of hlines in _output_ were consistent
> _by default_, regardless of whether the call is made by direct
> evaluation of a block; by a post(); or by a #+CALL. I found it very
> weird when I bumped into this discrepancy - in a much more complicated
> context than the examples I have shown here.
>
> But it is your system and you know what kind of qualities you want it to
> have. I am just learning the ropes and sending you a message from the
> trenches.
>
> All the best,
>
> Jarmo
>

I understand that this particular use case is confusing, however there
are competing use cases and the case described here is not the most
common.

Take for example the following.

    #+name: data
    | header |
    |--------|
    | one    |
    | two    |
    |--------|
    | three  |

    #+BEGIN_SRC sh :var in=data
      echo "$in"
    #+END_SRC

    #+RESULTS:
    | header |
    | one    |
    | two    |
    | three  |

In fact, hlines are *not* preserved by default with regular code blocks.
And in practice only emacs-lisp code blocks tend to create hlines
themselves.  In general babel does a good deal of hline and colnames
processing.

    #+name: with-a-header
    | numbers |
    |---------|
    | one     |
    | two     |
    | three   |
    | four    |

    Strips both the header *and* the top hline by default.
    #+begin_src emacs-lisp :var in=with-a-header
      (mapcar (lambda (row) (mapcar #'length row)) in)
    #+end_src

    #+RESULTS:
    | 3 |
    | 3 |
    | 5 |
    | 4 |

    Applies the code block only to the body of the input table.
    #+begin_src emacs-lisp :var in=with-a-header :colnames yes
      (mapcar (lambda (row) (mapcar #'length row)) in)
    #+end_src

    #+RESULTS:
    | numbers |
    |---------|
    |       3 |
    |       3 |
    |       5 |
    |       4 |

Perhaps we should change `org-babel-default-inline-header-args' to
include `(:hlines "yes")'.  If there is no push back on that change I'd
be happy to make it.

Regards,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  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
  1 sibling, 1 reply; 16+ messages in thread
From: Rick Frankel @ 2013-11-13 18:52 UTC (permalink / raw)
  To: emacs-orgmode

On 2013-11-13 09:17, Eric Schulte wrote:
> Perhaps we should change `org-babel-default-inline-header-args' to
> include `(:hlines "yes")'.  If there is no push back on that change I'd
> be happy to make it.

I agree. It would probably make the behavior less confusing.

rick

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-13 18:52                         ` Rick Frankel
@ 2013-11-13 23:27                           ` Eric Schulte
  0 siblings, 0 replies; 16+ messages in thread
From: Eric Schulte @ 2013-11-13 23:27 UTC (permalink / raw)
  To: Rick Frankel; +Cc: emacs-orgmode

Rick Frankel <rick@rickster.com> writes:

> On 2013-11-13 09:17, Eric Schulte wrote:
>> Perhaps we should change `org-babel-default-inline-header-args' to
>> include `(:hlines "yes")'.  If there is no push back on that change I'd
>> be happy to make it.
>
> I agree. It would probably make the behavior less confusing.
>

Done.

>
> rick
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Babel: the disappearing hline
  2013-11-13 14:17                       ` Eric Schulte
  2013-11-13 18:52                         ` Rick Frankel
@ 2013-11-15  6:50                         ` Jarmo Hurri
  1 sibling, 0 replies; 16+ messages in thread
From: Jarmo Hurri @ 2013-11-15  6:50 UTC (permalink / raw)
  To: emacs-orgmode


Greetings Eric.

Eric Schulte <schulte.eric@gmail.com> writes:

> I understand that this particular use case is confusing, however there
> are competing use cases and the case described here is not the most
> common.
>
> Take for example the following.
>
>     #+name: data
>     | header |
>     |--------|
>     | one    |
>     | two    |
>     |--------|
>     | three  |
>
>     #+BEGIN_SRC sh :var in=data
>       echo "$in"
>     #+END_SRC
>
>     #+RESULTS:
>     | header |
>     | one    |
>     | two    |
>     | three  |
>
> In fact, hlines are *not* preserved by default with regular code blocks.
> And in practice only emacs-lisp code blocks tend to create hlines
> themselves.  

I do realize this, and you are the expert, but the suggestion was that
hlines would not be stripped from the _output_ of a #+CALL, if they are
generated by the call, just like hlines are not stripped from the
_output_ of an evaluated block, or the _output_ of a post(), as
demonstrated in my earlier examples.

In your example hlines are stripped directly from the _input_.  The
manual also leads one to think that stripping is applied to the
_input_. Maybe this is too simplistic for expert taste, but that is what
it looks like to a casual user.

To put things in context while discussing this minor detail: thank you
for this very impressive system!

All the best,

Jarmo

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2013-11-15  6:50 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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