* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.