From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: Babel: the disappearing hline Date: Wed, 13 Nov 2013 07:17:04 -0700 Message-ID: <8738n0b0ot.fsf@gmail.com> References: <877gcfhuq0.fsf@syk.fi> <8738n3t2ez.fsf@gmail.com> <87fvr3nfcm.fsf@syk.fi> <87wqkfrm3v.fsf@gmail.com> <87y54uhpw8.fsf@gmail.com> <87y54urgs4.fsf@syk.fi> <87ppq6hlye.fsf@gmail.com> <87r4amb0vc.fsf@syk.fi> <87ob5pmwkf.fsf@syk.fi> <87y54ssu1r.fsf@syk.fi> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgfS3-0008UG-Iq for emacs-orgmode@gnu.org; Wed, 13 Nov 2013 13:46:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgfRx-0002GV-7h for emacs-orgmode@gnu.org; Wed, 13 Nov 2013 13:46:07 -0500 Received: from mail-ob0-x230.google.com ([2607:f8b0:4003:c01::230]:44646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgfRx-0002FQ-1v for emacs-orgmode@gnu.org; Wed, 13 Nov 2013 13:46:01 -0500 Received: by mail-ob0-f176.google.com with SMTP id wp4so931907obc.35 for ; Wed, 13 Nov 2013 10:45:59 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Jarmo Hurri Cc: emacs-orgmode@gnu.org Jarmo Hurri writes: > Rick Frankel 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