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
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
top post - sorry: I overlooked this thread somehow.
Eric Schulte writes:
> Achim Gratz writes:
>
>> Eric Schulte writes:
>>> If you mean that there should be new syntax for setting header arguments
>>> on a file or sub-tree basis w/o using file local variables, I'd be happy
>>> to apply a patc
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
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 write tests and documentation (
Eric Schulte writes:
> I think these are great ideas. Personally I'd love to see them
> implemented. Unfortunately I don't have time to work on an
> implementation currently. I'm surprised that none of the users who
> motivated this discussion have chimed in. Their opinions may be more
> valuab
Eric Schulte writes:
>> #+PROPERTY: header-args:R :session "*R*" :exports none
>
> I hate to change syntax, but the syntax you mention above does look both
> appealing and natural. Even with working file local variables [1].
OK, so let's settle for this.
>> I've checked that the property interfa
Achim Gratz writes:
> Eric Schulte writes:
>> If you mean that there should be new syntax for setting header arguments
>> on a file or sub-tree basis w/o using file local variables, I'd be happy
>> to apply a patch.
>
> I'm thinking that something like
>
> #+PROPERTY: header-args:R :session "*R*"
Eric Schulte writes:
> If you mean that there should be new syntax for setting header arguments
> on a file or sub-tree basis w/o using file local variables, I'd be happy
> to apply a patch.
I'm thinking that something like
#+PROPERTY: header-args:R :session "*R*" :exports none
should work. I'v
Achim Gratz writes:
> Am 28.03.2013 20:35, schrieb Andreas Leha:
>> so it seems, currently, I (and John...) can not have both, /file local/
>> and /language local/ variables.
>>
>> - The emacs-lisp-block
>>#+begin_src emacs-lisp
>> (setq org-babel-default-header-args:R
>>'((:
Am 28.03.2013 20:35, schrieb Andreas Leha:
so it seems, currently, I (and John...) can not have both, /file local/
and /language local/ variables.
- The emacs-lisp-block
#+begin_src emacs-lisp
(setq org-babel-default-header-args:R
'((:session . "org-R")))
#+end_src
works
John Hendy writes:
[...]
>
> Haven't really been following along, but this works for me (after execution):
>
> #+begin_src emacs-lisp
> (setq org-babel-default-header-args:R
> '((:session . "org-R")))
> #+end_src
>
>
> These aren't:
>
> -*- org-babel-default-header-args:R: ((:s
On Wed, Mar 27, 2013 at 3:35 PM, Eric Schulte wrote:
> Andreas Leha writes:
>
> [...]
>>
>> Is that just not working for me? And any ideas, what I could do about
>> it?
>>
>
> I have no good ideas. Is the `org-babel-default-header-args:R' variable
> defined on your system before you load this f
On Thu, Mar 28, 2013 at 5:25 AM, Andreas Leha
wrote:
> Hi Eric,
>
> Eric Schulte writes:
>
>> Andreas Leha writes:
>>
>> [...]
>>>
>>> Is that just not working for me? And any ideas, what I could do about
>>> it?
>>>
>>
>> I have no good ideas. Is the `org-babel-default-header-args:R' variable
Hi Eric,
Eric Schulte writes:
> Andreas Leha writes:
>
> [...]
>>
>> Is that just not working for me? And any ideas, what I could do about
>> it?
>>
>
> I have no good ideas. Is the `org-babel-default-header-args:R' variable
> defined on your system before you load this file? If not, maybe y
[ ... ]
But non-R code blocks do not have a default session value.
#+begin_src sh
date
#+end_src
#+RESULTS:
: Mi 27. Mär 21:18:49 CET 2013
#+end_org
Would say rather: global defaults are not predictable from users perspective,
as global :seesion settings may have an
effect or not.
See
Andreas Leha writes:
[...]
>
> Is that just not working for me? And any ideas, what I could do about
> it?
>
I have no good ideas. Is the `org-babel-default-header-args:R' variable
defined on your system before you load this file? If not, maybe you
should be sure to add
(require 'ob-R)
to
Hi Eric,
Eric Schulte writes:
> Andreas Leha writes:
>
>> Hi Eric,
>>
>> [...]
>>
>>> As a side note, if
>>> one wants to set these R defaults for a single file the following syntax
>>> at the top of the file will suffice.
>>>
>>> # -*- org-babel-default-header-args:R: ((:session . "foo"))
Andreas Leha writes:
> Hi Eric,
>
> [...]
>
>> As a side note, if
>> one wants to set these R defaults for a single file the following syntax
>> at the top of the file will suffice.
>>
>> # -*- org-babel-default-header-args:R: ((:session . "foo")) -*-
>>
>
> That does not work for me. (I am
Hi Eric,
[...]
> As a side note, if
> one wants to set these R defaults for a single file the following syntax
> at the top of the file will suffice.
>
> # -*- org-babel-default-header-args:R: ((:session . "foo")) -*-
>
That does not work for me. (I am on GNU Emacs 24.3.50.1, org-mode
versi
Am 27.03.2013 13:43, schrieb Eric Schulte:
"org-R" is the name of the session. The code blocks illustrate that the
value of x (set in the first code block) is preserved and can be used
in the second (and subsequent) code blocks.
Nick
Okay, so the :session argument must not be repeated?
N
Am 27.03.2013 13:22, schrieb Rainer M Krug:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/13 13:18, Andreas Röhler wrote:
Am 27.03.2013 12:48, schrieb Nick Dokos:
Andreas Röhler wrote:
Am 27.03.2013 10:27, schrieb Andreas Leha:
Andreas Röhler writes:
Am 26.03.2013 16:31, schrie
>>
>> "org-R" is the name of the session. The code blocks illustrate that the
>> value of x (set in the first code block) is preserved and can be used
>> in the second (and subsequent) code blocks.
>>
>> Nick
>>
>>
>
> Okay, so the :session argument must not be repeated?
>
No one has said or impli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 27/03/13 13:18, Andreas Röhler wrote:
> Am 27.03.2013 12:48, schrieb Nick Dokos:
>> Andreas Röhler wrote:
>>
>>> Am 27.03.2013 10:27, schrieb Andreas Leha:
Andreas Röhler writes:
> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>
Am 27.03.2013 12:48, schrieb Nick Dokos:
Andreas Röhler wrote:
Am 27.03.2013 10:27, schrieb Andreas Leha:
Andreas Röhler writes:
Am 26.03.2013 16:31, schrieb Eric Schulte:
Achim Gratz writes:
Am 26.03.2013 13:37, schrieb Eric Schulte:
This can be done system wide by setting the langua
Andreas Röhler wrote:
> Am 27.03.2013 10:27, schrieb Andreas Leha:
> > Andreas Röhler writes:
> >
> >> Am 26.03.2013 16:31, schrieb Eric Schulte:
> >>> Achim Gratz writes:
> >>>
> Am 26.03.2013 13:37, schrieb Eric Schulte:
> > This can be done system wide by setting the language-specif
Am 27.03.2013 10:27, schrieb Andreas Leha:
Andreas Röhler writes:
Am 26.03.2013 16:31, schrieb Eric Schulte:
Achim Gratz writes:
Am 26.03.2013 13:37, schrieb Eric Schulte:
This can be done system wide by setting the language-specific header
arguments.
I've yet to see an example on how t
Hi Eric,
[...]
>
> #+begin_src emacs-lisp
> (setq org-babel-default-header-args:R
> '((:session . "org-R")))
> #+end_src
thanks a lot for this. I've looked for that option for such a long
time, but simply did not find it.
Now I have an emacs question: How would I use
Andreas Röhler writes:
> Am 26.03.2013 16:31, schrieb Eric Schulte:
>> Achim Gratz writes:
>>
>>> Am 26.03.2013 13:37, schrieb Eric Schulte:
This can be done system wide by setting the language-specific header
arguments.
>>>
>>> I've yet to see an example on how to do this.
>>>
>>
>>
Am 26.03.2013 16:31, schrieb Eric Schulte:
Achim Gratz writes:
Am 26.03.2013 13:37, schrieb Eric Schulte:
This can be done system wide by setting the language-specific header
arguments.
I've yet to see an example on how to do this.
#+begin_src emacs-lisp
(setq org-babel-defau
Hi Rainer,
Rainer M Krug wrote:
>> #+begin_src emacs-lisp
>> (setq org-babel-default-header-args:R '((:session . "org-R")))
>> #+end_src
>
> OK - that I see how this works. Although I would very much like to have a
> syntax to define this default language header as #+PROPERTY as it would be
> mor
Am 26.03.2013 13:37, schrieb Eric Schulte:
Question from here:
I use mainly R and have there set file wide
#+PROPERTY: session "R-session"
But I also have bash code, which would be evaluated in the R session, unless I
use
#+begin_src sh :session sh-session
...
#+end_src
But I do not need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/13 16:31, Eric Schulte wrote:
> Achim Gratz writes:
>
>> Am 26.03.2013 13:37, schrieb Eric Schulte:
>>> This can be done system wide by setting the language-specific header
>>> arguments.
>>
>> I've yet to see an example on how to do this.
Achim Gratz writes:
> Am 26.03.2013 13:37, schrieb Eric Schulte:
>> This can be done system wide by setting the language-specific header
>> arguments.
>
> I've yet to see an example on how to do this.
>
#+begin_src emacs-lisp
(setq org-babel-default-header-args:R
'((:sessio
Am 26.03.2013 13:37, schrieb Eric Schulte:
This can be done system wide by setting the language-specific header
arguments.
I've yet to see an example on how to do this.
This can also be done file-wide through the use of file
local variables (instead of the property line above).
Still, lang
Hi Eric,
Eric Schulte writes:
>>>
>>> Question from here:
>>>
>>> I use mainly R and have there set file wide
>>>
>>> #+PROPERTY: session "R-session"
>>>
>>> But I also have bash code, which would be evaluated in the R session,
>>> unless I use
>>>
>>> #+begin_src sh :session sh-session
>>> ..
>>
>> Question from here:
>>
>> I use mainly R and have there set file wide
>>
>> #+PROPERTY: session "R-session"
>>
>> But I also have bash code, which would be evaluated in the R session, unless
>> I use
>>
>> #+begin_src sh :session sh-session
>> ...
>> #+end_src
>>
>> But I do not need a sess
Rainer M Krug writes:
> On 26/03/13 01:46, Eric Schulte wrote:
>> Michael Gauland writes:
>>
>>> Andreas Röhler easy-emacs.de> writes:
>>>
Would find it more natural if ":session" is the default, while a command
"refresh" makes a
new one.
>>>
>>
>> Header argument defaults a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/13 01:46, Eric Schulte wrote:
> Michael Gauland writes:
>
>> Andreas Röhler easy-emacs.de> writes:
>>
>>> Would find it more natural if ":session" is the default, while a command
>>> "refresh" makes a
>>> new one.
>>
>
> Header argument
Thanks!
Am 26.03.2013 01:46, schrieb Eric Schulte:
Michael Gauland writes:
Andreas Röhler easy-emacs.de> writes:
Would find it more natural if ":session" is the default, while a command
"refresh" makes a new one.
Header argument defaults are easy to accomplish on a per user or per
file
Am 26.03.2013 00:58, schrieb Michael Gauland:
Andreas Röhler easy-emacs.de> writes:
Would find it more natural if ":session" is the default, while a command
"refresh" makes a new one.
I don't think so, but perhaps I'm just used to the way it works now. I use a
mix of session and non-session
Michael Gauland writes:
> Andreas Röhler easy-emacs.de> writes:
>
>> Would find it more natural if ":session" is the default, while a command
>> "refresh" makes a new one.
>
Header argument defaults are easy to accomplish on a per user or per
file basis, just customize the `org-babel-default-
Andreas Röhler easy-emacs.de> writes:
> Would find it more natural if ":session" is the default, while a command
"refresh" makes a new one.
I don't think so, but perhaps I'm just used to the way it works now. I use a
mix of session and non-session blocks. When I use plantuml, dot, or asymptote
Hi all,
org-babel uses the header argument ":session" keeping the environment for
consecutive evaluations.
That feels the opposite of all on-the-fly evaluations commonly done by a
(language)-shell.
Commonly a shell keeps is values until a new one is created.
Would find it more natural if ":se
61 matches
Mail list logo
