Eric Schulte writes:
> This is great, thanks. I now see that we had different things in mind
> when talking about the location used when evaluating header arguments,
> however both were required and are now implemented.
Indeed.
> You implemented location-specific look up of header argument prope
>>> Hopefully the simpler solution which uses the existing value of
>>> `org-babel-current-src-block-location' will prove sufficient (once
>>> someone implements it that is...).
>>
>> I'll implement it and see if this seems more useful than the current
>> behaviour. If it is, then we'll have to de
Achim Gratz writes:
> Eric Schulte writes:
>> Oh, I understand now. I would also be happy with using *no* header
>> arguments for this ephemeral elisp block if that is easily accomplished.
>
> I'll make a patch for testing this.
I'll have to think about his some more. The info block produced fro
>> Hopefully the simpler solution which uses the existing value of
>> `org-babel-current-src-block-location' will prove sufficient (once
>> someone implements it that is...).
>
> I'll implement it and see if this seems more useful than the current
> behaviour. If it is, then we'll have to decide i
Eric Schulte writes:
> Oh, I understand now. I would also be happy with using *no* header
> arguments for this ephemeral elisp block if that is easily accomplished.
I'll make a patch for testing this.
> Hopefully the simpler solution which uses the existing value of
> `org-babel-current-src-bloc
Achim Gratz writes:
> Eric Schulte writes:
>>> 2. The evaluation of header arguments assumes emacs-lisp as a language.
>>
>> Yes, if one wants to execute a language other than Emacs-Lisp, then they
>> should use a full fledged code block and pass a reference to that code
>> block into the header
Eric Schulte writes:
>> 2. The evaluation of header arguments assumes emacs-lisp as a language.
>
> Yes, if one wants to execute a language other than Emacs-Lisp, then they
> should use a full fledged code block and pass a reference to that code
> block into the header argument.
[…]
>> For the seco
Achim Gratz writes:
> Hi Eric,
>
> while starting to write up a test document I've found some behaviour
> when executing LOB calls that warrant discussion, I think:
>
> 1. The properties are evaluated at the site of the definition rather
>than the site of the call.
I see what you're saying.
Hi Achim
On Tue, Jun 18, 2013 at 10:41 PM, Achim Gratz wrote:
> Hi Eric,
>
> while starting to write up a test document I've found some behaviour
> when executing LOB calls that warrant discussion, I think:
>
> 1. The properties are evaluated at the site of the definition rather
> than the site o
Hi Eric,
while starting to write up a test document I've found some behaviour
when executing LOB calls that warrant discussion, I think:
1. The properties are evaluated at the site of the definition rather
than the site of the call. This is simply how org-babel-process-params
works, it jumps to
Rainer M Krug writes:
> As mentioned, I would then change my optional syntax of PROPERTY
> tomorrow. If you prefer earlier feedback, I could give it.
An actual user document is much better than me trying to construct test
cases (I'll still have do that later along with the documentation in the
man
Achim Gratz writes:
> Eric Schulte writes:
>> Great. Would you be willing to go ahead and apply these changes
>> (including documentation)? If it upsets anyone we'll sort things out on
>> the mailing list.
>
> All right, then. I've pushed the first part as it is a preparation for
> the actual
Andreas Leha writes:
> Hi Achim,
>
> Achim Gratz writes:
>
>> Eric Schulte writes:
>>> As I recall I was fully in favor of applying these changes, however I am
>>> not qualified to address the changes to property behaviors. Hopefully
>>> someone who works more on that side of things can address
Eric Schulte writes:
> Great. Would you be willing to go ahead and apply these changes
> (including documentation)? If it upsets anyone we'll sort things out on
> the mailing list.
All right, then. I've pushed the first part as it is a preparation for
the actual change. I can push that second
Achim Gratz writes:
> Eric Schulte writes:
>> As I recall I was fully in favor of applying these changes, however I am
>> not qualified to address the changes to property behaviors. Hopefully
>> someone who works more on that side of things can address those aspects.
>
> Oh wait, now I understan
Eric Schulte writes:
> As I recall I was fully in favor of applying these changes, however I am
> not qualified to address the changes to property behaviors. Hopefully
> someone who works more on that side of things can address those aspects.
Oh wait, now I understand what you're getting at, let
Hi Achim,
Achim Gratz writes:
> Eric Schulte writes:
>> As I recall I was fully in favor of applying these changes, however I am
>> not qualified to address the changes to property behaviors. Hopefully
>> someone who works more on that side of things can address those aspects.
>
> I am still ho
Eric Schulte writes:
> As I recall I was fully in favor of applying these changes, however I am
> not qualified to address the changes to property behaviors. Hopefully
> someone who works more on that side of things can address those aspects.
I am still hoping that one of the users that was askin
Achim Gratz writes:
> Achim Gratz writes:
>> The change on the Babel side was just a few lines, but reconciling Org's
>> notion of property syntax in various places proved to be more difficult.
>>
>> It's still not very well tested (it does survive the test suite
>> obviously) and I'll need to wr
19 matches
Mail list logo
