From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phill Wolf Subject: Re: Clojure Code Block Results not Tabularized Date: Wed, 29 Jan 2014 18:40:04 -0500 Message-ID: References: <1390915384.2241.11.camel@raven-CM5571> <1390998988.2272.12.camel@raven-CM5571> <1391000780.2272.18.camel@raven-CM5571> <87d2ja4yro.fsf@gmail.com> <87r47qrenk.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdca354d3bf7804f12475a9 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8ejm-00079X-6V for emacs-orgmode@gnu.org; Wed, 29 Jan 2014 18:40:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8ejl-0004xZ-Cd for emacs-orgmode@gnu.org; Wed, 29 Jan 2014 18:40:06 -0500 In-Reply-To: <87r47qrenk.fsf@bzg.ath.cx> 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: Bastien Cc: Soapy Smith , emacs-orgmode@gnu.org, Christian Moe , Eric Schulte --047d7bdca354d3bf7804f12475a9 Content-Type: text/plain; charset=UTF-8 It is better. To really stress it, I tried a two-row table: #+begin_src clojure :results table [[:ny :nj :ct] [ 7 9 4]] #+end_src #+RESULTS: | :ny | :nj | :ct | | 7 | 9 | 4 | On Wed, Jan 29, 2014 at 10:28 AM, Bastien wrote: > Eric Schulte writes: > > > Try evaluating the following and see how it works. > > It works fine for me: > > ,---- > | #+BEGIN_SRC clojure :results table > | (map #(* %1 3) '(1 2 3)) > | #+END_SRC > | > | #+RESULTS: > | | 3 | 6 | 9 | > `---- > > > This simply copies > > the results handling from the slime backend to the cider backend (which > > currently does not appear to have any results handling). While you're > > at it the nrepl results handling looks broken to me as well. > > Yep. > > Greg, please test Eric's function above for all your use cases and let > us know if it covers them all -- then I'll fix this and the nrepl case > too. > > Thanks Eric! > > -- > Bastien > > --047d7bdca354d3bf7804f12475a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is better.=C2=A0 To really stress it, I tried a two-row= table:

#+begin_src clojure :results table
=C2=A0 [[:ny :nj :ct]<= br>=C2=A0=C2=A0 [=C2=A0 7=C2=A0=C2=A0 9=C2=A0=C2=A0 4]]
#+end_src
#+RESULTS:
| :ny | :nj | :ct |
|=C2=A0=C2=A0 7 |=C2=A0=C2=A0 9 |=C2= =A0=C2=A0 4 |


On Wed, Jan 2= 9, 2014 at 10:28 AM, Bastien <bzg@gnu.org> wrote:
Eric Schulte <schulte.eric@gmail.com> writes:

> Try evaluating the following and see how it works.

It works fine for me:

,----
| #+BEGIN_SRC clojure :results table
| (map #(* %1 3) '(1 2 3))
| #+END_SRC
|
| #+RESULTS:
| | 3 | 6 | 9 |
`----

> This simply copies
> the results handling from the slime backend to the cider backend (whic= h
> currently does not appear to have any results handling). =C2=A0While y= ou're
> at it the nrepl results handling looks broken to me as well.

Yep.

Greg, please test Eric's function above for all your use cases and let<= br> us know if it covers them all -- then I'll fix this and the nrepl case<= br> too.

Thanks Eric!

--
=C2=A0Bastien


--047d7bdca354d3bf7804f12475a9--