From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Rettke Subject: Re: Evaluating inline source blocks on export issue Date: Fri, 25 Jul 2014 13:01:05 -0500 Message-ID: References: <87sils9rf7.fsf@gmail.com> <87lhrja6qo.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAjno-0008RO-EN for emacs-orgmode@gnu.org; Fri, 25 Jul 2014 14:01:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAjnm-0002xG-TB for emacs-orgmode@gnu.org; Fri, 25 Jul 2014 14:01:08 -0400 Received: from mail-oi0-x22e.google.com ([2607:f8b0:4003:c06::22e]:50830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAjnm-0002x9-OA for emacs-orgmode@gnu.org; Fri, 25 Jul 2014 14:01:06 -0400 Received: by mail-oi0-f46.google.com with SMTP id i138so3594497oig.5 for ; Fri, 25 Jul 2014 11:01:05 -0700 (PDT) In-Reply-To: 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: Ista Zahn Cc: Andreas Leha , emacs-orgmode Mailinglist Understood. Somehow got the call syntax suck in my head and didn't see that the underscore named syntax only works for LoB stuff and works perfectly when you just make a plain old language call. Thanks! This feature is really, really important. Grant Rettke | ACM, ASA, FSF, IEEE, SIAM gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/ =E2=80=9CWisdom begins in wonder.=E2=80=9D --Socrates ((=CE=BB (x) (x x)) (=CE=BB (x) (x x))) =E2=80=9CLife has become immeasurably better since I have been forced to st= op taking it seriously.=E2=80=9D --Thompson On Thu, Jul 24, 2014 at 8:53 PM, Ista Zahn wrote: > On Thu, Jul 24, 2014 at 6:14 AM, Andreas Leha > wrote: >> Nick Dokos writes: >> >>> Grant Rettke writes: >>> >>>> Thanks for looking Thomas and Nick. >>>> >>>> When I set this and export >>>> >>>> ,---- >>>> | (setq org-export-babel-evaluate t) >>>> `---- >>>> >>>> I get the expected result of >>>> >>>> ,---- >>>> | Here is a `16', stuck in the middle of some prose. >>>> `---- >>>> >>>> But when I do this and export >>>> >>>> ,---- >>>> | (setq org-export-babel-evaluate 'inline-only) >>>> `---- >>>> >>>> I get this output which is not what I expected >>>> >>>> ,---- >>>> | Here is a , stuck in the middle of some prose. >>>> `---- >>>> >>>> I thought that I was enabling inline code block execution correctly >>>> and making the inline call correctly. >>>> >>>> How does it look should it be doing what I had wanted? >>>> >>> >>> I don't think you can: the `type' (see below) of the inline code is not >>> `inline' as one might think at first, but `lob', presumably because >>> call_foo is defined in the library-of-babel. >>> >>> The relevant code is in ob-exp.el:org-babel-exp-results: >>> >>> ,---- >>> | ... >>> | (when (and (or (eq org-export-babel-evaluate t) >>> | (and (eq type 'inline) >>> | (eq org-export-babel-evaluate 'inline-only))) >>> | (not (and hash (equal hash (org-babel-current-result-hash)))= )) >>> | ... >>> `---- >> >> Then I would like to turn this into a feature request: Enable >> inline-block-specific settings. > > I'm not sure if this solves your problem, but > > --8<---------------cut here---------------start------------->8--- > #+name: squareFun > #+begin_src emacs-lisp :exports none > (defun square (it) (* it it)) > #+end_src > > #+RESULTS: squareFun > : square > > Here is a src_emacs-lisp{(square 10)}, from an inline source block. > --8<---------------cut here---------------end--------------->8--- > > does work with org-export-babel-evaluate set to 'inline-only. You do > have to evaluate the squareFun block before exporting. > > Best, > Ista > > > >> >> This does not only hold for the evaluation, but also for default header >> arguments. Different settings for inline code are quite useful. I do >> have to specify [:results raw] on the block-to-block basis quite a lot >> and would benefit a lot from global inline-specific settings. >> >> As always, point me to the way to do it, if (quite likely) this is >> possible already. >> >> Regards, >> Andreas >> >> >