From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: link abbreviation with multiple params, e. g. for geo locations Date: Thu, 06 Jun 2013 11:01:38 -0600 Message-ID: <87a9n35g25.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukda5-00011Q-Pa for emacs-orgmode@gnu.org; Thu, 06 Jun 2013 13:02:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ukda0-0003e9-TV for emacs-orgmode@gnu.org; Thu, 06 Jun 2013 13:02:33 -0400 Received: from mail-pb0-x22e.google.com ([2607:f8b0:400e:c01::22e]:48357) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ukda0-0003dy-Mr for emacs-orgmode@gnu.org; Thu, 06 Jun 2013 13:02:28 -0400 Received: by mail-pb0-f46.google.com with SMTP id rq8so1158459pbb.5 for ; Thu, 06 Jun 2013 10:02:27 -0700 (PDT) In-Reply-To: (Michael Brand's message of "Wed, 22 May 2013 19:03:09 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Michael Brand Cc: Org Mode --=-=-= Content-Type: text/plain Michael Brand writes: > Hi all > > On Tue, May 7, 2013 at 12:29 AM, Christian Moe 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, --=-=-= Content-Type: text/x-org Content-Disposition: inline; filename=org-entry-get-point-example.org #+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" --=-=-= Content-Type: text/plain -- Eric Schulte http://cs.unm.edu/~eschulte --=-=-=--