Re: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric
On Fri, Jun 14, 2013 at 10:13 PM, Michael Brand
michael.ch.br...@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
From 576cd364262d33bbf614414085cc918ac7ff548b Mon Sep 17 00:00:00 2001
From: Michael Brand michael.ch.br...@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)
+
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Sat, Jun 8, 2013 at 9:21 PM, Eric Schulte schulte.e...@gmail.com wrote: Vitalie Spinu spinu...@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: [O] link abbreviation with multiple params, e. g. for geo locations
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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Fri, Jun 14, 2013 at 8:18 PM, Eric Schulte schulte.e...@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 21 /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) : 00061 cc 88 : 003 : 000c3 a4 : 002 : (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) : 00 61 cc 88 : 03 : 00 : 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: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand michael.ch.br...@gmail.com writes: Hi Eric On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
On Sun, Jun 9, 2013 at 9:56 AM, Michael Brand michael.ch.br...@gmail.com wrote: In the attached marker_offset.org Sorry, forgot that. marker_offset.org Description: Binary data
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand michael.ch.br...@gmail.com writes: Hi Eric On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
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: [O] link abbreviation with multiple params, e. g. for geo locations
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: [O] link abbreviation with multiple params, e. g. for geo locations
Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Vitalie Spinu spinu...@gmail.com writes: Eric Schulte schulte.e...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric Thank you for looking into this. On Thu, Jun 6, 2013 at 7:01 PM, Eric Schulte schulte.e...@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.e...@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 spinu...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Michael,
Is release_8.0.3-207-g5dc5143 the change you mention?:
yes
commit 5dc5143578a2759611a5856de9bf9d1c7eba9283
Author: Eric Schulte schulte.e...@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 spinu...@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.
# #+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
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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric
On Fri, Jun 7, 2013 at 5:18 PM, Eric Schulte schulte.e...@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 spinu...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand michael.ch.br...@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: [O] link abbreviation with multiple params, e. g. for geo locations
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: [O] link abbreviation with multiple params, e. g. for geo locations
Michael Brand michael.ch.br...@gmail.com writes:
Hi all
On Tue, May 7, 2013 at 12:29 AM, Christian Moe m...@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,
#+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
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Wed, May 29, 2013 at 6:14 PM, Michael Brand michael.ch.br...@gmail.com wrote: Hi Eric On Wed, May 22, 2013 at 7:03 PM, Michael Brand michael.ch.br...@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+locationssubmit=Search!idxname=emacs-orgmodemax=100result=normalsort=date%3Aearly Michael
Re: [O] link abbreviation with multiple params, e. g. for geo locations
Hi Eric On Wed, May 22, 2013 at 7:03 PM, Michael Brand michael.ch.br...@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: [O] link abbreviation with multiple params, e. g. for geo locations
Hi all
On Tue, May 7, 2013 at 12:29 AM, Christian Moe m...@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
From 178d8c7100176561a395d545c193ea36225ab81c Mon Sep 17 00:00:00 2001
From: Michael Brand michael.ch.br...@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=
Re: [O] link abbreviation with multiple params, e. g. for geo locations
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: [O] link abbreviation with multiple params, e. g. for geo locations
On Mon, May 6, 2013 at 9:06 AM, Christian Moe m...@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: [O] link abbreviation with multiple params, e. g. for geo locations
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=pspn=0.2,0.2ll=13.0,14.3q=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
