From: Michael Brand <michael.ch.brand@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Vitalie Spinu <spinuvit@gmail.com>, Org Mode <emacs-orgmode@gnu.org>
Subject: Re: link abbreviation with multiple params, e. g. for geo locations
Date: Fri, 7 Jun 2013 21:16:00 +0200 [thread overview]
Message-ID: <CALn3zogvL86WmS2XNaiRUM-wEtL6_d5FMh0qNaaTOHbLy5X6fg@mail.gmail.com> (raw)
In-Reply-To: <87fvwuuez8.fsf@gmail.com>
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
next prev parent reply other threads:[~2013-06-07 19:16 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 17:03 link abbreviation with multiple params, e. g. for geo locations Michael Brand
2013-05-29 16:14 ` Michael Brand
2013-06-05 17:19 ` Michael Brand
2013-06-06 17:01 ` Eric Schulte
2013-06-07 14:53 ` Michael Brand
2013-06-07 15:18 ` Eric Schulte
2013-06-07 19:16 ` Michael Brand [this message]
2013-06-07 19:54 ` Vitalie Spinu
2013-06-08 18:05 ` Eric Schulte
2013-06-08 18:52 ` Vitalie Spinu
2013-06-08 19:21 ` Eric Schulte
2013-06-14 17:54 ` Michael Brand
2013-06-14 18:18 ` Eric Schulte
2013-06-14 20:13 ` Michael Brand
2013-06-19 9:39 ` Michael Brand
2013-06-07 20:10 ` Achim Gratz
2013-06-08 18:03 ` Eric Schulte
2013-06-09 7:56 ` Michael Brand
2013-06-09 8:07 ` Michael Brand
2013-06-09 19:18 ` Eric Schulte
2013-06-09 20:32 ` Michael Brand
2013-06-11 13:12 ` Eric Schulte
-- strict thread matches above, loose matches on Subject: below --
2013-05-05 15:06 Michael Brand
2013-05-06 7:06 ` Christian Moe
2013-05-06 18:42 ` Michael Brand
2013-05-06 22:29 ` Christian Moe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALn3zogvL86WmS2XNaiRUM-wEtL6_d5FMh0qNaaTOHbLy5X6fg@mail.gmail.com \
--to=michael.ch.brand@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
--cc=spinuvit@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).