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: Fri, 07 Jun 2013 09:18:03 -0600 Message-ID: <87fvwuuez8.fsf@gmail.com> References: <87a9n35g25.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkyRK-0003Ac-Up for emacs-orgmode@gnu.org; Fri, 07 Jun 2013 11:18:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkyRJ-0005nK-E7 for emacs-orgmode@gnu.org; Fri, 07 Jun 2013 11:18:54 -0400 Received: from mail-pb0-x22d.google.com ([2607:f8b0:400e:c01::22d]:42327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkyRJ-0005nF-7W for emacs-orgmode@gnu.org; Fri, 07 Jun 2013 11:18:53 -0400 Received: by mail-pb0-f45.google.com with SMTP id mc8so4820127pbc.18 for ; Fri, 07 Jun 2013 08:18:52 -0700 (PDT) In-Reply-To: (Michael Brand's message of "Fri, 7 Jun 2013 16:53:10 +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 , Eric Schulte --=-=-= Content-Type: text/plain Hi Michael, > > Is release_8.0.3-207-g5dc5143 the change you mention?: > yes > > commit 5dc5143578a2759611a5856de9bf9d1c7eba9283 > Author: Eric Schulte > 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 > 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. --=-=-= Content-Type: text/x-org Content-Disposition: inline; filename=export-loc.org # #+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 --=-=-= Content-Type: text/plain 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 --=-=-=--