link abbreviation with multiple params, e. g. for geo locations

link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi all

I suggest that the Org link abbreviation supports multiple and
repeated parameters so that it can handle more than the one and only
parameter %s as of now. What I have in mind is to abbreviate the URL

[[http://maps.google.com/maps?ll=4.56,7.89&spn=0.3,0.3&q=4.56,7.89]]

this way

: #+LINK: geo http://maps.google.com/maps?ll=%1&spn=%2,%2&q=%1
: [[geo:4.56,7.89&0.3]]

where & in the Org link is the separator of the parameters %1 and %2.
Note the repeated use of %1 and %2 in this case which is a good part
of the convenience. I tried with a workaround URL that by itself would
work

[[http://maps.google.com/maps?ll=4.56,7.89&spn=0.3,0.3&q=4.56,7.89&spn=0.3,0.3]]

with the repeated spn. But below the second %s remains without
replacement which means the marker in the map gets lost when trying
this with release_8.0.2-72-gccfe83:

#+LINK: geo http://maps.google.com/maps?ll=%s&q=%s
[[geo:4.56,7.89&spn=0.3,0.3]]

Does it make sense to put at least repeatable %s, but then also
multiple and repeatable parameters for link abbreviations to the wish
list? Or did I miss something else that supports also
org-open-at-point, maybe Org macros?

I am not sure if %1 %2 etc. for the parameters is a good choice since
it might interfere with escaped chars in #+LINK. Maybe &1 &2 etc.
interfere less because the & to separate URL parameters are followed
mostly by letters, as well as the & in HTML entities, AFAIK.

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Christian Moe]

Michael Brand writes:

> Does it make sense to put at least repeatable %s, but then also
> multiple and repeatable parameters for link abbreviations to the wish
> list? Or did I miss something else that supports also
> org-open-at-point, maybe Org macros?

When link abbreviations do not suffice, you can always write a link
definition in Lisp and add it with org-add-link-type.

For explanation and a practical example see:

info:org#Adding%20hyperlink%20types

Yours,
Christian

PS. If Org were to add a default geo: link type, I think it would make
sense to keep the parameters to a minimum, i.e. just the latitude and
longitude, without backend-dependent options such as Google Maps' "spn"
parameter. Though I can see how it would be useful.

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

On Mon, May 6, 2013 at 9:06 AM, Christian Moe <mail@christianmoe.com> wrote:

> PS. If Org were to add a default geo: link type, I think it would make
> sense to keep the parameters to a minimum, i.e. just the latitude and
> longitude, without backend-dependent options such as Google Maps' "spn"
> parameter. Though I can see how it would be useful.

Good point, agreed. So what I am trying to do is less about a link
type "geo location" but more about possibly having several different
visualizations of one single geo location.

> When link abbreviations do not suffice, you can always write a link
> definition in Lisp and add it with org-add-link-type.

Thinking about this and my previous post I conclude that Org babel is
just perfect for my use case. Well, as a beginner of Org babel I am
not yet there completely and would like to ask for help on the source
block header:

--------------------------------------------
* Org babel function for Google Maps browser
  #+NAME: gmb
  #+HEADER: :var ty="m" spn=0.2
  #+HEADER: :var geo_var=(or (org-entry-get nil "geo") "4.56,7.89")
  #+BEGIN_SRC emacs-lisp :results silent
    (browse-url
     (concat "http://maps.google.ch/maps?t=" ty
             "&spn=" (number-to-string spn) "," (number-to-string spn)
             "&ll=" geo_var "&q=" geo_var))
  #+END_SRC
* example of a geo location, realistic to try out
  :PROPERTIES:
  :geo:      4.56,7.89
  :END:
  - call_gmb()
    - interactively (type C-c on "call_gmb") visualize the current geo
      location on Google Maps with a marker and as "map" in the
      browser
  - call_gmb(ty="k", spn=0.002)
    - visualize the same geo location on Google Maps with a marker, as
      "satellite image" and with a certain scale suitable for this
      specific geo location and view type
* another geo location
  :PROPERTIES:
  :geo:      4.44,5.55
  :END:
  - call_gmb(ty="p")
    - visualize another geo location as "terrain"
--------------------------------------------

The issue is that org-entry-get returns nil instead of the value of
the item property :geo:, therefore my "demo workaround" with the "or"
to show the principle of "gmb". How to resolve this properly?

Isn't there something like "#+HEADER: :var geo_var=:geo:" to copy the
value of the item property :geo: to the babel variable unless
specified by the caller?

Not sure yet how to support export of such geo locations to a GPS
track... That would probably be "simply" all item properties :geo:
with the item's name and nothing else. Probably quite a boring
exercise of writing a new exporter backend for someone who would know
how to do it...

Btw. I re-found the Org mode mailing list thread
[2010-06-29 Tue] "Getting a Google Maps' map for an entry"
http://thread.gmane.org/gmane.emacs.orgmode/26797
by Julien Danjou, currently to be found at
http://julien.danjou.info/projects/emacs-packages#google-maps
It can also be used as a backend to visualize a geo location and
demonstrates the usage of the interesting Google Maps Static Maps API
that converts a Google Maps URL to an image:
https://developers.google.com/maps/documentation/staticmaps/#quick_example

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Christian Moe]

Michael Brand writes:
>
> Thinking about this and my previous post I conclude that Org babel is
> just perfect for my use case.

If you want to pass a variety of named parameters, that may be true.

On the other hand, since you end up typing the parameter names anyway,
the absolutely simplest way to get the behavior you want might simply be
something like:

: #+LINK: gmap http://maps.google.ch/maps?

: [[gmap:t=p&spn=0.2,0.2&ll=13.0,14.3&q=13.0,14.3]]

>  Well, as a beginner of Org babel I am
> not yet there completely and would like to ask for help on the source
> block header:
> [...]
> The issue is that org-entry-get returns nil instead of the value of
> the item property :geo:, therefore my "demo workaround" with the "or"
> to show the principle of "gmb". How to resolve this properly?

For starters, see the docstring for org-entry-get; it expects a
point-or-marker as the first argument, but you are passing nil. 

I'm afraid knowing that doesn't help much. The problem is, you don't know
what point the inline call is at, so you cannot point org-entry-get to
the right entry. If you try

: (org-entry-get (point) "geo")

it will look for a geo property in the outline entry the source block is
in, not in the entry the call comes from.

I don't know any easy way to pass a parameter to a source block from an
outline entry property via an inline call in that entry. Others may know
better.

>
> Isn't there something like "#+HEADER: :var geo_var=:geo:" to copy the
> value of the item property :geo: to the babel variable unless
> specified by the caller?

Afraid not. 

Yours,
Christian

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Hi all

On Tue, May 7, 2013 at 12:29 AM, Christian Moe <mail@christianmoe.com> wrote:
> I'm afraid knowing that doesn't help much. The problem is, you don't know
> what point the inline call is at, so you cannot point org-entry-get to
> the right entry. If you try
>
> : (org-entry-get (point) "geo")
>
> it will look for a geo property in the outline entry the source block is
> in, not in the entry the call comes from.
>
> I don't know any easy way to pass a parameter to a source block from an
> outline entry property via an inline call in that entry. Others may know
> better.

After some trials it seemed to me that it is enough to just add a "loc
(point-marker)" to a "let" of org-babel-ref-resolve. Now when the Lisp
variable loc ("Location Of Call") is used as the first argument of
org-entry-get it reads the property from that entry where the code
block has been called. With this, Babel perfectly covers every
requirement of my use case described earlier in this thread.

Please review and comment my attached patch containing doc and ERT.

Michael

[-- Attachment #2: 0001-Entry-properties-as-code-block-arguments-in-Babel.patch.txt --]
[-- Type: text/plain, Size: 4160 bytes --]

From 178d8c7100176561a395d545c193ea36225ab81c Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Wed, 22 May 2013 18:59:24 +0200
Subject: [PATCH] Entry properties as code block arguments in Babel

* doc/org.texi (var): Document loc ("Location Of Call").
* lisp/ob-ref.el (org-babel-ref-resolve): Add `loc' which is set to
point as a marker object.
* testing/examples/babel.org: Add test entry for ERT.
* testing/lisp/test-ob-exp.el: Add expected code block results for
ERT.
---
 doc/org.texi                |    9 +++++++++
 lisp/ob-ref.el              |    4 +++-
 testing/examples/babel.org  |   30 ++++++++++++++++++++++++++++++
 testing/lisp/test-ob-exp.el |    8 ++++++++
 4 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 290c671..29362cd 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14381,6 +14381,15 @@ evaluation of the code block body.
 #+END_SRC
 @end example
 
+Within Emacs Lisp evaluation the Lisp variable @code{loc} provides the
+``Location Of Call'' as a marker object which can be passed for example to
+the Lisp function @code{org-entry-get} to read a property from that entry
+where the code block has been called:
+
+@example
+#+HEADERS: :var todo_state=(org-entry-get loc "TODO" t)
+@end example
+
 Note that values read from tables and lists will not be evaluated as
 Emacs Lisp, as shown in the following example.
 
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index a2814ea..9645b9e 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -124,7 +124,9 @@ the variable."
     (save-excursion
       (let ((case-fold-search t)
 	    type args new-refere new-header-args new-referent result
-	    lob-info split-file split-ref index index-row index-col id)
+	    lob-info split-file split-ref index index-row index-col id
+	    ;; For Emacs Lisp evaluation of :var, see Org manual.
+	    (loc (point-marker)))
 	;; if ref is indexed grab the indices -- beware nested indices
 	(when (and (string-match "\\[\\([^\\[]+\\)\\]$" ref)
 		   (let ((str (substring ref 0 (match-beginning 0))))
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index 7c30ab2..8b18c3f 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -359,3 +359,33 @@ Here is a call line with more than just the results exported.
   <<strip-export-1>>
   echo "1$i"
 #+END_SRC
+
+* Emacs Lisp evaluation of :var with "loc" (Location Of Call)
+  :PROPERTIES:
+  :ID:       cc5fbc20-bca5-437a-a7b8-2b4d7a03f820
+  :END:
+
+#+NAME: func
+#+HEADERS: :var a=(string-to-number (or (org-entry-get loc "a" t) "0"))
+#+HEADERS: :var b=(string-to-number (or (org-entry-get loc "b" t) "0"))
+#+HEADERS: :var c=(string-to-number (or (org-entry-get loc "c" t) "0"))
+#+HEADERS: :var d=(string-to-number (or (org-entry-get loc "d" t) "0"))
+#+HEADERS: :var e=(string-to-number (or (org-entry-get loc "e" t) "0"))
+#+BEGIN_SRC emacs-lisp
+  (message "a:%d, b:%d, c:%d, d:%d, e:%d" a b c d e)
+#+END_SRC
+
+** section
+   :PROPERTIES:
+   :a:        1
+   :c:        3
+   :END:
+- section: call_func()
+
+*** subsection
+    :PROPERTIES:
+    :b:        2
+    :c:        4
+    :END:
+- subsec1: call_func()
+- subsec2: call_func(c=5, e=6)
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index abfe230..ea671f0 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -216,6 +216,14 @@ Here is one at the end of a line. =2=
       (should-not (string-match (regexp-quote "<<strip-export-1>>") result))
       (should-not (string-match (regexp-quote "i=\"10\"") result)))))
 
+(ert-deftest ob-exp/location-of-call ()
+  (org-test-at-id "cc5fbc20-bca5-437a-a7b8-2b4d7a03f820"
+    (org-narrow-to-subtree)
+    (let ((result (org-test-with-expanded-babel-code (buffer-string))))
+      (should (string-match "section: =a:1, b:0, c:3, d:0, e:0=" result))
+      (should (string-match "subsec1: =a:1, b:2, c:4, d:0, e:0=" result))
+      (should (string-match "subsec2: =a:1, b:2, c:5, d:0, e:6=" result)))))
+
 (ert-deftest ob-exp/export-from-a-temp-buffer ()
   :expected-result :failed
   (org-test-with-temp-text
-- 
1.7.4.2

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Wed, May 22, 2013 at 7:03 PM, Michael Brand
<michael.ch.brand@gmail.com> wrote:
> Please review and comment my attached patch containing doc and ERT.

As there has been no answer yet from anyone else: Could you please
read this thread and review my Babel patch? I guess that you did not
follow the thread because the subject and the first two posts are
non-Babel.

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Wed, May 29, 2013 at 6:14 PM, Michael Brand
<michael.ch.brand@gmail.com> wrote:
> Hi Eric
>
> On Wed, May 22, 2013 at 7:03 PM, Michael Brand
> <michael.ch.brand@gmail.com> wrote:
>> Please review and comment my attached patch containing doc and ERT.
>
> As there has been no answer yet from anyone else: Could you please
> read this thread and review my Babel patch? I guess that you did not
> follow the thread because the subject and the first two posts are
> non-Babel.
>
> Michael

I don't expect a review within a few days but it would help me to know
whether you or somebody else plans to look at my two weeks old patch.

One of the emails in the thread misses a "References" in the email
header but the following URL gives a complete list of all messages of
this thread:
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=link+abbreviation+with+multiple+params%2C+e.+g.+for+geo+locations&submit=Search!&idxname=emacs-orgmode&max=100&result=normal&sort=date%3Aearly

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi all
>
> On Tue, May 7, 2013 at 12:29 AM, Christian Moe <mail@christianmoe.com> wrote:
>> I'm afraid knowing that doesn't help much. The problem is, you don't know
>> what point the inline call is at, so you cannot point org-entry-get to
>> the right entry. If you try
>>
>> : (org-entry-get (point) "geo")
>>
>> it will look for a geo property in the outline entry the source block is
>> in, not in the entry the call comes from.
>>
>> I don't know any easy way to pass a parameter to a source block from an
>> outline entry property via an inline call in that entry. Others may know
>> better.
>
> After some trials it seemed to me that it is enough to just add a "loc
> (point-marker)" to a "let" of org-babel-ref-resolve. Now when the Lisp
> variable loc ("Location Of Call") is used as the first argument of
> org-entry-get it reads the property from that entry where the code
> block has been called. With this, Babel perfectly covers every
> requirement of my use case described earlier in this thread.
>
> Please review and comment my attached patch containing doc and ERT.
>

Please forgive my lateness to this thread.  Is the only requirement that
the point from which a code block was called be accessible to the
emacs-lisp code executed within that code block?

If so then there should be no need for additional development.  The
following already works thanks to some very recently applied changes.
See the attached example which demonstrates how to access the point of
the original call from a code block.

Cheers,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-entry-get-point-example.org --]
[-- Type: text/x-org, Size: 798 bytes --]

#+Options: ^:{}

* Org babel function for Google Maps browser

Here I simplify the previous Google maps function to simply
demonstrate the recovery of entry properties.

#+NAME: gmb
#+HEADER: :var geo_var=(or (org-entry-get org-babel-current-exec-src-block-head "geo") "4.56,7.89")
#+BEGIN_SRC emacs-lisp :results silent
  (format "geo_var is %s" geo_var)
#+END_SRC

* example of a geo location, realistic to try out
  :PROPERTIES:
  :geo:      4.56,7.89
  :END:

- call_gmb() =geo_var is 4.56,7.89=
  - interactively (type C-c on "call_gmb") visualize the current geo
    location on Google Maps with a marker and as "map" in the
    browser

* another geo location
  :PROPERTIES:
  :geo:      4.44,5.55
  :END:

- call_gmb() =geo_var is 4.44,5.55=
  - visualize another geo location as "terrain"

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

Thank you for looking into this.

On Thu, Jun 6, 2013 at 7:01 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> Is the only requirement that
> the point from which a code block was called be accessible to the
> emacs-lisp code executed within that code block?

Yes.

> If so then there should be no need for additional development.  The
> following already works thanks to some very recently applied changes.

Is release_8.0.3-207-g5dc5143 the change you mention?:

    commit 5dc5143578a2759611a5856de9bf9d1c7eba9283
    Author: Eric Schulte <schulte.eric@gmail.com>
    Date:   Thu Jun 6 10:59:27 2013 -0600

        inline sets org-babel-current-exec-src-block-head

In this commit I see two issues which my patch does not have:

1) The variable name org-babel-current-exec-src-block-head is the same
   as for a different meaning (source block head) and purpose introduced
   in release_8.0.3-202-gf301bbc

       commit f301bbcc862c2acc61749bc1e24895bf69cd4d06
       Author: Vitalie Spinu <spinuvit@gmail.com>
       Date:   Thu Jun 6 12:04:02 2013 +0200

           make src block location available to execution backends

   but in release_8.0.3-207-g5dc5143 the same name is used for the
   point-marker of "call_func" which is misleading. In my patch I
   named the variable "loc" for Location Of Call. And I chose
   intentionally a name as short as possible to keep the "#+HEADER:"
   lines not getting too wide, see e. g. the ERT in my patch.

2) Export is not supported ("C-c C-c" works as expected).

Just today I saw a possible improvement for my patch: For a more
general usage of "loc" than only for org-entry-get it would be better
if "loc" in export would not contain the location of the entry start
but the exact location of possibly more than one call within the same
entry. For "C-c C-c" this is already the case. Since I don't know how
to resolve this I would let it as is for now unless there is a
suggestion.

I would like to provide a new patch if I know what else should be
improved.

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

Hi Michael,

>
> Is release_8.0.3-207-g5dc5143 the change you mention?:
>

yes

>
>     commit 5dc5143578a2759611a5856de9bf9d1c7eba9283
>     Author: Eric Schulte <schulte.eric@gmail.com>
>     Date:   Thu Jun 6 10:59:27 2013 -0600
>
>         inline sets org-babel-current-exec-src-block-head
>
> In this commit I see two issues which my patch does not have:
>
> 1) The variable name org-babel-current-exec-src-block-head is the same
>    as for a different meaning (source block head) and purpose introduced
>    in release_8.0.3-202-gf301bbc
>
>        commit f301bbcc862c2acc61749bc1e24895bf69cd4d06
>        Author: Vitalie Spinu <spinuvit@gmail.com>
>        Date:   Thu Jun 6 12:04:02 2013 +0200
>
>            make src block location available to execution backends
>
>    but in release_8.0.3-207-g5dc5143 the same name is used for the
>    point-marker of "call_func" which is misleading.

Perhaps the variable name should be updated, but this extension is
simply a generalization to include inline code blocks as well.  I don't
find it misleading.

>    In my patch I named the variable "loc" for Location Of Call.

In the technical pigeon spoken in my own circles loc has a well
established meaning, namely "line of code".

>    And I chose intentionally a name as short as possible to keep the
>    "#+HEADER:" lines not getting too wide, see e. g. the ERT in my
>    patch.
>
> 2) Export is not supported ("C-c C-c" works as expected).
>

I can't reproduce this bug.  The following Org-mode file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: export-loc.org --]
[-- Type: text/x-org, Size: 438 bytes --]

# #+PROPERTY: exports results

# Two examples using `org-babel-current-exec-src-block-head'.

* head
  :PROPERTIES:
  :foo:      bar
  :END:

In a block.
#+name: head
#+begin_src emacs-lisp
  (org-entry-get org-babel-current-exec-src-block-head "foo")
#+end_src

In a call line.
#+call: head()

* tail
  :PROPERTIES:
  :foo:      baz
  :END:

#+begin_src emacs-lisp
  (org-entry-get org-babel-current-exec-src-block-head "foo")
#+end_src

[-- Attachment #3: Type: text/plain, Size: 1168 bytes --]


exports to the following latex

    % -*- latex -*-
    \section{head}
    \label{sec-1}

    In a block.
    \begin{verbatim}
    bar
    \end{verbatim}

    In a call line.
    \begin{verbatim}
    bar
    \end{verbatim}
    \section{tail}
    \label{sec-2}

    \begin{verbatim}
    baz
    \end{verbatim}

Although I think there may well be improvements to be made to the
current approach, e.g. a different variable name, or saving a list of
call locations instead of just the first call location, I've yet to see
a motivating example where the existing solution is inadequate.

Thanks,

>
> Just today I saw a possible improvement for my patch: For a more
> general usage of "loc" than only for org-entry-get it would be better
> if "loc" in export would not contain the location of the entry start
> but the exact location of possibly more than one call within the same
> entry. For "C-c C-c" this is already the case. Since I don't know how
> to resolve this I would let it as is for now unless there is a
> suggestion.
>
> I would like to provide a new patch if I know what else should be
> improved.
>
> Michael

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Fri, Jun 7, 2013 at 5:18 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> In this commit I see two issues which my patch does not have:
>>
>> 1) The variable name org-babel-current-exec-src-block-head is the same
>>    as for a different meaning (source block head) and purpose introduced
>>    in release_8.0.3-202-gf301bbc
>>
>>        commit f301bbcc862c2acc61749bc1e24895bf69cd4d06
>>        Author: Vitalie Spinu <spinuvit@gmail.com>
>>        Date:   Thu Jun 6 12:04:02 2013 +0200
>>
>>            make src block location available to execution backends
>>
>>    but in release_8.0.3-207-g5dc5143 the same name is used for the
>>    point-marker of "call_func" which is misleading.
>
> Perhaps the variable name should be updated, but this extension is
> simply a generalization to include inline code blocks as well.  I don't
> find it misleading.

Aha, now it seems to me that I must have misunderstood the variable
name org-babel-current-exec-src-block-head as introduced with the
first commit release_8.0.3-202-gf301bbc. Because of the "src-block"
and "head" in the name and because this commit was made for debugging
I thought that the variable refers to point-marker of the one and only
named code block with the #+HEADER, in my thinking the "function
definition" to be debugged.

Is this understanding wrong and the variable refers to point-marker of
just every code block evaluation individually, not only in the changes
for release_8.0.3-207-g5dc5143 but also in the changes for
release_8.0.3-202-gf301bbc ?

If yes then I understand only now that the functionality of the new
variable is of course the same for the changes in both commits and
therefore the name has to be the same for the changes in both commits.
But for me it would have helped to have some other name, containing
neither "src-block", which I associate it with #+BEGIN_SRC but
not #+CALL line or inline call_<name>, nor "head", which I associate
with #+HEADER. I would like to suggest org-babel-exec-marker. What do
you and Vitalie (CCed) think?

>> 2) Export is not supported ("C-c C-c" works as expected).
>
> I can't reproduce this bug.

From your attached org-entry-get-point-example.org I get with some
lines omitted

\section{example of a geo location, realistic to try out}
\item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
\section{another geo location}
\item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.44,5.55}

but expect

\section{example of a geo location, realistic to try out}
\item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
\section{another geo location}
\item \texttt{geo\_var is 4.44,5.55} \texttt{geo\_var is 4.44,5.55}

Changing to

#+HEADER: :var geo_var=(format "%s" org-babel-current-exec-src-block-head)

shows that the variable is nil.

> The following Org-mode file.
>
> exports to the following latex

From your attached export-loc.org I get the same evaluations after
uncommenting "#+PROPERTY: exports results"

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Vitalie Spinu]

 >> Michael Brand <michael.ch.brand@gmail.com>
 >> on Fri, 7 Jun 2013 21:16:00 +0200 wrote:

[...]

 >> 
 >> Perhaps the variable name should be updated, but this extension is
 >> simply a generalization to include inline code blocks as well.  I don't
 >> find it misleading.

[...]


 > If yes then I understand only now that the functionality of the new
 > variable is of course the same for the changes in both commits and
 > therefore the name has to be the same for the changes in both commits.
 > But for me it would have helped to have some other name, containing
 > neither "src-block", which I associate it with #+BEGIN_SRC but
 > not #+CALL line or inline call_<name>, nor "head", which I associate
 > with #+HEADER. I would like to suggest org-babel-exec-marker. What do
 > you and Vitalie (CCed) think?

I named it with "head" because head is the local variable in
org-babel-get-src-block-info referring to that position.  There are
other functions that use -head: org-babel-goto-src-block-head,
org-babel-where-is-src-block-head. 

But, I agree that it might be better called beg, location or position.

I think "src-block" is not misleading, there are plenty of
foo-src-block-bar in babel. 

May be then:  org-babel-current-src-block-location?

The -exec- part stands for -executed- and, might be drop.

It should be explicitly named because this is a global variable which is
bound only during the processing of src-blocks, simply 'loc wouldn't
work.

    Vitalie

Re: link abbreviation with multiple params, e. g. for geo locations

[Achim Gratz]

Michael Brand writes:
> But for me it would have helped to have some other name, containing
> neither "src-block", which I associate it with #+BEGIN_SRC but
> not #+CALL line or inline call_<name>, nor "head", which I associate
> with #+HEADER.

There are multiple places in Babel where "src-block-head" means "the
header arguments to a Babel invocation".  You'd have to look at the
history when separate header lines and inline calls were introduced, but
I think you'll find the reason for the naming somewhere in the past.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

>>> 2) Export is not supported ("C-c C-c" works as expected).
>>
>> I can't reproduce this bug.
>
> From your attached org-entry-get-point-example.org I get with some
> lines omitted
>
> \section{example of a geo location, realistic to try out}
> \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
> \section{another geo location}
> \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.44,5.55}
>
> but expect
>
> \section{example of a geo location, realistic to try out}
> \item \texttt{geo\_var is 4.56,7.89} \texttt{geo\_var is 4.56,7.89}
> \section{another geo location}
> \item \texttt{geo\_var is 4.44,5.55} \texttt{geo\_var is 4.44,5.55}
>

I've just pushed up a commit which should fix this problem.  The
org-babel-current-exec-src-block-head variable wasn't bound during
export.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

>  > If yes then I understand only now that the functionality of the new
>  > variable is of course the same for the changes in both commits and
>  > therefore the name has to be the same for the changes in both commits.
>  > But for me it would have helped to have some other name, containing
>  > neither "src-block", which I associate it with #+BEGIN_SRC but
>  > not #+CALL line or inline call_<name>, nor "head", which I associate
>  > with #+HEADER. I would like to suggest org-babel-exec-marker. What do
>  > you and Vitalie (CCed) think?
>
> I named it with "head" because head is the local variable in
> org-babel-get-src-block-info referring to that position.  There are
> other functions that use -head: org-babel-goto-src-block-head,
> org-babel-where-is-src-block-head. 
>
> But, I agree that it might be better called beg, location or position.
>
> I think "src-block" is not misleading, there are plenty of
> foo-src-block-bar in babel. 
>
> May be then:  org-babel-current-src-block-location?
>

How about the shorter `org-babel-current-src-block'?  It is somewhat
more ambiguous, but the only reasonable options would be location or
name, and not every code block has a name.  I think the added brevity is
worth the ambiguity, but I'm not strongly committed either way.

I'll happily commit whatever is generally appealing.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Vitalie Spinu]

 >> Eric Schulte <schulte.eric@gmail.com>
 >> on Sat, 08 Jun 2013 12:05:32 -0600 wrote:

[...]

 >> 
 >> May be then:  org-babel-current-src-block-location?
 >> 

 > How about the shorter `org-babel-current-src-block'?  It is somewhat
 > more ambiguous, but the only reasonable options would be location or
 > name, and not every code block has a name.  I think the added brevity is
 > worth the ambiguity, but I'm not strongly committed either way.

I personally find it quite confusing.  Babel names that contain
src-block semantically refer to the whole thing. This one refers to the
pointer. If brevity is very important I would rather drop "current":

    `org-babel-src-block-location'

or probably even more suggestive:

    `org-babel-src-block-beginning'.


    Vitalie

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

Vitalie Spinu <spinuvit@gmail.com> writes:

>  >> Eric Schulte <schulte.eric@gmail.com>
>  >> on Sat, 08 Jun 2013 12:05:32 -0600 wrote:
>
> [...]
>
>  >> 
>  >> May be then:  org-babel-current-src-block-location?
>  >> 
>
>  > How about the shorter `org-babel-current-src-block'?  It is somewhat
>  > more ambiguous, but the only reasonable options would be location or
>  > name, and not every code block has a name.  I think the added brevity is
>  > worth the ambiguity, but I'm not strongly committed either way.
>
> I personally find it quite confusing.  Babel names that contain
> src-block semantically refer to the whole thing. This one refers to the
> pointer. If brevity is very important I would rather drop "current":
>
>     `org-babel-src-block-location'
>
> or probably even more suggestive:
>
>     `org-babel-src-block-beginning'.
>

I like "current" because it is similar to other variables which are
dynamically bound by Org-mode and without it there is no indication that
it points to a block which is active *now*.

I've changed the variable name to your previous suggestion of
`org-babel-current-src-block-location'.  If anyone really wants brevity
they can add the following to their config.

    ;; -*- emacs-lisp -*-
    (defun loc () org-babel-current-src-block-location)

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> I've just pushed up a commit which should fix this problem.  The
> org-babel-current-exec-src-block-head variable wasn't bound during
> export.

Confirmed, thanks. In the attached marker_offset.org the evaluation of
the variable todo-state-var during export did not work before, now it
does.

What I do not understand is the behavior of the evaluation of the
other variable marker-var. During "C-c C-c" it is like expected with
point >= 305 which means within entry "* s". But during export it is
far before 305 which confuses me. How can "DONE" instead of nil from
the previous entry be assigned to todo-state-var this way and is this
"displacement" to be accepted?

For me it is enough for now if the marker is just anywhere within the
current entry. I do not (yet?) have a use case where I need the marker
to be at an individual source block and therefore different when
calling a function twice in the same entry as in marker_offset.org
with calls "(a)" and "(b)".

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 139 bytes --]

On Sun, Jun 9, 2013 at 9:56 AM, Michael Brand
<michael.ch.brand@gmail.com> wrote:
> In the attached marker_offset.org

Sorry, forgot that.

[-- Attachment #2: marker_offset.org --]
[-- Type: application/octet-stream, Size: 345 bytes --]

* Babel function definition
#+NAME: func
#+HEADER: :var todo-state-var=(org-entry-get org-babel-current-src-block-location "TODO" nil)
#+HEADER: :var marker-var=(format "%s" org-babel-current-src-block-location)
#+BEGIN_SRC emacs-lisp :exports none
  (format "%s %s" todo-state-var marker-var)
#+END_SRC
* DONE s
call_func() (a)
call_func() (b)

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> I've just pushed up a commit which should fix this problem.  The
>> org-babel-current-exec-src-block-head variable wasn't bound during
>> export.
>
> Confirmed, thanks. In the attached marker_offset.org the evaluation of
> the variable todo-state-var during export did not work before, now it
> does.
>
> What I do not understand is the behavior of the evaluation of the
> other variable marker-var. During "C-c C-c" it is like expected with
> point >= 305 which means within entry "* s". But during export it is
> far before 305 which confuses me. How can "DONE" instead of nil from
> the previous entry be assigned to todo-state-var this way and is this
> "displacement" to be accepted?
>

Export buffers are sometimes modified or narrowed during the export
process, so I wouldn't depend too much on the absolute values of markers
generated during export.  As long as the heading in which the marker
lives seems to be correct I'd count it as a success.

>
> For me it is enough for now if the marker is just anywhere within the
> current entry. I do not (yet?) have a use case where I need the marker
> to be at an individual source block and therefore different when
> calling a function twice in the same entry as in marker_offset.org
> with calls "(a)" and "(b)".
>

Great.  If such a need arises, you could try setting the variable in the
src_call line, rather than relying on the value set in the main code
block.

Cheers,

BTW: I notice your Org file attached as application/vnd.lotus-organizer
(the default for .org in Emacs mime types).  I had this issue as well,
and I now use the following so that Org-mode files attach as org.

    ;; -*- emacs-lisp -*-
    (setf mailcap-mime-extensions
          (cons '(".org" . "text/x-org") mailcap-mime-extensions))

>
> Michael

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> Export buffers are sometimes modified or narrowed during the export
> process, so I wouldn't depend too much on the absolute values of markers
> generated during export.  As long as the heading in which the marker
> lives seems to be correct I'd count it as a success.

Ok.

Out of curiosity I also tried to assign a Lisp marker with :var

#+HEADER: :var marker-var=(identity org-babel-current-src-block-location)

which leads to

executing Emacs-Lisp code block (func)...
(marker-var (quote #<marker at 458 in marker_offset.org>))
eval: Invalid read syntax: "#"

Is such a Lisp marker supposed to work across a :var assignment? For
me it does not matter because either the variable
org-babel-current-src-block-location is better evaluated within the
source block or in the header I do not expect the value to be of much
use for source blocks other than Lisp. I just let you know in case you
wanted the assignment to work with other #-constructs or there was a
connection with the recent changes that temporarily required :shebang
quoting.

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

Michael Brand <michael.ch.brand@gmail.com> writes:

> Hi Eric
>
> On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> Export buffers are sometimes modified or narrowed during the export
>> process, so I wouldn't depend too much on the absolute values of markers
>> generated during export.  As long as the heading in which the marker
>> lives seems to be correct I'd count it as a success.
>
> Ok.
>
> Out of curiosity I also tried to assign a Lisp marker with :var
>
> #+HEADER: :var marker-var=(identity org-babel-current-src-block-location)
>
> which leads to
>
> executing Emacs-Lisp code block (func)...
> (marker-var (quote #<marker at 458 in marker_offset.org>))
> eval: Invalid read syntax: "#"
>

You'll get this if you do the following.

  ;; -*- emacs-lisp -*-
  (read-from-string (format "%s" (point-marker)))

This is because unlike most lisp objects, point markers can not be read
in the same syntax they print as.  Babel only supports passing strings,
numbers, and lists of strings and numbers as variables between code
blocks.  If you convert the point-marker to a point (integer) then it
will flow between blocks.

>
> Is such a Lisp marker supposed to work across a :var assignment? For
> me it does not matter because either the variable
> org-babel-current-src-block-location is better evaluated within the
> source block or in the header I do not expect the value to be of much
> use for source blocks other than Lisp. I just let you know in case you
> wanted the assignment to work with other #-constructs or there was a
> connection with the recent changes that temporarily required :shebang
> quoting.
>
> Michael

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Sat, Jun 8, 2013 at 9:21 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> Vitalie Spinu <spinuvit@gmail.com> writes:
>> [...]
>>     `org-babel-src-block-location'
>>
>> or probably even more suggestive:
>>
>>     `org-babel-src-block-beginning'.
>>
>
> I like "current" because it is similar to other variables which are
> dynamically bound by Org-mode and without it there is no indication that
> it points to a block which is active *now*.
>
> I've changed the variable name to your previous suggestion of
> `org-babel-current-src-block-location'.

Thanks to all for the clarifications about the name and the improved
docstring of org-babel-current-src-block-location. Now I see the good
reasons for the old and the new name.

According to this change and my better understanding I am rewriting
and extending the ERT from my previous patch to document my use case.
There is an issue with shell and :session that I do not know how to
deal with: In the following example when I do "C-c C-c" on #+BEGIN_SRC
the result is as expected but on the "#+CALL" lines it should be

: a:0
and
: a:1

The :session is only to have more than one call which works for
emacs-lisp source blocks. Am I doing something wrong or is this a bug?

------------------------------------------------------------
#+NAME: func
#+HEADER: :var a=(or (org-entry-get
org-babel-current-src-block-location "a" t) "0")
#+BEGIN_SRC sh :shebang #!/bin/sh :results verbatim
  echo "a:$a"
#+END_SRC

#+RESULTS: func
: a:0

#+CALL: func[:session default]()

#+RESULTS: func[:session default]()
:
: > > ^[]0;^Gbash-3.2$ a:0

* section
   :PROPERTIES:
   :a:        1
   :END:

#+CALL: func[:session property]()

#+RESULTS: func[:session property]()
:
: > > ^[]0;^Gbash-3.2$ a:1

------------------------------------------------------------

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Eric Schulte]

>
> The :session is only to have more than one call which works for
> emacs-lisp source blocks. Am I doing something wrong or is this a bug?
>

Sessions are not supported in every language.  Shell code blocks do
*not* support sessions (or rather it looks like someone started to
implement session support, but never completed it).

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

Hi Eric

On Fri, Jun 14, 2013 at 8:18 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> The :session is only to have more than one call which works for
>> emacs-lisp source blocks. Am I doing something wrong or is this a bug?
>
> Sessions are not supported in every language.  Shell code blocks do
> *not* support sessions (or rather it looks like someone started to
> implement session support, but never completed it).

Good to know. It is high on my wishlist. I often take notes about
shell and utilities and just a few days ago I planned to improve by
using, well, babel source blocks. Now I know that I have to use some
workaround. What about :var dummy_name?

#+NAME:     unicode_normal_form_c
#+HEADER:   :var dummy_name="workaround to get different result blocks"
#+BEGIN_SRC sh :shebang #!/bin/sh :eval no :exports code
  printf 'a\xcc\x88'                               | od -Ax -tx1
  printf 'a\xcc\x88' | iconv -f UTF-8-MAC -t UTF-8 | od -Ax -tx1
  printf 'a\xcc\x88' | iconv -f UTF-8-MAC -t UTF-8 2>&1 > /dev/null
  echo "(`uname`, `date +%Y-%m-%d`)"
#+END_SRC

- OS X (implementation of iconv by Apple, not e. g. MacPorts):
  #+CALL:    unicode_normal_form_c[:results output verbatim :eval
no-export :exports results](dummy_name="osx")

  #+RESULTS: unicode_normal_form_c[:results output verbatim :eval
no-export :exports results](dummy_name="osx")
  : 0000000    61  cc  88
  : 0000003
  : 0000000    c3  a4
  : 0000002
  : (Darwin, 2013-06-14)

- GNU/Linux:
  #+CALL:    unicode_normal_form_c[:results output verbatim :eval
no-export :exports results](dummy_name="gnu")

  #+RESULTS: unicode_normal_form_c[:results output verbatim :eval
no-export :exports results](dummy_name="gnu")
  : 000000 61 cc 88
  : 000003
  : 000000
  : iconv: conversion from `UTF-8-MAC' is not supported
  : Try `iconv --help' or `iconv --usage' for more information.
  : (Linux, 2013-06-14)

Is there a better workaround or would you accept :var dummy_name for
my ERT that I mentioned?

And how can I break the long lines #+CALL into multiple lines staying
near their individual #+CALL line, when moving header arguments
into #+BEGIN_SRC and its #+HEADERs is not possible for cases where
variety in the values of header arguments between calls or between
call and #+BEGIN_SRC is necessary?

Michael

Re: link abbreviation with multiple params, e. g. for geo locations

[Michael Brand]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hi Eric

On Fri, Jun 14, 2013 at 10:13 PM, Michael Brand
<michael.ch.brand@gmail.com> wrote:
> Is there a better workaround or would you accept :var dummy_name for
> my ERT that I mentioned?

For the variant of :var dummy_name see my attached patch with the updated ERT.

Michael

[-- Attachment #2: 0001-Babel-use-case-of-reading-entry-properties-as-an-ERT.patch.txt --]
[-- Type: text/plain, Size: 6121 bytes --]

From 576cd364262d33bbf614414085cc918ac7ff548b Mon Sep 17 00:00:00 2001
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Wed, 19 Jun 2013 11:36:36 +0200
Subject: [PATCH] Babel: use case of reading entry properties as an ERT

* testing/examples/babel.org: Add test entry for ERT.
* testing/lisp/test-ob-exp.el(ob-exp/use-case-of-reading-entry-properties):
Add expected source block results for ERT.
---
 testing/examples/babel.org  | 77 +++++++++++++++++++++++++++++++++++++++++++++
 testing/lisp/test-ob-exp.el | 42 +++++++++++++++++++++++++
 2 files changed, 119 insertions(+)

diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index 15f9717..de1980e 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -359,3 +359,80 @@ Here is a call line with more than just the results exported.
   <<strip-export-1>>
   echo "1$i"
 #+END_SRC
+
+* use case of reading entry properties
+  :PROPERTIES:
+  :ID:       cc5fbc20-bca5-437a-a7b8-2b4d7a03f820
+  :END:
+
+If overriden by caller then use :var from header else use entry property.
+
+** section
+   :PROPERTIES:
+   :a:        1
+   :c:        3
+   :END:
+
+Note: Just export of a property can be done with a macro: {{{property(a)}}}.
+
+#+CALL: src_block_location_shell(dummy_name="sect call")
+#+CALL: src_block_location_elisp[:session sect call]()
+- sect inline call_src_block_location_shell(dummy_name="sect inline")
+- sect inline call_src_block_location_elisp[:session sect inline]()
+
+*** subsection
+    :PROPERTIES:
+    :b:        2
+    :c:        4
+    :END:
+
+#+CALL: src_block_location_shell(dummy_name="sub0 call")
+#+CALL: src_block_location_elisp[:session sub0 call]()
+- sub0 inline call_src_block_location_shell(dummy_name="sub0 inline")
+- sub0 inline call_src_block_location_elisp[:session sub0 inline]()
+
+#+CALL: src_block_location_shell(dummy_name="sub1 call", c=5, e=6)
+#+CALL: src_block_location_elisp[:session sub1 call](c=5, e=6)
+- sub1 inline call_src_block_location_shell(dummy_name="sub1 inline", c=5, e=6)
+- sub1 inline call_src_block_location_elisp[:session sub1 inline](c=5, e=6)
+
+**** function definition
+
+#+NAME: src_block_location_shell
+#+HEADER: :var dummy_name="workaround to get different result blocks"
+#+HEADER: :var a=(or (org-entry-get org-babel-current-src-block-location "a" t) "0")
+#+HEADER: :var b=(or (org-entry-get org-babel-current-src-block-location "b" t) "0")
+#+HEADER: :var c=(or (org-entry-get org-babel-current-src-block-location "c" t) "0")
+#+HEADER: :var d=(or (org-entry-get org-babel-current-src-block-location "d" t) "0")
+#+HEADER: :var e=(or (org-entry-get org-babel-current-src-block-location "e" t) "0")
+#+BEGIN_SRC sh :shebang #!/bin/sh :exports results :results verbatim
+  printf "shell a:$a, b:$b, c:$c, d:$d, e:$e"
+#+END_SRC
+
+#+RESULTS: src_block_location_shell
+
+#+NAME: src_block_location_elisp
+#+HEADER: :var a='nil
+#+HEADER: :var b='nil
+#+HEADER: :var c='nil
+#+HEADER: :var d='nil
+#+HEADER: :var e='nil
+#+BEGIN_SRC emacs-lisp :exports results
+  (setq
+   a (or a (string-to-number
+            (or (org-entry-get org-babel-current-src-block-location "a" t)
+                "0")))
+   b (or b (string-to-number
+            (or (org-entry-get org-babel-current-src-block-location "b" t)
+                "0")))
+   c (or c (string-to-number
+            (or (org-entry-get org-babel-current-src-block-location "c" t)
+                "0")))
+   d (or d (string-to-number
+            (or (org-entry-get org-babel-current-src-block-location "e" t)
+                "0")))
+   e (or e (string-to-number
+            (or (org-entry-get org-babel-current-src-block-location "d" t)
+                "0"))))
+  (format "elisp a:%d, b:%d, c:%d, d:%d, e:%d" a b c d e)
+#+END_SRC
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index abfe230..a930c99 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -216,6 +216,48 @@ Here is one at the end of a line. =2=
       (should-not (string-match (regexp-quote "<<strip-export-1>>") result))
       (should-not (string-match (regexp-quote "i=\"10\"") result)))))
 
+(ert-deftest ob-exp/use-case-of-reading-entry-properties ()
+  (org-test-at-id "cc5fbc20-bca5-437a-a7b8-2b4d7a03f820"
+    (org-narrow-to-subtree)
+    (let* ((case-fold-search nil)
+	   (result (org-test-with-expanded-babel-code (buffer-string)))
+	   (sect "a:1, b:0, c:3, d:0, e:0")
+	   (sub0 "a:1, b:2, c:4, d:0, e:0")
+	   (sub1 "a:1, b:2, c:5, d:0, e:6")
+	   (func sub0))
+      ;; entry "section"
+      (should (string-match (concat "\"sect call\".*)\n: shell " sect "\n")
+			    result))
+      (should (string-match (concat "sect call\\](.*)\n: elisp " sect "\n")
+			    result))
+      (should (string-match (concat "\n- sect inline =shell " sect "=\n")
+			    result))
+      (should (string-match (concat "\n- sect inline =elisp " sect "=\n")
+			    result))
+      ;; entry "subsection", call without arguments
+      (should (string-match (concat "\"sub0 call\".*)\n: shell " sub0 "\n")
+			    result))
+      (should (string-match (concat "sub0 call\\](.*)\n: elisp " sub0 "\n")
+			    result))
+      (should (string-match (concat "\n- sub0 inline =shell " sub0 "=\n")
+			    result))
+      (should (string-match (concat "\n- sub0 inline =elisp " sub0 "=\n")
+			    result))
+      ;; entry "subsection", call with arguments
+      (should (string-match (concat "\"sub1 call\".*)\n: shell " sub1 "\n")
+			    result))
+      (should (string-match (concat "sub1 call\\](.*)\n: elisp " sub1 "\n")
+			    result))
+      (should (string-match (concat "\n- sub1 inline =shell " sub1 "=\n")
+			    result))
+      (should (string-match (concat "\n- sub1 inline =elisp " sub1 "=\n")
+			    result))
+      ;; entry "function definition"
+      (should (string-match (concat "_location_shell\n: shell " func "\n")
+			    result))
+      (should (string-match (concat "_location_elisp\n: elisp " func "\n")
+			    result)))))
+
 (ert-deftest ob-exp/export-from-a-temp-buffer ()
   :expected-result :failed
   (org-test-with-temp-text
-- 
1.8.3