1

I like the short notation of org-babel function calls. E.g. you can define a named code block like this

#+name: get_date
#+begin_src http
GET http://date.jsontest.com
#+end_src

and then hit C-c C-c in some inline call to get the results for some parameters (if it's a single line result that is):

call_get_date[:select ".date"]() {{{results(=12-06-2016=)}}}

Or you can even do the code definition inline thus getting rid of 4 more lines:

src_http[:select ".date"]{GET http://date.jsontest.com} {{{results(=12-06-2016=)}}}

I find that is pretty cool, and I would like to use it more often. But I don't see a way to set a name for the inline result to reference it for later :var assignments. Is there any? Or is there some simple elisp which could be employed here?

  • 2
    "Inline code blocks don't associate themselves with their results, they are only expected to be evaluated during export" (org-babel.readthedocs.io/en/latest/eval/#inline-code-blocks) – mutbuerger Dec 6 '16 at 12:53
  • Thanks, I didn't know that documentation. Then it seems I've to write my elisp for that. I'm not so much interested in the export in this case, because I just want to automate some maintenance tasks. I guess this shows that org-babel is heavily build upon the needs of the research community, not so much on developers and administrators. – David Ongaro Dec 6 '16 at 20:25
2

(Not a solution, just digging into the problem.)

One can actually assign a name to an intermediate result with #+name:

#+name: callgetdate
call_get_date[:select .date]()

then the result will be tagged with the name, and a later call_callgetdate() will not complain/give an error. BUT in my tests, this later call always gave nil results. Idem for the src_ case.

I think this is a bug/irregularity in org.

The same happened for me with the longer version of #+call:.

#+name: callgetdate2
#+call: get_date[:select .date]
#+RESULTS: callgetdate2
# ... The expected json date ...

but:

call_callgetdate2()
#+RESULTS:
: nil

So this is not only related to inline blocks.

0

Might be a little late to add something, but here is the solution which is working for me. One can just put a #+results: somename header in front of the paragraph containing the inline result. The following elisp function can then be used to extract the value:

(defun get-inline-result (name)
  (save-excursion
    (org-babel-goto-named-result name)
    (re-search-forward "{{{results(=\\(.*?\\)=)}}}")
    (match-string 1)))

If you have more than one inline result per paragraph I guess you're still stuck or you have come up with an own inline-naming syntax and a corresponding elisp function to match it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.