Hi Eric
On Fri, Jun 14, 2013 at 10:13 PM, Michael Brand
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 M
Hi Eric
On Fri, Jun 14, 2013 at 8:18 PM, Eric Schulte 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 session
>
> 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 su
Hi Eric
On Sat, Jun 8, 2013 at 9:21 PM, Eric Schulte wrote:
> Vitalie Spinu 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
> dynam
Michael Brand writes:
> Hi Eric
>
> On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte 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
Hi Eric
On Sun, Jun 9, 2013 at 9:18 PM, Eric Schulte 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 c
Michael Brand writes:
> Hi Eric
>
> On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte 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 th
On Sun, Jun 9, 2013 at 9:56 AM, Michael Brand
wrote:
> In the attached marker_offset.org
Sorry, forgot that.
marker_offset.org
Description: Binary data
Hi Eric
On Sat, Jun 8, 2013 at 8:03 PM, Eric Schulte 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-s
Vitalie Spinu writes:
> >> Eric Schulte
> >> 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 op
>> Eric Schulte
>> 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
>>> 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\_va
> > 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
> >
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_, nor "head", which I associate
> with #+HEADER.
There are multiple places in Babel where "src-block-head" m
>> Michael Brand
>> 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
Hi Eric
On Fri, Jun 7, 2013 at 5:18 PM, Eric Schulte 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.
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
Hi Eric
Thank you for looking into this.
On Thu, Jun 6, 2013 at 7:01 PM, Eric Schulte 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 addit
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 (p
Hi Eric
On Wed, May 29, 2013 at 6:14 PM, Michael Brand
wrote:
> Hi Eric
>
> On Wed, May 22, 2013 at 7:03 PM, Michael Brand
> 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
Hi Eric
On Wed, May 22, 2013 at 7:03 PM, Michael Brand
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 th
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
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
On Mon, May 6, 2013 at 9:06 AM, Christian Moe 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
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, y
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:
26 matches
Mail list logo
