From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [babel] using #+call for inline results Date: Mon, 27 Jun 2011 10:43:46 -0700 Message-ID: <87y60n5fvx.fsf@counsyl.com> References: <87mxhaunsi.fsf@ucl.ac.uk> <87mxh9omwb.fsf@gmail.com> <87mxh9pvz8.fsf@ucl.ac.uk> <87sjr1i040.fsf@gmail.com> <4E030676.3070504@christianmoe.com> <87hb7ej1pu.fsf@gmail.com> <4E071E71.4060804@christianmoe.com> <87vcvsruzs.fsf@gmail.com> <4E082041.6080709@christianmoe.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:54166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbFqp-0000M8-IA for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 13:44:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbFqn-0004l1-PQ for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 13:43:59 -0400 Received: from mail-pz0-f41.google.com ([209.85.210.41]:65041) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbFqn-0004jI-KJ for emacs-orgmode@gnu.org; Mon, 27 Jun 2011 13:43:57 -0400 Received: by mail-pz0-f41.google.com with SMTP id 4so3779922pzk.0 for ; Mon, 27 Jun 2011 10:43:57 -0700 (PDT) In-Reply-To: <4E082041.6080709@christianmoe.com> (Christian Moe's message of "Mon, 27 Jun 2011 08:16:33 +0200") 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: mail@christianmoe.com Cc: emacs-orgmode@gnu.org Christian Moe writes: > Fixed, thanks. I should have guessed that might be it. > > Evaluating inline calls now works, but there are some ramifications > for output and export that I hadn't thought about when I seconded the > request. > > > * Export > > The call itself should not be exported, but I'm seeing: > > :

> : Here is a callsquare(it=4) 16 stuck in the > middle of some prose. > :

> > > * Output > > To get rid of the literal equals-signs, I try: > > : Here is a call_square(it=4)[:results raw] stuck in the middle of > some prose. > > I expect to get the result inline, but instead it comes as a normal > call results block (aligned with the call): > > : #+results: square(it=4) > : 16 > Hi Christian, Thanks for sharing these issues, it appears I messed some functionality up with some of my recent changes. I believe that I have fixed these issues. The following examples should now all export as described. --8<---------------cut here---------------start------------->8--- The following exports as a normal call line #+call: double(it=1) Now here is an inline call call_double(it=1) stuck in the middle of some prose. This one should not be exported =call_double(it=2)= because it is quoted. Finally this next one should export, even though it starts a line call_double(it=3) because sometimes inline blocks fold with a paragraph. And, a call with raw results call_double(4)[:results raw] should not have quoted results. --8<---------------cut here---------------end--------------->8--- Please let me know if you experience any more problems, and thanks for helping to get this sorted before the impending release! Cheers -- Eric > > > Yours, > Christian > > On 6/27/11 2:14 AM, Eric Schulte wrote: >>> >>> But I seem to have a problem (running your example): >>> >>> Debugger entered--Lisp error: (invalid-function (nonempty (a b) (let >>> ((it (match-string a))) (if (= (length it) 0) (match-string b) it)))) >>> (nonempty (a b) (let (...) (if ... ... it)))() >>> org-babel-lob-get-info() >>> org-babel-lob-execute-maybe() >>> org-babel-execute-maybe() >>> org-babel-execute-safely-maybe() >>> run-hook-with-args-until-success(org-babel-execute-safely-maybe) >>> org-ctrl-c-ctrl-c(nil) >>> call-interactively(org-ctrl-c-ctrl-c nil nil) >>> >> >> I believe this is due to my forgetting to require 'cl at compile time. >> I've just pushed up a fix, please let me know if the problem persists. >> >> Thanks -- Eric >> > -- Eric Schulte http://cs.unm.edu/~eschulte/