:session question

:session question

[Andreas Röhler]

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 ":session" is the default, while a command "refresh" makes a new one.

Also instead of ":session" a header argument ":dedicated" would provide a new process every time.

As we have a bug around, maybe it's a good moment to consider that,

Andreas

Re: :session question

[Michael Gauland]

Andreas Röhler <andreas.roehler <at> 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 to
generate images, I don't use sessions (I'm not sure these languages even support
sessions). I almost always use sessions for R, because I want to use the same
data in different blocks. I also generally use sessions for Racket (scheme),
even when I don't to share data across blocks, so I don't need to wait for the
interpreter to start up for each block.

Kind Regards,
Mike Gauland

Re: :session question

[Eric Schulte]

Michael Gauland <mikelygee@no8wireless.co.nz> writes:

> Andreas Röhler <andreas.roehler <at> 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-header-args' variable.

,----[org-babel-default-header-args]
| org-babel-default-header-args is a variable defined in `ob.el'.
| Its value is ((:noweb . "yes")
|  (:session . "none")
|  (:results . "replace")
|  (:exports . "code")
|  (:cache . "no")
|  (:hlines . "no")
|  (:tangle . "no")
|  (:padnewline . "yes"))
| 
| 
| Documentation:
| Default arguments to use when evaluating a source block.
| 
| [back]
`----

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Andreas Röhler]

Am 26.03.2013 00:58, schrieb Michael Gauland:
> Andreas Röhler <andreas.roehler <at> 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 to
> generate images, I don't use sessions (I'm not sure these languages even support
> sessions).

Which is a strong argument for the present explicit way. Otherwise it would be hard to detect if
results are kept or not.

Thanks,

Andreas

I almost always use sessions for R, because I want to use the same
> data in different blocks. I also generally use sessions for Racket (scheme),
> even when I don't to share data across blocks, so I don't need to wait for the
> interpreter to start up for each block.
>
> Kind Regards,
> Mike Gauland
>
>
>

Re: :session question

[Andreas Röhler]

Thanks!

Am 26.03.2013 01:46, schrieb Eric Schulte:
> Michael Gauland <mikelygee@no8wireless.co.nz> writes:
>
>> Andreas Röhler <andreas.roehler <at> 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-header-args' variable.
>
> ,----[org-babel-default-header-args]
> | org-babel-default-header-args is a variable defined in `ob.el'.
> | Its value is ((:noweb . "yes")
> |  (:session . "none")
> |  (:results . "replace")
> |  (:exports . "code")
> |  (:cache . "no")
> |  (:hlines . "no")
> |  (:tangle . "no")
> |  (:padnewline . "yes"))
> |
> |
> | Documentation:
> | Default arguments to use when evaluating a source block.
> |
> | [back]
> `----
>

Re: :session question

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/03/13 01:46, Eric Schulte wrote:
> Michael Gauland <mikelygee@no8wireless.co.nz> writes:
> 
>> Andreas Röhler <andreas.roehler <at> 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-header-args' variable.
> 
> ,----[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in
> `ob.el'. | Its value is ((:noweb . "yes") |  (:session . "none") |  (:results . "replace") |
> (:exports . "code") |  (:cache . "no") |  (:hlines . "no") |  (:tangle . "no") |  (:padnewline
> . "yes")) | | | Documentation: | Default arguments to use when evaluating a source block.

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 session for the bash code blocks - so would :session "none" disable session
for this source block?
This would be great!

Also: it would be quite nice if one could set the session argument specific for languages, so that
I could file wide

#+PROPERTY: R-session "R"
#+PROPERTY: sh-session "sh"

but the default for all un-specified languages would be no sessio use. Is there a possibility to
do it?

Cheers,

Rainer

> | | [back] `----
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRUWaZAAoJENvXNx4PUvmCdEYH/RBXokBJsbPp9bFK/9IRv5k9
xxpkTClUlUBgfKOjQIDCUxkQ53iyuhdGXkM5d9CNXi0VrOEU8lAsEKscyJBaDEMY
6bcfT6TgULw53uOL42dpwfh+dw/URyCyCI4TY+IazRQ80eR4GZVcTNNSKwwjoZmJ
b5PUFX1f5qtiS4oxC91GqBWujLSDrQS0sLMOUG7UYXTv2UJNTKWphyw7srdXakA+
A7fvl4lEnpX2sXbi8YJCvmICW1k3L1KcMkM1RSx2TbOLFxfEbc2mHQew6UganHG2
Ww+DeBqT197TJ7sUF6vMPAIs4r7Hu/Nwm7jsYdANFe6QgKHVbCvsv+SRSV4v5nY=
=ei0N
-----END PGP SIGNATURE-----

Re: :session question

[Andreas Leha]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On 26/03/13 01:46, Eric Schulte wrote:
>> Michael Gauland <mikelygee@no8wireless.co.nz> writes:
>> 
>>> Andreas Röhler <andreas.roehler <at> 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-header-args' variable.
>> 
>> ,----[org-babel-default-header-args] | org-babel-default-header-args is a variable defined in
>> `ob.el'. | Its value is ((:noweb . "yes") |  (:session . "none") |  (:results . "replace") |
>> (:exports . "code") |  (:cache . "no") |  (:hlines . "no") |  (:tangle . "no") |  (:padnewline
>> . "yes")) | | | Documentation: | Default arguments to use when evaluating a source block.
>
> 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 session for the bash code blocks - so would :session "none" disable session
> for this source block?
> This would be great!
>
> Also: it would be quite nice if one could set the session argument specific for languages, so that
> I could file wide
>
> #+PROPERTY: R-session "R"
> #+PROPERTY: sh-session "sh"
>

+1

[...]

Regards,
Andreas

Re: :session question

[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 a session for the bash code blocks - so would :session "none" disable session
>> for this source block?
>> This would be great!
>>

Yes

>>
>> Also: it would be quite nice if one could set the session argument specific for languages, so that
>> I could file wide
>>
>> #+PROPERTY: R-session "R"
>> #+PROPERTY: sh-session "sh"
>>
>
> +1
>

This can be done system wide by setting the language-specific header
arguments.  This can also be done file-wide through the use of file
local variables (instead of the property line above).

Please read through the header argument documentation to see the many
different ways in which header arguments may be set.

http://orgmode.org/manual/Using-header-arguments.html

Best,

>
> [...]
>
> Regards,
> Andreas
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Andreas Leha]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> 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
>>>  ...
>>> #+end_src
>>>
>>> But I do not need a session for the bash code blocks - so would :session "none" disable session
>>> for this source block?
>>> This would be great!
>>>
>
> Yes
>
>>>
>>> Also: it would be quite nice if one could set the session argument specific for languages, so that
>>> I could file wide
>>>
>>> #+PROPERTY: R-session "R"
>>> #+PROPERTY: sh-session "sh"
>>>
>>
>> +1
>>
>
> This can be done system wide by setting the language-specific header
> arguments.  This can also be done file-wide through the use of file
> local variables (instead of the property line above).
>
> Please read through the header argument documentation to see the many
> different ways in which header arguments may be set.
>
> http://orgmode.org/manual/Using-header-arguments.html
>
> Best,
>

Thanks for taking this up.  And sorry for my ignorance.  I have read the
linked pages, but I still do not know how to achieve the language
specific session values.
Could you provide an example?

Regards,
Andreas

Re: :session question

[Achim Gratz]

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, language specific properties should exists.

But importantly, there should be no way to set a default session name 
without also specifying the language, regardless of which way one tries 
to set this up.

> Please read through the header argument documentation to see the many
> different ways in which header arguments may be set.
>
> http://orgmode.org/manual/Using-header-arguments.html

This sends you off to Worg (which tries to send you back to where you 
came from), where you'll learn that there are no language specific 
header arguments for R and no further documentation on how to set 
defaults specific to R can easily be found (if it exists).


Regards,
-- 
Achim.

(on the road :-)

Re: :session question

[Eric Schulte]

Achim Gratz <Stromeko@Nexgo.DE> 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
            '((:session . "org-R")))
    #+end_src

    #+RESULTS:
    | (:session . org-R) |

    #+begin_src R
    x <- 1
    x
    #+end_src

    #+RESULTS:
    : 1

    #+begin_src R
    x
    #+end_src

    #+RESULTS:
    : 1

>
>>  This can also be done file-wide through the use of file
>> local variables (instead of the property line above).
>
> Still, language specific properties should exists.
>

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.

>
> But importantly, there should be no way to set a default session name
> without also specifying the language, regardless of which way one
> tries to set this up.
>

If you can think of a clean way to implement this then we should go for
it.  I doubt many existing configurations rely on this behavior.

>
>> Please read through the header argument documentation to see the many
>> different ways in which header arguments may be set.
>>
>> http://orgmode.org/manual/Using-header-arguments.html
>
> This sends you off to Worg (which tries to send you back to where you
> came from),

Clearly this portion of the manual should be improved.

> where you'll learn that there are no language specific header
> arguments for R and no further documentation on how to set defaults
> specific to R can easily be found (if it exists).
>

Every language can specify default header arguments through setting a
defvar.  The syntax is `org-babel-default-header-args:lang'.  This
should not be hard to find through apropos, simple tab completion or
searching the archives of this mailing list.  However I agree the manual
should be improved wrt this topic.

Best,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question - header argument setting

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/03/13 16:31, Eric Schulte wrote:
> Achim Gratz <Stromeko@Nexgo.DE> 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 '((: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 more consistent.

But I remember there was a way of executing this code when opening but I can't find it anymore.

> 
> #+RESULTS: | (:session . org-R) |
> 
> #+begin_src R x <- 1 x #+end_src
> 
> #+RESULTS: : 1
> 
> #+begin_src R x #+end_src
> 
> #+RESULTS: : 1
> 
>> 
>>> This can also be done file-wide through the use of file local variables (instead of the
>>> property line above).
>> 
>> Still, language specific properties should exists.
>> 
> 
> 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.
> 
>> 
>> But importantly, there should be no way to set a default session name without also specifying
>> the language, regardless of which way one tries to set this up.
>> 

I think that would be a very important and useful aspect to include.

> 
> If you can think of a clean way to implement this then we should go for

Just an idea: if one would add a second value to the :session argument, one could use that one th
specify the language for the session. If none is given, it would apply to all languages (so
nothing changes), but if one is given, it would only apply to this language:

#+PROPERTY: :session R-test R
#+PROPERTY: :session none

would set the language specific header :session to R-test, and the "old" session argument to "none",


> it.  I doubt many existing configurations rely on this behavior.

If implemented as above, the default behavior would not be changed, so no changes need to be done
by the user.

In addition, this could be extended to other language specific headers (the only problem could be
header arguments which take anyway multiple arguments, like :results).

Cheers,

Rainer


> 
>> 
>>> Please read through the header argument documentation to see the many different ways in
>>> which header arguments may be set.
>>> 
>>> http://orgmode.org/manual/Using-header-arguments.html
>> 
>> This sends you off to Worg (which tries to send you back to where you came from),
> 
> Clearly this portion of the manual should be improved.
> 
>> where you'll learn that there are no language specific header arguments for R and no further
>> documentation on how to set defaults specific to R can easily be found (if it exists).
>> 
> 
> Every language can specify default header arguments through setting a defvar.  The syntax is
> `org-babel-default-header-args:lang'.  This should not be hard to find through apropos, simple
> tab completion or searching the archives of this mailing list.  However I agree the manual 
> should be improved wrt this topic.
> 
> Best,
> 
>> 
>> 
>> Regards,
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRUqd0AAoJENvXNx4PUvmC/HAIAJhoWFi8/D84V0FKNw1Y7TOW
/7BXZHB8sDZENdO+35lqjJuKEKECcjSiwQOpa8KPffI4QYIJlsQzEbMSbTgl2+3H
CaVARcnuj1hil0J7+EjTfWewbulCMSIDr9GsVpwMVKxl5VxY52/SRtOXyl7Ci2Td
yAKDaPshq6kV15FdRF8MF30XxoEt+IH4p/u6m71Iq8poI8E8rqWhPufgeOdvhuNR
q6yz57L0FG2kww//Mv3VByDvTf94+gbcMMtZ8qbrl+z3Mk+6I9WYTb6lzl3qP6je
zW58K7rzorl8ZbbNe7GCmv0OOrEXXkkwHI5Ji00Jb+JMyBOrxe1r8cssHkFUbTo=
=uNE3
-----END PGP SIGNATURE-----

Re: :session question

[Andreas Röhler]

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 a session for the bash code blocks - so would :session "none" disable session
>>> for this source block?
>>> This would be great!
>>>
>
> Yes
>

maybe just

:session no

rather than

:session "none"

Booleans written as strings reads terribly for me :(

Cheers,

Andreas

Re: :session question - header argument setting

[Sebastien Vauban]

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
> more consistent.
>
> But I remember there was a way of executing this code when opening but I
> can't find it anymore.

File local variable?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: :session question

[Andreas Röhler]

Am 26.03.2013 16:31, schrieb Eric Schulte:
> Achim Gratz <Stromeko@Nexgo.DE> 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
>              '((:session . "org-R")))
>      #+end_src
>
>      #+RESULTS:
>      | (:session . org-R) |
>
>      #+begin_src R
>      x <- 1
>      x
>      #+end_src
>
>      #+RESULTS:
>      : 1
>
>      #+begin_src R
>      x
>      #+end_src
>
>      #+RESULTS:
>      : 1
>
>>

Hi,

this looks very confusing for me.

So, what is the purpose of a named session?
Understood it being a name-space, whose values don't affect the other ones.
What's in python-mode a dedicated shell.

As it reads, it clutters even the global languages name space?

Best,

Andreas

Re: :session question

[Andreas Leha]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Am 26.03.2013 16:31, schrieb Eric Schulte:
>> Achim Gratz <Stromeko@Nexgo.DE> 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
>>              '((:session . "org-R")))
>>      #+end_src
>>
>>      #+RESULTS:
>>      | (:session . org-R) |
>>
>>      #+begin_src R
>>      x <- 1
>>      x
>>      #+end_src
>>
>>      #+RESULTS:
>>      : 1
>>
>>      #+begin_src R
>>      x
>>      #+end_src
>>
>>      #+RESULTS:
>>      : 1
>>
>>>
>
> Hi,
>
> this looks very confusing for me.
>
> So, what is the purpose of a named session?
> Understood it being a name-space, whose values don't affect the other ones.
> What's in python-mode a dedicated shell.

I can't speak for python, but in R, every differently named session will
run within its own R process.

The cool thing is, that I can work on file_foo.org and file_bar.org
simultaneously, when file_foo.org uses R-session *foo* and file_bar.org
uses R-session *bar*.

[...]

Regards,
Andreas

Re: [O] :session question

[Andreas Röhler]

Am 27.03.2013 10:27, schrieb Andreas Leha:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>> Achim Gratz <Stromeko@Nexgo.DE> 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
>>>               '((:session . "org-R")))
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       | (:session . org-R) |
>>>
>>>       #+begin_src R
>>>       x <- 1
>>>       x
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       : 1
>>>
>>>       #+begin_src R
>>>       x
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       : 1
>>>
>>>>
>>
>> Hi,
>>
>> this looks very confusing for me.
>>
>> So, what is the purpose of a named session?
>> Understood it being a name-space, whose values don't affect the other ones.
>> What's in python-mode a dedicated shell.
>
> I can't speak for python, but in R, every differently named session will
> run within its own R process.
>
> The cool thing is, that I can work on file_foo.org and file_bar.org
> simultaneously, when file_foo.org uses R-session *foo* and file_bar.org
> uses R-session *bar*.
>
> [...]
>
> Regards,
> Andreas
>

Okay, that's the expected usage.
How do you read the example displayed?

Looks like a named (:session . "org-R") affects global R namespace.

What did "org-R" say here, what might be the purpose?

Assume it should switch it on. Then "org-R" represents a boolean here?

Best,

Andreas

Re: [O] :session question

[Andreas Röhler]

Am 27.03.2013 11:10, schrieb Andreas Röhler:
Sorry, wrong list...

Re: :session question

[Andreas Leha]

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 that in
file-local-variables?  The colon seems to cause trouble:

# Local Variables:
# org-babel-default-header-args:R: (quote ((:session . "org-R")))
# End:

Thanks in advance for pointers.

[...]

Regards,
Andreas

Re: :session question

[Andreas Röhler]

Am 27.03.2013 10:27, schrieb Andreas Leha:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>> Achim Gratz <Stromeko@Nexgo.DE> 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
>>>               '((:session . "org-R")))
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       | (:session . org-R) |
>>>
>>>       #+begin_src R
>>>       x <- 1
>>>       x
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       : 1
>>>
>>>       #+begin_src R
>>>       x
>>>       #+end_src
>>>
>>>       #+RESULTS:
>>>       : 1
>>>
>>>>
>>
>> Hi,
>>
>> this looks very confusing for me.
>>
>> So, what is the purpose of a named session?
>> Understood it being a name-space, whose values don't affect the other ones.
>> What's in python-mode a dedicated shell.
>
> I can't speak for python, but in R, every differently named session will
> run within its own R process.
>
> The cool thing is, that I can work on file_foo.org and file_bar.org
> simultaneously, when file_foo.org uses R-session *foo* and file_bar.org
> uses R-session *bar*.
>
> [...]
>
> Regards,
> Andreas
>
>
>
>


Okay, that's the expected usage.
How do you read the example displayed?

Looks like a named (:session . "org-R") affects global R namespace.

What did "org-R" say here, what might be the purpose?

Assume it should switch it on. Then "org-R" represents a boolean here?

Best,

Andreas

Re: :session question

[Nick Dokos]

Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Am 27.03.2013 10:27, schrieb Andreas Leha:
> > Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> >
> >> Am 26.03.2013 16:31, schrieb Eric Schulte:
> >>> Achim Gratz <Stromeko@Nexgo.DE> 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
> >>>               '((:session . "org-R")))
> >>>       #+end_src
> >>>
> >>>       #+RESULTS:
> >>>       | (:session . org-R) |
> >>>
> >>>       #+begin_src R
> >>>       x <- 1
> >>>       x
> >>>       #+end_src
> >>>
> >>>       #+RESULTS:
> >>>       : 1
> >>>
> >>>       #+begin_src R
> >>>       x
> >>>       #+end_src
> >>>
> >>>       #+RESULTS:
> >>>       : 1
> >>>
> >>>>
> >>
> >> Hi,
> >>
> >> this looks very confusing for me.
> >>
> >> So, what is the purpose of a named session?
> >> Understood it being a name-space, whose values don't affect the other ones.
> >> What's in python-mode a dedicated shell.
> >
> > I can't speak for python, but in R, every differently named session will
> > run within its own R process.
> >
> > The cool thing is, that I can work on file_foo.org and file_bar.org
> > simultaneously, when file_foo.org uses R-session *foo* and file_bar.org
> > uses R-session *bar*.
> >
> > [...]
> >
> > Regards,
> > Andreas
> >
> >
> >
> >
> 
> 
> Okay, that's the expected usage.
> How do you read the example displayed?
> 
> Looks like a named (:session . "org-R") affects global R namespace.
> 
> What did "org-R" say here, what might be the purpose?
> 
> Assume it should switch it on. Then "org-R" represents a boolean here?
> 

"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

Re: :session question

[Andreas Röhler]

Am 27.03.2013 12:48, schrieb Nick Dokos:
> Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:
>
>> Am 27.03.2013 10:27, schrieb Andreas Leha:
>>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>
>>>> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>>>> Achim Gratz <Stromeko@Nexgo.DE> 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
>>>>>                '((:session . "org-R")))
>>>>>        #+end_src
>>>>>
>>>>>        #+RESULTS:
>>>>>        | (:session . org-R) |
>>>>>
>>>>>        #+begin_src R
>>>>>        x <- 1
>>>>>        x
>>>>>        #+end_src
>>>>>
>>>>>        #+RESULTS:
>>>>>        : 1
>>>>>
>>>>>        #+begin_src R
>>>>>        x
>>>>>        #+end_src
>>>>>
>>>>>        #+RESULTS:
>>>>>        : 1
>>>>>
>>>>>>
>>>>
>>>> Hi,
>>>>
>>>> this looks very confusing for me.
>>>>
>>>> So, what is the purpose of a named session?
>>>> Understood it being a name-space, whose values don't affect the other ones.
>>>> What's in python-mode a dedicated shell.
>>>
>>> I can't speak for python, but in R, every differently named session will
>>> run within its own R process.
>>>
>>> The cool thing is, that I can work on file_foo.org and file_bar.org
>>> simultaneously, when file_foo.org uses R-session *foo* and file_bar.org
>>> uses R-session *bar*.
>>>
>>> [...]
>>>
>>> Regards,
>>> Andreas
>>>
>>>
>>>
>>>
>>
>>
>> Okay, that's the expected usage.
>> How do you read the example displayed?
>>
>> Looks like a named (:session . "org-R") affects global R namespace.
>>
>> What did "org-R" say here, what might be the purpose?
>>
>> Assume it should switch it on. Then "org-R" represents a boolean here?
>>
>
> "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?

i.e. doesn't look like a session, resp. not a named session

 >>>>> #+begin_src R
 >>>>>        x <- 1
 >>>>>        x
 >>>>> #+end_src


Once a named session "org-R" is started all non-sessioned source goes there?
Looks like a broken namespace.

Re: :session question

[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 <andreas.roehler@easy-emacs.de> wrote:
>> 
>>> Am 27.03.2013 10:27, schrieb Andreas Leha:
>>>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>> 
>>>>> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>>>>> Achim Gratz <Stromeko@Nexgo.DE> 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 '((:session .
>>>>>> "org-R"))) #+end_src
>>>>>> 
>>>>>> #+RESULTS: | (:session . org-R) |
>>>>>> 
>>>>>> #+begin_src R x <- 1 x #+end_src
>>>>>> 
>>>>>> #+RESULTS: : 1
>>>>>> 
>>>>>> #+begin_src R x #+end_src
>>>>>> 
>>>>>> #+RESULTS: : 1
>>>>>> 
>>>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> this looks very confusing for me.
>>>>> 
>>>>> So, what is the purpose of a named session? Understood it being a name-space, whose
>>>>> values don't affect the other ones. What's in python-mode a dedicated shell.
>>>> 
>>>> I can't speak for python, but in R, every differently named session will run within its
>>>> own R process.
>>>> 
>>>> The cool thing is, that I can work on file_foo.org and file_bar.org simultaneously, when
>>>> file_foo.org uses R-session *foo* and file_bar.org uses R-session *bar*.
>>>> 
>>>> [...]
>>>> 
>>>> Regards, Andreas
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> Okay, that's the expected usage. How do you read the example displayed?
>>> 
>>> Looks like a named (:session . "org-R") affects global R namespace.
>>> 
>>> What did "org-R" say here, what might be the purpose?
>>> 
>>> Assume it should switch it on. Then "org-R" represents a boolean here?
>>> 
>> 
>> "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?
> 
> i.e. doesn't look like a session, resp. not a named session
> 
>>>>>> #+begin_src R x <- 1 x #+end_src
> 
> 
> Once a named session "org-R" is started all non-sessioned source goes there? Looks like a
> broken namespace.

Isn't it the same with all header arguments? when they are set file wide, they are used for the
source block unless specified otherwise.

Rainer

> 
> 
> 


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys.
(Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRUuSDAAoJENvXNx4PUvmC2gEH/1t3vVle7zsa6tVYCMru5QEa
uKr1o8+COJ8H92U28kn0++g4Qvtpu9cA8SRG8pH4bDw1Cv3kpg32CkQraJ6k7lIT
gFTc1pcw33znfNwYJ4eHVz3uff5pXZOYBgJVtiYdmOEXMh1Kvg5UmHAB9mjoZC6L
McZDRGCEGgjIkiGnrsZigCx3PEpYDTTMJ+qMDyaBA7csHxDXW96p3zUbFvLfWsaw
6egmMkvLca/WfJ1xjM4nbdp2VsPl/GofLWa/65hpGv5iMmOf/ixInhT2cQDsCmcB
HukzR7Mu6BK4tHy6VGBOzRJARpo2fGGcMPv5BKRw6QRb3FhK/uBTLR6THt6FzFo=
=z/jU
-----END PGP SIGNATURE-----

Re: :session question

[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?
>

No one has said or implied that.

>
> i.e. doesn't look like a session, resp. not a named session
>

The example below is from my previous email in which I demonstrated how
to add a particular named session to the default header arguments list.
Explicitly making that particular session global.  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")) -*-

>
>>>>>> #+begin_src R
>>>>>>        x <- 1
>>>>>>        x
>>>>>> #+end_src
>
>
> Once a named session "org-R" is started all non-sessioned source goes
> there?  Looks like a broken namespace.

Of course not.  Trivial local experimentation could show that is not the
case.  Please actually try to run things locally before assuming that
there are non-sensical bugs and posting questions to the mailing list.

I don't think this line makes sense.  If you can spend 10 more minutes
writing an email to save the average reader one minute, please do so, as
on average many more than 10 people will read every post you send to
this list.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Andreas Röhler]

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 <andreas.roehler@easy-emacs.de> wrote:
>>>
>>>> Am 27.03.2013 10:27, schrieb Andreas Leha:
>>>>> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>>>>>
>>>>>> Am 26.03.2013 16:31, schrieb Eric Schulte:
>>>>>>> Achim Gratz <Stromeko@Nexgo.DE> 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 '((:session .
>>>>>>> "org-R"))) #+end_src
>>>>>>>
>>>>>>> #+RESULTS: | (:session . org-R) |
>>>>>>>
>>>>>>> #+begin_src R x <- 1 x #+end_src
>>>>>>>
>>>>>>> #+RESULTS: : 1
>>>>>>>
>>>>>>> #+begin_src R x #+end_src
>>>>>>>
>>>>>>> #+RESULTS: : 1
>>>>>>>
>>>>>>>>
>>>>>>
[ ... ]
>>>>
>>>>
>>>> Okay, that's the expected usage. How do you read the example displayed?
>>>>
>>>> Looks like a named (:session . "org-R") affects global R namespace.
>>>>
>>>> What did "org-R" say here, what might be the purpose?
>>>>
>>>> Assume it should switch it on. Then "org-R" represents a boolean here?
>>>>
>>>
>>> "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?
>>
>> i.e. doesn't look like a session, resp. not a named session
>>
>>>>>>> #+begin_src R x <- 1 x #+end_src
>>
>>
>> Once a named session "org-R" is started all non-sessioned source goes there? Looks like a
>> broken namespace.
>
> Isn't it the same with all header arguments? when they are set file wide, they are used for the
> source block unless specified otherwise.
>
> Rainer
>

Hmm, may you point me to the file-wide setting?

Form at stake

(setq org-babel-default-header-args:R '((:session . "org-R")))

seems to put all remaining R-evaluations into a named session "org-R"

Don't see any restriction onto a file resp. buffer. Maybe that's thought implicit?

Thanks,

Andreas

Re: :session question

[Andreas Röhler]

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?
>>
>
> No one has said or implied that.
>

Looks for me as this code from your example runs in session mode without explicit :session argument given:

   #+begin_src R
     x <- 1
     x
     #+end_src

     #+RESULTS:
     : 1

     #+begin_src R
     x
     #+end_src

     #+RESULTS:
     : 1
[ ... ]

Re: :session question

[Andreas Leha]

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
version 8.0-pre (release_8.0-pre-97-gffdd9e))

When I open an org-file containing that line, I get
,----
| Malformed mode-line
`----
and have to answer
,----
| The local variables list contains values that may not be safe(*).
| 
| (*) org-babel-default-header-args : R:
| 
| Please type y, n, or !: y
`----

When I accept and try to actually evaluate R-code, I get 
,----
| Wrong type argument: sequencep, R: |
`----


What am I missing?

Regards,
Andreas

Re: :session question

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

Andreas Leha <andreas.leha@med.uni-goettingen.de> 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 on GNU Emacs 24.3.50.1, org-mode
> version 8.0-pre (release_8.0-pre-97-gffdd9e))
>

That's weird, it works perfectly for me.  I'm using the same version of
Emacs, but an earlier version of Org-mode.

Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)

>
> When I open an org-file containing that line, I get
> ,----
> | Malformed mode-line
> `----
> and have to answer
> ,----
> | The local variables list contains values that may not be safe(*).
> | 
> | (*) org-babel-default-header-args : R:
> | 
> | Please type y, n, or !: y
> `----
>
> When I accept and try to actually evaluate R-code, I get 
> ,----
> | Wrong type argument: sequencep, R: |
> `----
>
>
> What am I missing?
>

I'm not sure.  For some reason Emacs thinks the variable ends at the ":"
in the variable name.  I'm attaching the complete example file I've used
locally, please retry with that and see if the problem persists.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: example.org --]
[-- Type: text/x-org, Size: 561 bytes --]

# -*- org-babel-default-header-args:R: ((:session . "foo")) -*-
#+Title: Example
#+Author: Eric Schulte

For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local
Variables]].

Because there is a default :session values assigned locally for R
blocks we have the following.

#+begin_src R
  x <- 1
  x
#+end_src

#+RESULTS:
: 1

#+begin_src R
  x
#+end_src

#+RESULTS:
: 1

But non-R code blocks do not have a default session value.

#+begin_src sh
  date
#+end_src

#+RESULTS:
: Wed Mar 27 09:45:47 MDT 2013


[-- Attachment #3: Type: text/plain, Size: 81 bytes --]


Best,

>
> Regards,
> Andreas
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Andreas Leha]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Andreas Leha <andreas.leha@med.uni-goettingen.de> 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 on GNU Emacs 24.3.50.1, org-mode
>> version 8.0-pre (release_8.0-pre-97-gffdd9e))
>>
>
> That's weird, it works perfectly for me.  I'm using the same version of
> Emacs, but an earlier version of Org-mode.
>
> Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef @ /usr/share/emacs/24.3/lisp/org/)
>
>>
>> When I open an org-file containing that line, I get
>> ,----
>> | Malformed mode-line
>> `----
>> and have to answer
>> ,----
>> | The local variables list contains values that may not be safe(*).
>> | 
>> | (*) org-babel-default-header-args : R:
>> | 
>> | Please type y, n, or !: y
>> `----
>>
>> When I accept and try to actually evaluate R-code, I get 
>> ,----
>> | Wrong type argument: sequencep, R: |
>> `----
>>
>>
>> What am I missing?
>>
>
> I'm not sure.  For some reason Emacs thinks the variable ends at the ":"
> in the variable name.  I'm attaching the complete example file I've used
> locally, please retry with that and see if the problem persists.
>
> # -*- org-babel-default-header-args:R: ((:session . "foo")) -*-
> #+Title: Example
> #+Author: Eric Schulte
>
> For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local
> Variables]].
>
> Because there is a default :session values assigned locally for R
> blocks we have the following.
>
> #+begin_src R
>   x <- 1
>   x
> #+end_src
>
> #+RESULTS:
> : 1
>
> #+begin_src R
>   x
> #+end_src
>
> #+RESULTS:
> : 1
>
> But non-R code blocks do not have a default session value.
>
> #+begin_src sh
>   date
> #+end_src
>
> #+RESULTS:
> : Wed Mar 27 09:45:47 MDT 2013
>
>

Thanks for your answer!  I tested with your file.  I only get the
'Malformed mode-line'.  (The questions about unsave variables was my
mistake.)

But the session 'foo' is still not started, but the code blocks are
evaluated as if there was no session specified:

#+begin_org
# -*- org-babel-default-header-args:R: ((:session . "foo")) -*-
#+Title: Example
#+Author: Eric Schulte

For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local
Variables]].

Because there is a default :session values assigned locally for R
blocks we have the following.

#+begin_src R
  x <- 1
  x
#+end_src

#+RESULTS:
: 1

#+begin_src R
  x
#+end_src

#+RESULTS:

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


Is that just not working for me?  And any ideas, what I could do about
it?

Regards,
Andreas

Re: :session question

[Eric Schulte]

Andreas Leha <andreas.leha@med.uni-goettingen.de> 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 your emacs initialization.  If the ":" in the variable name is
somehow confusing your Emacs, then possibly you could use the alternate
format of specifying file local variables (see the info link in my
attached example).

I hope one of these works, aside from that I have no idea why our Emacs
versions would differ in such fundamental behavior.

Cheers,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Andreas Röhler]

[ ... ]
>
> 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 in Common Lisp for example, which is always in session-mode IIUC

Re: :session question

[Andreas Leha]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Andreas Leha <andreas.leha@med.uni-goettingen.de> 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)
>

The variable is defined (value is nil).  I added the (require 'ob-R) to
my initialization nonetheless, but no avail.  The value of
`org-babel-default-header-args:R' stays nil.

> to your emacs initialization.  If the ":" in the variable name is
> somehow confusing your Emacs, then possibly you could use the alternate
> format of specifying file local variables (see the info link in my
> attached example).

I tried (the file is below).  In this case I even get the question on
unsafe variables.

[...]


Thanks for the suggestions anyway,
Andreas

PS: the file again:
#+begin_org
#+Title: Example
#+Author: Eric Schulte

For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local
Variables]].

Because there is a default :session values assigned locally for R
blocks we have the following.

#+begin_src R
  x <- 1
  x
#+end_src

#+RESULTS:
: 1

#+begin_src R
  x
#+end_src

#+RESULTS:

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

# Local Variables:
# org-babel-default-header-args:R: ((:session . "foo"))
# End:
#+end_org

Re: :session question

[John Hendy]

On Thu, Mar 28, 2013 at 5:25 AM, Andreas Leha
<andreas.leha@med.uni-goettingen.de> wrote:
> Hi Eric,
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Andreas Leha <andreas.leha@med.uni-goettingen.de> 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)
>>

Is this the right way to require a language anymore? I thought it was:

;; active Babel languages
(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)))

(http://orgmode.org/worg/org-contrib/babel/languages.html)

>
> The variable is defined (value is nil).  I added the (require 'ob-R) to
> my initialization nonetheless, but no avail.  The value of
> `org-babel-default-header-args:R' stays nil.
>
>> to your emacs initialization.  If the ":" in the variable name is
>> somehow confusing your Emacs, then possibly you could use the alternate
>> format of specifying file local variables (see the info link in my
>> attached example).
>
> I tried (the file is below).  In this case I even get the question on
> unsafe variables.
>
> [...]
>

Well that's good; it's trying to start a session.

>
> Thanks for the suggestions anyway,
> Andreas
>
> PS: the file again:
> #+begin_org
> #+Title: Example
> #+Author: Eric Schulte
>
> For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local
> Variables]].
>
> Because there is a default :session values assigned locally for R
> blocks we have the following.
>
> #+begin_src R
>   x <- 1
>   x
> #+end_src
>
> #+RESULTS:
> : 1
>
> #+begin_src R
>   x
> #+end_src
>
> #+RESULTS:
>
> 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
>
> # Local Variables:
> # org-babel-default-header-args:R: ((:session . "foo"))
> # End:
> #+end_org
>

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: ((:session . "foo")) -*-

#-*- org-babel-default-header-args:R: ((:session . "foo")) -*-

There were a lot of suggestions made above and I've never used the
-*-setting-*- syntax and am not searching the right things to find out
more about how this is supposed to work.

ETA: Ah, I had to re-open the file after adding this to the buffer to
get it to recognize it:

# Local Variables:
# org-babel-default-header-args:R: ((:session . "foo"))
# End:

This produces the same issue as you, Andreas:

Wrong type argument: sequencep, R:


Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e).


John

>

Re: :session question

[John Hendy]

On Wed, Mar 27, 2013 at 3:35 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> Andreas Leha <andreas.leha@med.uni-goettingen.de> 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 your emacs initialization.  If the ":" in the variable name is
> somehow confusing your Emacs, then possibly you could use the alternate
> format of specifying file local variables (see the info link in my
> attached example).
>

By "alternate" do you mean:

# Local Variables:
# stuff
# End:

vs.

-*-stuff-*-

?

If so, this isn't working for me either (I get "malformed modeline"):

-*- org-babel-default-header-args:R: ((:session . "foo")) -*-

I read through the *info* on local file variables and both of the
above seem like they should be correct. Wouldn't it be the colon?
Emacs is looking for VAR:VALUE. Here's from files.el, which contains
the function =hack-local-variables=. While not an elisper, this looks
like it wouldn't figure out two colons:

		  (while (and (not (eobp))
			      (or (not mode-only)
				  (not result)))
		    ;; Find the variable name; strip whitespace.
		    (skip-chars-forward " \t")
		    (setq beg (point))
		    (skip-chars-forward "^:\n")
		    (if (eolp) (error "Missing colon in local variables entry"))
		    (skip-chars-backward " \t")

Isn't this sort of saying, "split up the var:value pair by starting at
line beginning, going to the first =:=, and then looking for a
newline? If so, I'd take the execution as trying to set:

=org-babel-default-header-args= to a value of =R: ((:session . "foo"))=




John

> I hope one of these works, aside from that I have no idea why our Emacs
> versions would differ in such fundamental behavior.
>
> Cheers,
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte
>

Re: :session question - a simple PATCH

[Andreas Leha]

[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]

John Hendy <jw.hendy@gmail.com> 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: ((:session . "foo")) -*-
>
> #-*- org-babel-default-header-args:R: ((:session . "foo")) -*-
>
> There were a lot of suggestions made above and I've never used the
> -*-setting-*- syntax and am not searching the right things to find out
> more about how this is supposed to work.
>
> ETA: Ah, I had to re-open the file after adding this to the buffer to
> get it to recognize it:
>
> # Local Variables:
> # org-babel-default-header-args:R: ((:session . "foo"))
> # End:
>
> This produces the same issue as you, Andreas:
>
> Wrong type argument: sequencep, R:
>
>
> Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e).
>
>
> John
>


Hi all,

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, of course, but sets the R-session globally.

- The file-local variables (both way to set them) choke on the colon in
  the varible name.



I do not know where to search for the reason, these variables work for
Eric but not for me (and John...).

So attached is a simple patch (search-and-replace) that renames all
org-babel-default-header-args:* variables to
org-babel-default-header-args-*
I do not see any problems with this renaming, but as I have only limited
elisp, that might not mean too much.


This fixes the issue for me at the cost of breaking other people's setup
if they use org-babel-default-header-args:* variants.

What do you think?


Regards,
Andreas



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 24769 bytes --]

From 91965d0fc8820f9c0b68728368d3d8062d8c49ef Mon Sep 17 00:00:00 2001
From: Andreas Leha <andreas@lehas.net>
Date: Thu, 28 Mar 2013 16:45:33 +0100
Subject: [PATCH] Renamed vars org-babel-default-header-args:* to
 org-babel-default-header-args-*

This makes them usable in file local variables.
---
 contrib/lisp/ob-eukleides.el     |    2 +-
 contrib/lisp/ob-fomus.el         |    2 +-
 contrib/lisp/ob-julia.el         |    2 +-
 contrib/lisp/ob-mathomatic.el    |    2 +-
 contrib/lisp/ob-tcl.el           |    2 +-
 lisp/ob-C.el                     |    2 +-
 lisp/ob-R.el                     |    2 +-
 lisp/ob-asymptote.el             |    2 +-
 lisp/ob-calc.el                  |    2 +-
 lisp/ob-clojure.el               |    2 +-
 lisp/ob-core.el                  |    4 ++--
 lisp/ob-css.el                   |    2 +-
 lisp/ob-ditaa.el                 |    2 +-
 lisp/ob-dot.el                   |    2 +-
 lisp/ob-emacs-lisp.el            |    2 +-
 lisp/ob-exp.el                   |    2 +-
 lisp/ob-fortran.el               |    2 +-
 lisp/ob-gnuplot.el               |    2 +-
 lisp/ob-haskell.el               |    2 +-
 lisp/ob-io.el                    |    2 +-
 lisp/ob-js.el                    |    2 +-
 lisp/ob-latex.el                 |    2 +-
 lisp/ob-ledger.el                |    2 +-
 lisp/ob-lilypond.el              |    6 +++---
 lisp/ob-lisp.el                  |    2 +-
 lisp/ob-makefile.el              |    2 +-
 lisp/ob-maxima.el                |    2 +-
 lisp/ob-mscgen.el                |    2 +-
 lisp/ob-ocaml.el                 |    2 +-
 lisp/ob-octave.el                |    4 ++--
 lisp/ob-org.el                   |    2 +-
 lisp/ob-perl.el                  |    2 +-
 lisp/ob-picolisp.el              |    2 +-
 lisp/ob-plantuml.el              |    2 +-
 lisp/ob-python.el                |    2 +-
 lisp/ob-ruby.el                  |    2 +-
 lisp/ob-sass.el                  |    2 +-
 lisp/ob-scala.el                 |    2 +-
 lisp/ob-scheme.el                |    2 +-
 lisp/ob-screen.el                |    4 ++--
 lisp/ob-sh.el                    |    2 +-
 lisp/ob-shen.el                  |    2 +-
 lisp/ob-sql.el                   |    2 +-
 lisp/ob-sqlite.el                |    2 +-
 testing/lisp/test-ob-lilypond.el |    8 ++++----
 45 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/contrib/lisp/ob-eukleides.el b/contrib/lisp/ob-eukleides.el
index e25ed1c..3747b4e 100644
--- a/contrib/lisp/ob-eukleides.el
+++ b/contrib/lisp/ob-eukleides.el
@@ -37,7 +37,7 @@
 (require 'ob)
 (require 'ob-eval)
 
-(defvar org-babel-default-header-args:eukleides
+(defvar org-babel-default-header-args-eukleides
   '((:results . "file") (:exports . "results"))
   "Default arguments for evaluating a eukleides source block.")
 
diff --git a/contrib/lisp/ob-fomus.el b/contrib/lisp/ob-fomus.el
index 58183fb..8914843 100644
--- a/contrib/lisp/ob-fomus.el
+++ b/contrib/lisp/ob-fomus.el
@@ -42,7 +42,7 @@
 (require 'ob)
 (require 'ob-eval)
 
-(defvar org-babel-default-header-args:fomus
+(defvar org-babel-default-header-args-fomus
   '((:results . "file") (:exports . "results"))
   "Default arguments to use when evaluating a fomus source block.")
 
diff --git a/contrib/lisp/ob-julia.el b/contrib/lisp/ob-julia.el
index 3aed818..61ece8d 100644
--- a/contrib/lisp/ob-julia.el
+++ b/contrib/lisp/ob-julia.el
@@ -51,7 +51,7 @@
 
 (add-to-list 'org-babel-tangle-lang-exts '("julia" . "jl"))
 
-(defvar org-babel-default-header-args:julia '())
+(defvar org-babel-default-header-args-julia '())
 
 (defcustom org-babel-julia-command inferior-julia-program-name
   "Name of command to use for executing julia code."
diff --git a/contrib/lisp/ob-mathomatic.el b/contrib/lisp/ob-mathomatic.el
index 585604e..717d2f0 100644
--- a/contrib/lisp/ob-mathomatic.el
+++ b/contrib/lisp/ob-mathomatic.el
@@ -40,7 +40,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("mathomatic" . "math"))
 
-(defvar org-babel-default-header-args:mathomatic '())
+(defvar org-babel-default-header-args-mathomatic '())
 
 (defcustom org-babel-mathomatic-command
   (if (boundp 'mathomatic-command) mathomatic-command "mathomatic")
diff --git a/contrib/lisp/ob-tcl.el b/contrib/lisp/ob-tcl.el
index e8d735b..d68b7d9 100644
--- a/contrib/lisp/ob-tcl.el
+++ b/contrib/lisp/ob-tcl.el
@@ -36,7 +36,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("tcl" . "tcl"))
 
-(defvar org-babel-default-header-args:tcl nil)
+(defvar org-babel-default-header-args-tcl nil)
 
 (defcustom org-babel-tcl-command "tclsh"
 "Name of command to use for executing Tcl code."
diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index b1e8a06..c2aaa1d 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -40,7 +40,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("C++" . "cpp"))
 
-(defvar org-babel-default-header-args:C '())
+(defvar org-babel-default-header-args-C '())
 
 (defvar org-babel-C-compiler "gcc"
   "Command used to compile a C source code file into an
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index 9875f81..9c40f68 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -65,7 +65,7 @@
 			    (output value graphics))))
   "R-specific header arguments.")
 
-(defvar org-babel-default-header-args:R '())
+(defvar org-babel-default-header-args-R '())
 
 (defcustom org-babel-R-command "R --slave --no-save"
   "Name of command to use for executing R code."
diff --git a/lisp/ob-asymptote.el b/lisp/ob-asymptote.el
index 4ea68df..1cb5625 100644
--- a/lisp/ob-asymptote.el
+++ b/lisp/ob-asymptote.el
@@ -51,7 +51,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("asymptote" . "asy"))
 
-(defvar org-babel-default-header-args:asymptote
+(defvar org-babel-default-header-args-asymptote
   '((:results . "file") (:exports . "results"))
   "Default arguments when evaluating an Asymptote source block.")
 
diff --git a/lisp/ob-calc.el b/lisp/ob-calc.el
index 766f6ce..803284c 100644
--- a/lisp/ob-calc.el
+++ b/lisp/ob-calc.el
@@ -36,7 +36,7 @@
 (declare-function calc-recall        "calc-store" (&optional var))
 (declare-function math-evaluate-expr "calc-ext"   (x))
 
-(defvar org-babel-default-header-args:calc nil
+(defvar org-babel-default-header-args-calc nil
   "Default arguments for evaluating an calc source block.")
 
 (defun org-babel-expand-body:calc (body params)
diff --git a/lisp/ob-clojure.el b/lisp/ob-clojure.el
index bc2bbc0..deff6d4 100644
--- a/lisp/ob-clojure.el
+++ b/lisp/ob-clojure.el
@@ -44,7 +44,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("clojure" . "clj"))
 
-(defvar org-babel-default-header-args:clojure '())
+(defvar org-babel-default-header-args-clojure '())
 (defvar org-babel-header-args:clojure '((package . :any)))
 
 (defun org-babel-expand-body:clojure (body params)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index a63f77e..4974cfe 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -1292,7 +1292,7 @@ may be specified in the properties of the current outline entry."
   "Parse the results from a match of the `org-babel-src-block-regexp'."
   (let* ((block-indentation (length (match-string 1)))
 	 (lang (org-no-properties (match-string 2)))
-         (lang-headers (intern (concat "org-babel-default-header-args:" lang)))
+         (lang-headers (intern (concat "org-babel-default-header-args-" lang)))
 	 (switches (match-string 3))
          (body (org-no-properties
 		(let* ((body (match-string 5))
@@ -1323,7 +1323,7 @@ may be specified in the properties of the current outline entry."
 (defun org-babel-parse-inline-src-block-match ()
   "Parse the results from a match of the `org-babel-inline-src-block-regexp'."
   (let* ((lang (org-no-properties (match-string 2)))
-         (lang-headers (intern (concat "org-babel-default-header-args:" lang))))
+         (lang-headers (intern (concat "org-babel-default-header-args-" lang))))
     (list lang
           (org-unescape-code-in-string (org-no-properties (match-string 5)))
           (org-babel-merge-params
diff --git a/lisp/ob-css.el b/lisp/ob-css.el
index a1205f5..b6bc5c0 100644
--- a/lisp/ob-css.el
+++ b/lisp/ob-css.el
@@ -29,7 +29,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:css '())
+(defvar org-babel-default-header-args-css '())
 
 (defun org-babel-execute:css (body params)
   "Execute a block of CSS code.
diff --git a/lisp/ob-ditaa.el b/lisp/ob-ditaa.el
index d3d76e5..bc8d979 100644
--- a/lisp/ob-ditaa.el
+++ b/lisp/ob-ditaa.el
@@ -39,7 +39,7 @@
 (require 'ob)
 (require 'org-compat)
 
-(defvar org-babel-default-header-args:ditaa
+(defvar org-babel-default-header-args-ditaa
   '((:results . "file")
     (:exports . "results")
     (:java . "-Dfile.encoding=UTF-8"))
diff --git a/lisp/ob-dot.el b/lisp/ob-dot.el
index 7504264..90dbfa2 100644
--- a/lisp/ob-dot.el
+++ b/lisp/ob-dot.el
@@ -40,7 +40,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:dot
+(defvar org-babel-default-header-args-dot
   '((:results . "file") (:exports . "results"))
   "Default arguments to use when evaluating a dot source block.")
 
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 886645d..df2c78e 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,7 +28,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:emacs-lisp
+(defvar org-babel-default-header-args-emacs-lisp
   '((:hlines . "yes") (:colnames . "no"))
   "Default arguments for evaluating an emacs-lisp source block.")
 
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 0d98690..6823c55 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -68,7 +68,7 @@ process."
 
 (defmacro org-babel-exp-in-export-file (lang &rest body)
   (declare (indent 1))
-  `(let* ((lang-headers (intern (concat "org-babel-default-header-args:" ,lang)))
+  `(let* ((lang-headers (intern (concat "org-babel-default-header-args-" ,lang)))
 	  (heading (nth 4 (ignore-errors (org-heading-components))))
 	  (export-buffer (current-buffer))
 	  (original-buffer (org-babel-exp-get-export-buffer)) results)
diff --git a/lisp/ob-fortran.el b/lisp/ob-fortran.el
index 1eab03e..a1b06c8 100644
--- a/lisp/ob-fortran.el
+++ b/lisp/ob-fortran.el
@@ -36,7 +36,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("fortran" . "F90"))
 
-(defvar org-babel-default-header-args:fortran '())
+(defvar org-babel-default-header-args-fortran '())
 
 (defvar org-babel-fortran-compiler "gfortran"
   "fortran command used to compile a fortran source code file into an
diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el
index 4b3a1c6..e0a6330 100644
--- a/lisp/ob-gnuplot.el
+++ b/lisp/ob-gnuplot.el
@@ -48,7 +48,7 @@
 (declare-function gnuplot-send-string-to-gnuplot "ext:gnuplot-mode" (str txt))
 (declare-function gnuplot-send-buffer-to-gnuplot "ext:gnuplot-mode" ())
 
-(defvar org-babel-default-header-args:gnuplot
+(defvar org-babel-default-header-args-gnuplot
   '((:results . "file") (:exports . "results") (:session . nil))
   "Default arguments to use when evaluating a gnuplot source block.")
 
diff --git a/lisp/ob-haskell.el b/lisp/ob-haskell.el
index a04963f..9ac3fe9 100644
--- a/lisp/ob-haskell.el
+++ b/lisp/ob-haskell.el
@@ -52,7 +52,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("haskell" . "hs"))
 
-(defvar org-babel-default-header-args:haskell '())
+(defvar org-babel-default-header-args-haskell '())
 
 (defvar org-babel-haskell-lhs2tex-command "lhs2tex")
 
diff --git a/lisp/ob-io.el b/lisp/ob-io.el
index af18f74..d10bf55 100644
--- a/lisp/ob-io.el
+++ b/lisp/ob-io.el
@@ -37,7 +37,7 @@
 
 (defvar org-babel-tangle-lang-exts) ;; Autoloaded
 (add-to-list 'org-babel-tangle-lang-exts '("io" . "io"))
-(defvar org-babel-default-header-args:io '())
+(defvar org-babel-default-header-args-io '())
 (defvar org-babel-io-command "io"
   "Name of the command to use for executing Io code.")
 
diff --git a/lisp/ob-js.el b/lisp/ob-js.el
index 8cae35b..0b1cba3 100644
--- a/lisp/ob-js.el
+++ b/lisp/ob-js.el
@@ -43,7 +43,7 @@
 
 (declare-function run-mozilla "ext:moz" (arg))
 
-(defvar org-babel-default-header-args:js '()
+(defvar org-babel-default-header-args-js '()
   "Default header arguments for js code blocks.")
 
 (defvar org-babel-js-eoe "org-babel-js-eoe"
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index 94d5133..3d2ce92 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -46,7 +46,7 @@
 (defvar org-latex-default-packages-alist) ; From org.el
 (defvar org-latex-packages-alist)	  ; From org.el
 
-(defvar org-babel-default-header-args:latex
+(defvar org-babel-default-header-args-latex
   '((:results . "latex") (:exports . "results"))
   "Default arguments to use when evaluating a LaTeX source block.")
 
diff --git a/lisp/ob-ledger.el b/lisp/ob-ledger.el
index 17911cc..c9fab4a 100644
--- a/lisp/ob-ledger.el
+++ b/lisp/ob-ledger.el
@@ -38,7 +38,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:ledger
+(defvar org-babel-default-header-args-ledger
   '((:results . "output") (:cmdline . "bal"))
   "Default arguments to use when evaluating a ledger source block.")
 
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 6080a5a..acd2313 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -36,7 +36,7 @@
 
 (add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
 
-(defvar org-babel-default-header-args:lilypond '()
+(defvar org-babel-default-header-args-lilypond '()
   "Default header arguments for lilypond code blocks.
 NOTE: The arguments are determined at lilypond compile time.
 See (ly-set-header-args)")
@@ -427,9 +427,9 @@ mode i.e.  ARRANGE-MODE is t"
            (:exports . "results")))))
 
 (defun ly-set-header-args (mode)
-  "Set org-babel-default-header-args:lilypond
+  "Set org-babel-default-header-args-lilypond
 dependent on LY-ARRANGE-MODE"
-  (setq org-babel-default-header-args:lilypond
+  (setq org-babel-default-header-args-lilypond
         (ly-get-header-args mode)))
 
 (provide 'ob-lilypond)
diff --git a/lisp/ob-lisp.el b/lisp/ob-lisp.el
index 2bb1a25..0433c34 100644
--- a/lisp/ob-lisp.el
+++ b/lisp/ob-lisp.el
@@ -40,7 +40,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("lisp" . "lisp"))
 
-(defvar org-babel-default-header-args:lisp '())
+(defvar org-babel-default-header-args-lisp '())
 (defvar org-babel-header-args:lisp '((package . :any)))
 
 (defcustom org-babel-lisp-dir-fmt
diff --git a/lisp/ob-makefile.el b/lisp/ob-makefile.el
index 7b0ff93..016651c 100644
--- a/lisp/ob-makefile.el
+++ b/lisp/ob-makefile.el
@@ -28,7 +28,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:makefile '())
+(defvar org-babel-default-header-args-makefile '())
 
 (defun org-babel-execute:makefile (body params)
   "Execute a block of makefile code.
diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index 916dd7e..6936dd0 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -38,7 +38,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("maxima" . "max"))
 
-(defvar org-babel-default-header-args:maxima '())
+(defvar org-babel-default-header-args-maxima '())
 
 (defcustom org-babel-maxima-command
   (if (boundp 'maxima-command) maxima-command "maxima")
diff --git a/lisp/ob-mscgen.el b/lisp/ob-mscgen.el
index 209ad7d..0c56071 100644
--- a/lisp/ob-mscgen.el
+++ b/lisp/ob-mscgen.el
@@ -56,7 +56,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:mscgen
+(defvar org-babel-default-header-args-mscgen
   '((:results . "file") (:exports . "results"))
   "Default arguments to use when evaluating a mscgen source block.")
 
diff --git a/lisp/ob-ocaml.el b/lisp/ob-ocaml.el
index 9390fab..5919c42 100644
--- a/lisp/ob-ocaml.el
+++ b/lisp/ob-ocaml.el
@@ -46,7 +46,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("ocaml" . "ml"))
 
-(defvar org-babel-default-header-args:ocaml '())
+(defvar org-babel-default-header-args-ocaml '())
 
 (defvar org-babel-ocaml-eoe-indicator "\"org-babel-ocaml-eoe\";;")
 (defvar org-babel-ocaml-eoe-output "org-babel-ocaml-eoe")
diff --git a/lisp/ob-octave.el b/lisp/ob-octave.el
index c2a3abb..77e68a8 100644
--- a/lisp/ob-octave.el
+++ b/lisp/ob-octave.el
@@ -35,8 +35,8 @@
 (declare-function matlab-shell "ext:matlab-mode")
 (declare-function matlab-shell-run-region "ext:matlab-mode")
 
-(defvar org-babel-default-header-args:matlab '())
-(defvar org-babel-default-header-args:octave '())
+(defvar org-babel-default-header-args-matlab '())
+(defvar org-babel-default-header-args-octave '())
 
 (defvar org-babel-matlab-shell-command "matlab -nosplash"
   "Shell command to run matlab as an external process.")
diff --git a/lisp/ob-org.el b/lisp/ob-org.el
index 18cce3b..eecf802 100644
--- a/lisp/ob-org.el
+++ b/lisp/ob-org.el
@@ -32,7 +32,7 @@
 (declare-function org-export-string-as "ox"
 		  (string backend &optional body-only ext-plist))
 
-(defvar org-babel-default-header-args:org
+(defvar org-babel-default-header-args-org
   '((:results . "raw silent") (:exports . "code"))
   "Default arguments for evaluating a org source block.")
 
diff --git a/lisp/ob-perl.el b/lisp/ob-perl.el
index 117782f..4e38319 100644
--- a/lisp/ob-perl.el
+++ b/lisp/ob-perl.el
@@ -33,7 +33,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("perl" . "pl"))
 
-(defvar org-babel-default-header-args:perl '())
+(defvar org-babel-default-header-args-perl '())
 
 (defvar org-babel-perl-command "perl"
   "Name of command to use for executing perl code.")
diff --git a/lisp/ob-picolisp.el b/lisp/ob-picolisp.el
index e785366..99fb254 100644
--- a/lisp/ob-picolisp.el
+++ b/lisp/ob-picolisp.el
@@ -65,7 +65,7 @@
 
 ;;; interferes with settings in org-babel buffer?
 ;; optionally declare default header arguments for this language
-;; (defvar org-babel-default-header-args:picolisp
+;; (defvar org-babel-default-header-args-picolisp
 ;;   '((:colnames . "no"))
 ;;   "Default arguments for evaluating a picolisp source block.")
 
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index c17d444..0046d3b 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -36,7 +36,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:plantuml
+(defvar org-babel-default-header-args-plantuml
   '((:results . "file") (:exports . "results"))
   "Default arguments for evaluating a plantuml source block.")
 
diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 7bc9a1f..195c6ab 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -38,7 +38,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("python" . "py"))
 
-(defvar org-babel-default-header-args:python '())
+(defvar org-babel-default-header-args-python '())
 
 (defcustom org-babel-python-command "python"
   "Name of the command for executing Python code."
diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
index bef8fba..b0a040c 100644
--- a/lisp/ob-ruby.el
+++ b/lisp/ob-ruby.el
@@ -45,7 +45,7 @@
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("ruby" . "rb"))
 
-(defvar org-babel-default-header-args:ruby '())
+(defvar org-babel-default-header-args-ruby '())
 
 (defvar org-babel-ruby-command "ruby"
   "Name of command to use for executing ruby code.")
diff --git a/lisp/ob-sass.el b/lisp/ob-sass.el
index cdb75be..d9ee093 100644
--- a/lisp/ob-sass.el
+++ b/lisp/ob-sass.el
@@ -40,7 +40,7 @@
 ;;; Code:
 (require 'ob)
 
-(defvar org-babel-default-header-args:sass '())
+(defvar org-babel-default-header-args-sass '())
 
 (defun org-babel-execute:sass (body params)
   "Execute a block of Sass code with Babel.
diff --git a/lisp/ob-scala.el b/lisp/ob-scala.el
index 7cb3099..5f34401 100644
--- a/lisp/ob-scala.el
+++ b/lisp/ob-scala.el
@@ -35,7 +35,7 @@
 
 (defvar org-babel-tangle-lang-exts) ;; Autoloaded
 (add-to-list 'org-babel-tangle-lang-exts '("scala" . "scala"))
-(defvar org-babel-default-header-args:scala '())
+(defvar org-babel-default-header-args-scala '())
 (defvar org-babel-scala-command "scala"
   "Name of the command to use for executing Scala code.")
 
diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index c9fa44a..c37af38 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -42,7 +42,7 @@
 
 (declare-function run-scheme "ext:cmuscheme" (cmd))
 
-(defvar org-babel-default-header-args:scheme '()
+(defvar org-babel-default-header-args-scheme '()
   "Default header arguments for scheme code blocks.")
 
 (defvar org-babel-scheme-eoe "org-babel-scheme-eoe"
diff --git a/lisp/ob-screen.el b/lisp/ob-screen.el
index f263376..f57924b 100644
--- a/lisp/ob-screen.el
+++ b/lisp/ob-screen.el
@@ -39,7 +39,7 @@
   "The command location for screen.
 In case you want to use a different screen than one selected by your $PATH")
 
-(defvar org-babel-default-header-args:screen
+(defvar org-babel-default-header-args-screen
   '((:results . "silent") (:session . "default") (:cmd . "sh") (:terminal . "xterm"))
   "Default arguments to use when running screen source blocks.")
 
@@ -124,7 +124,7 @@ The terminal should shortly flicker."
          (tmpfile "/tmp/org-babel-screen.test")
          (body (concat "echo '" random-string "' > " tmpfile "\nexit\n"))
          process tmp-string)
-    (org-babel-execute:screen body org-babel-default-header-args:screen)
+    (org-babel-execute:screen body org-babel-default-header-args-screen)
     ;; XXX: need to find a better way to do the following
     (while (not (file-readable-p tmpfile))
       ;; do something, otherwise this will be optimized away
diff --git a/lisp/ob-sh.el b/lisp/ob-sh.el
index f11b799..39f5e30 100644
--- a/lisp/ob-sh.el
+++ b/lisp/ob-sh.el
@@ -36,7 +36,7 @@
 (declare-function org-babel-comint-with-output "ob-comint" (meta &rest body))
 (declare-function orgtbl-to-generic "org-table" (table params))
 
-(defvar org-babel-default-header-args:sh '())
+(defvar org-babel-default-header-args-sh '())
 
 (defvar org-babel-sh-command "sh"
   "Command used to invoke a shell.
diff --git a/lisp/ob-shen.el b/lisp/ob-shen.el
index a41580f..61a4ea6 100644
--- a/lisp/ob-shen.el
+++ b/lisp/ob-shen.el
@@ -37,7 +37,7 @@
 
 (declare-function shen-eval-defun "ext:inf-shen" (&optional and-go))
 
-(defvar org-babel-default-header-args:shen '()
+(defvar org-babel-default-header-args-shen '()
   "Default header arguments for shen code blocks.")
 
 (defun org-babel-expand-body:shen (body params)
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 658a54f..7b59aaa 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -62,7 +62,7 @@
 (declare-function orgtbl-to-csv "org-table" (table params))
 (declare-function org-table-to-lisp "org-table" (&optional txt))
 
-(defvar org-babel-default-header-args:sql '())
+(defvar org-babel-default-header-args-sql '())
 
 (defconst org-babel-header-args:sql
   '((engine	       . :any)
diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el
index 84d4688..9008bd9 100644
--- a/lisp/ob-sqlite.el
+++ b/lisp/ob-sqlite.el
@@ -34,7 +34,7 @@
 (declare-function orgtbl-to-csv "org-table" (table params))
 (declare-function org-table-to-lisp "org-table" (&optional txt))
 
-(defvar org-babel-default-header-args:sqlite '())
+(defvar org-babel-default-header-args-sqlite '())
 
 (defvar org-babel-header-args:sqlite
   '((db        . :any)
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 4a155a8..2f48198 100644
--- a/testing/lisp/test-ob-lilypond.el
+++ b/testing/lisp/test-ob-lilypond.el
@@ -128,12 +128,12 @@
 (ert-deftest ob-lilypond/ly-arrange-mode ()
   (should (boundp 'ly-arrange-mode)))
 
-;; (ert-deftest ob-lilypond/org-babel-default-header-args:lilypond ()
+;; (ert-deftest ob-lilypond/org-babel-default-header-args-lilypond ()
 ;;   (should (equal  '((:tangle . "yes")
 ;;                     (:noweb . "yes")
 ;;                     (:results . "silent")
 ;;                     (:comments . "yes"))
-;;                   org-babel-default-header-args:lilypond)))
+;;                   org-babel-default-header-args-lilypond)))
 
 ;;TODO finish...
 (ert-deftest ob-lilypond/org-babel-expand-body:lilypond ()
@@ -380,11 +380,11 @@
                    (:results . "silent")
                    (:cache . "yes")
                    (:comments . "yes"))
-                 org-babel-default-header-args:lilypond))
+                 org-babel-default-header-args-lilypond))
   (ly-set-header-args nil)
   (should (equal '((:results . "file")
                    (:exports . "results"))
-                 org-babel-default-header-args:lilypond)))
+                 org-babel-default-header-args-lilypond)))
 
 (provide 'test-ob-lilypond)
 
-- 
1.7.10.4

Re: :session question - a simple PATCH

[Achim Gratz]

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, of course, but sets the R-session globally.
>
> - The file-local variables (both way to set them) choke on the colon in
>    the varible name.

You could use

eval: (setq etq org-babel-default-header-args:R '((:session . "org-R")))

instead of setting the variable directly.

> I do not know where to search for the reason, these variables work for
> Eric but not for me (and John...).

I don't think they work for Eric if he tries to set them as file variable.

> So attached is a simple patch (search-and-replace) that renames all
> org-babel-default-header-args:* variables to
> org-babel-default-header-args-*

In keeping with the spirit of the original naming I'd suggest switching 
from ":" to "/".  I still think this is a bug in how Emacs evaluates the 
local variables, but since it has been that way for ages it probably has 
become a feature.


Regards,
-- 
Achim.

(on the road :-)

Re: :session question - a simple PATCH

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Achim Gratz <Stromeko@Nexgo.DE> 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
>>            '((:session . "org-R")))
>>    #+end_src
>>    works, of course, but sets the R-session globally.
>>
>> - The file-local variables (both way to set them) choke on the colon in
>>    the varible name.
>
> You could use
>
> eval: (setq etq org-babel-default-header-args:R '((:session . "org-R")))
>
> instead of setting the variable directly.
>

The above sets the value globally, the following should work for
everyone.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: bar.org --]
[-- Type: text/x-org, Size: 251 bytes --]

#+Title: Example

The value in this buffer is...
#+begin_src emacs-lisp
  org-babel-default-header-args:R
#+end_src

#+RESULTS:
| (:session . bar) |

# Local Variables:
# eval: (setq-local org-babel-default-header-args:R '((:session . "bar")))
# End:

[-- Attachment #3: Type: text/plain, Size: 847 bytes --]


>
>> I do not know where to search for the reason, these variables work for
>> Eric but not for me (and John...).
>
> I don't think they work for Eric if he tries to set them as file variable.
>

This was my fault.  I miss-interpreted what was happening on my system,
these aren't working for me either.

>
>> So attached is a simple patch (search-and-replace) that renames all
>> org-babel-default-header-args:* variables to
>> org-babel-default-header-args-*
>
> In keeping with the spirit of the original naming I'd suggest
> switching from ":" to "/".  I still think this is a bug in how Emacs
> evaluates the local variables, but since it has been that way for ages
> it probably has become a feature.
>

I agree that this is an Emacs bug.  The attached patch fixes this bug, I
suppose it should be submitted to the emacs-dev mailing list.


[-- Attachment #4: temporary-file-variables-w-colons.txt --]
[-- Type: text/plain, Size: 2593 bytes --]

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: schulte.eric@gmail.com-20130328230926-46be4fl21w1g28wc
# target_branch: http://bzr.savannah.gnu.org/r/emacs/trunk/
# testament_sha1: 969600ed8b879f2317f13e9f06968aafad4f786d
# timestamp: 2013-03-28 17:09:47 -0600
# base_revision_id: monnier@iro.umontreal.ca-20130328163306-\
#   419khox8aneaoaxv
# 
# Begin patch
=== modified file 'lisp/files.el'
--- lisp/files.el	2013-03-24 06:42:25 +0000
+++ lisp/files.el	2013-03-28 23:09:26 +0000
@@ -3058,7 +3058,11 @@
 	       (while (and (or (not mode-only)
 			       (not result))
 			   (< (point) end))
-		 (unless (looking-at "[ \t]*\\([^ \t\n:]+\\)[ \t]*:[ \t]*")
+                 ;; The first of these next two regexs handles the
+                 ;; case when a variable name includes a ":", such as
+                 ;; the `org-babel-default-header-args:R' variable.
+		 (unless (or (looking-at "[ \t]*\\([^ \t\n]?+\\)[ \t]*:[ \t]*")
+                             (looking-at "[ \t]*\\([^ \t\n:]+\\)[ \t]*:[ \t]*"))
 		   (message "Malformed mode-line")
 		   (throw 'malformed-line nil))
 		 (goto-char (match-end 0))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWUbmhKQAAan/gAAyACBQ////
0gAcD/////BQA80t1o3vPXpy93vdCSSJiMIGmJNhCT9FNMninqBiY0CDJEniaZNJ6T0oYR6gAAAA
AAyTEmSnhRmkDT1AAyDQB6hoADakmp5DRTam1DajamgA0PUAaAAAkkmkwmFPJijRkzRAAHqAGgAz
S1WEfhTwKtT3Lzh0ptUwFljq3RvPzgDg4+hi9JNFWatAiacBNp3IkDC56rp8faNALW4WJH9ce0I4
Z3GPJC6C2Mb/dxhkm8cOfdIQ66fN3VUdhn4rW+w5H6/o92st+ja2A7xflnsZ06UJhX+y7kGzooqq
7W3cVuusjwpFyfSvT2myqcZODnTyKrAEMOEEaFAZApCpsCwwBUubxmdbx0obNO9dlFeiheV1LyDX
grJNYIaa/OZTZslmmUv7NSjYTFSk0HuVurzo5oI0iIlY6e7GirGiM9qyooTyBr4gzgBdrWq+Udoe
0ELOU2gsNRtBGh50VBsck88MdLUo+pMxY1mqNkZFkcH8gVyOKsQDBAUtQV1RrZdWaaXBQEh+HE2Q
kWgqVFNjBZWqkg2pKMldeUECX3XNq1r2CtxigWqRU0OaIkCCVas9HdcHxV+nLC8RBtcVmSA7SxMZ
lwmjRRgRp2L4OsGG70jewey+edEe9QsThoPhM5SSi9uw8jxVmjPJsysa316MLrg4yithl8O1FIx2
kx7GAZzYWEYDCjyehjfA4NODyIKlnHwdst+b6fwry3abeeHKHYZrQ1gPqOmhUQTyKFRZZUcuSiqp
fIVPxXdinnCWLtFgZlnmXMvCh31Y6oR6F1mRwbL00PMnsNGv4VJfH63gBQrSAFt2TFK9pSLnQIUs
UEFLiW0xQw6o1drbk1zomZn0mlK6/l1Z1i/dpsovmyXGNUqwMRMb5wOO+4BiSsMIWzRm7CEds32t
xSnyoRc8RLKQ0YK1qmSsgqRtgjenIw0zyJ+3ZXoWrebSiyCwcsp67r24c2dGLM4pHGjGLGjH7AP9
/hT1q4JHj3qme3tF4qRBYqISdCql/Uzk+8rA3UoDaUwY2PDLU/IFNql4g1W3xQa7jkVwazlnC1Xg
bcAUimCaAIYmZiBzlVrw524UmJwhskwG4DTYolplKIXliWBxlgZsB4MzXkHiZKaaYz5CjEbRQJxB
wxlfWTlI6mdWCDgOSQMw0X7QHH/SKlmxuydL7cEQqDEdmqoZsyqoSoGVLDqORLbUOwFGCE7rGkzW
tXehClq6UIvm2YaBqeCIc0js7FE4NKr4IjM2IK2kU9OW5+kBzyGEE5o1MnSclPbVJUJUhMxGO6ak
Kb5XiWBuQ0UmBkKFYFeIWApYzQralEo0UqwMw60f/i7kinChII3NCUg=

[-- Attachment #5: Type: text/plain, Size: 71 bytes --]


Cheers,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Achim Gratz]

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've checked that the property interface returns the data
as expected, but I haven't implemented anything yet.  It does not seem
to be an overly difficult endeavour, however.

>> But importantly, there should be no way to set a default session name
>> without also specifying the language, regardless of which way one
>> tries to set this up.
>
> If you can think of a clean way to implement this then we should go for
> it.  I doubt many existing configurations rely on this behavior.

General settings for all languages should be effected by

#+PROPERTY: header-args :results value :exports none

and there'd be a list of header arguments (or specific values) that are
either ignored or warned about when not associated with a particular
language.

BTW, I think the current property syntax for header arguments should be
deprecated since it is the only place where the leading ":" is missing
for those.

Comments, thoughts?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: :session question

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> 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*" :exports none
>
> should work.

I hate to change syntax, but the syntax you mention above does look both
appealing and natural.  Even with working file local variables [1].

> I've checked that the property interface returns the data as expected,
> but I haven't implemented anything yet.  It does not seem to be an
> overly difficult endeavour, however.
>

That is very good news.  With that portion working I would agree that
this should be a fairly straightforward task.

>
>>> But importantly, there should be no way to set a default session name
>>> without also specifying the language, regardless of which way one
>>> tries to set this up.
>>
>> If you can think of a clean way to implement this then we should go for
>> it.  I doubt many existing configurations rely on this behavior.
>
> General settings for all languages should be effected by
>
> #+PROPERTY: header-args :results value :exports none
>
> and there'd be a list of header arguments (or specific values) that are
> either ignored or warned about when not associated with a particular
> language.
>
> BTW, I think the current property syntax for header arguments should be
> deprecated since it is the only place where the leading ":" is missing
> for those.
>
> Comments, thoughts?
>

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
valuable than my own in this regard (as I'm not a heavy #+Property
user).

Thanks for the clean and initially tested implementation idea!

>
>
> Regards,
> Achim.


Footnotes: 

[1]  Thanks to Bastien my patch allowing variables like
     `org-babel-default-header-args:R' to be set file-local has been
     applied to Emacs.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question

[Achim Gratz]

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 interface returns the data as expected,
>> but I haven't implemented anything yet.  It does not seem to be an
>> overly difficult endeavour, however.
>>
>
> That is very good news.  With that portion working I would agree that
> this should be a fairly straightforward task.
[…]
> 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'll try to get something working.  Not immediately, but I'll see when I
can shoe it in.

> I'm surprised that none of the users who motivated this discussion
> have chimed in.  Their opinions may be more valuable than my own in
> this regard (as I'm not a heavy #+Property user).

Well, feedback from users would of course be welcome, but I don't expect
anything really until there's some working code to show.

> Thanks for the clean and initially tested implementation idea!

Thanks for your comments.

> [1]  Thanks to Bastien my patch allowing variables like
>      `org-babel-default-header-args:R' to be set file-local has been
>      applied to Emacs.

… but it will only be available from 24.4 onward.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: :session question

[Achim Gratz]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

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
> valuable than my own in this regard (as I'm not a heavy #+Property
> user).

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 (help is
welcome).  Also, a new-style form of specifying header arguments for all
languages (to then deprecate the old form) is missing at the moment
since I'd like to get feedback on the language specific side first.


With these caveats, here's the patchset:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org.el-improve-org-property-re-and-use-it-throughout.patch --]
[-- Type: text/x-patch, Size: 5278 bytes --]

From fe5f9f46896939179f0163c2ce10f8738ebde709 Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Thu, 9 May 2013 19:47:59 +0200
Subject: [PATCH 1/2] org.el: improve org-property-re and use it throughout

* lisp/org.el (org-property-re): Improve definition so that this regex
  can be used in all situations.  Extend docstring with explanation of
  matching groups.
  (org-at-property-p): Implement using `org-element-at-point'.
  (org-entry-properties, org-buffer-property-keys, org-indent-line):
  Use `org-property-re' and adjust match group numbers accordingly.

* lisp/org-element.el (org-element-node-property-parser): Use
  `org-property-re' and adjust match group numbers accordingly.  Move
  `looking-at' out of the let clause to not rely on the unspecified
  evaluation order inside the let.
---
 lisp/org-element.el |  6 +++---
 lisp/org.el         | 40 ++++++++++++++++++++--------------------
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index aafba88..f180f91 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -1973,11 +1973,11 @@ (defun org-element-node-property-parser (limit)
 containing `:key', `:value', `:begin', `:end' and `:post-blank'
 keywords."
   (save-excursion
+    (looking-at org-property-re)
     (let ((case-fold-search t)
 	  (begin (point))
-	  (key (progn (looking-at "[ \t]*:\\(.*?\\):[ \t]+\\(.*?\\)[ \t]*$")
-		      (org-match-string-no-properties 1)))
-	  (value (org-match-string-no-properties 2))
+	  (key   (org-match-string-no-properties 2))
+	  (value (org-match-string-no-properties 3))
 	  (pos-before-blank (progn (forward-line) (point)))
 	  (end (progn (skip-chars-forward " \r\t\n" limit)
 		      (if (eobp) (point) (point-at-bol)))))
diff --git a/lisp/org.el b/lisp/org.el
index 1e28d93..b2e3836 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6139,8 +6139,15 @@ (defun org-outline-level ()
 
 (defvar org-font-lock-keywords nil)
 
-(defconst org-property-re (org-re "^[ \t]*\\(:\\([-[:alnum:]_]+\\+?\\):\\)[ \t]*\\([^ \t\r\n].*\\)")
-  "Regular expression matching a property line.")
+(defconst org-property-re
+  "^\\(?4:[ \t]*\\)\\(?1::\\(?2:.*?\\):\\)[ \t]+\\(?3:[^ \t\r\n].*?\\)\\(?5:[ \t]*\\)$"
+  "Regular expression matching a property line.
+There are four matching groups:
+1: :PROPKEY: including the leading and trailing colon,
+2: PROPKEY without the leading and trailing colon,
+3: PROPVAL without leading or trailing spaces,
+4: the indentation of the current line,
+5: trailing whitespace.")
 
 (defvar org-font-lock-hook nil
   "Functions to be called for special font lock stuff.")
@@ -15116,13 +15123,9 @@ (defun org-set-effort (&optional value increment)
 (defun org-at-property-p ()
   "Is cursor inside a property drawer?"
   (save-excursion
-    (beginning-of-line 1)
-    (when (looking-at (org-re "^[ \t]*\\(:\\([[:alpha:]][[:alnum:]_-]*\\):\\)[ \t]*\\(.*\\)"))
-      (save-match-data ;; Used by calling procedures
-	(let ((p (point))
-	      (range (unless (org-before-first-heading-p)
-		       (org-get-property-block))))
-	  (and range (<= (car range) p) (< p (cdr range))))))))
+    (when (equal 'node-property (car (org-element-at-point)))
+      (beginning-of-line 1)
+      (looking-at org-property-re))))
 
 (defun org-get-property-block (&optional beg end force)
   "Return the (beg . end) range of the body of the property drawer.
@@ -15247,11 +15250,10 @@ (defun org-entry-properties (&optional pom which specific)
 	    (setq range (org-get-property-block beg end))
 	    (when range
 	      (goto-char (car range))
-	      (while (re-search-forward
-		      (org-re "^[ \t]*:\\([[:alpha:]][[:alnum:]_-]*\\):[ \t]*\\(\\S-.*\\)?")
+	      (while (re-search-forward org-property-re
 		      (cdr range) t)
-		(setq key (org-match-string-no-properties 1)
-		      value (org-trim (or (org-match-string-no-properties 2) "")))
+		(setq key (org-match-string-no-properties 2)
+		      value (org-trim (or (org-match-string-no-properties 3) "")))
 		(unless (member key excluded)
 		  (push (cons key (or value "")) props)))))
 	  (if clocksum
@@ -15520,10 +15522,9 @@ (defun org-buffer-property-keys (&optional include-specials include-defaults inc
 	(while (re-search-forward org-property-start-re nil t)
 	  (setq range (org-get-property-block))
 	  (goto-char (car range))
-	  (while (re-search-forward
-		  (org-re "^[ \t]*:\\([-[:alnum:]_]+\\):")
+	  (while (re-search-forward org-property-re
 		  (cdr range) t)
-	    (add-to-list 'rtn (org-match-string-no-properties 1)))
+	    (add-to-list 'rtn (org-match-string-no-properties 2)))
 	  (outline-next-heading))))
 
     (when include-specials
@@ -22029,11 +22030,10 @@ (defun org-indent-line ()
       ;; Special polishing for properties, see `org-property-format'
       (setq column (current-column))
       (beginning-of-line 1)
-      (if (looking-at
-	   "\\([ \t]*\\)\\(:[-_0-9a-zA-Z]+:\\)[ \t]*\\(\\S-.*\\(\\S-\\|$\\)\\)")
-	  (replace-match (concat (match-string 1)
+      (if (looking-at org-property-re)
+	  (replace-match (concat (match-string 4)
 				 (format org-property-format
-					 (match-string 2) (match-string 3)))
+					 (match-string 1) (match-string 3)))
 			 t t))
       (org-move-to-column column))))
 
-- 
1.8.2.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-ob-core-allow-language-specific-header-arguments-in-.patch --]
[-- Type: text/x-patch, Size: 2916 bytes --]

From 659663d7f053f85872e572aca83541b470070abf Mon Sep 17 00:00:00 2001
From: Achim Gratz <Stromeko@Stromeko.DE>
Date: Thu, 9 May 2013 20:01:45 +0200
Subject: [PATCH 2/2] ob-core: allow language specific header arguments in
 properties

* lisp/ob-core.el (org-babel-insert-header-arg,
  org-babel-parse-src-block-match): Replace `if' with empty else part
  by `when' for readability.
  (org-babel-parse-src-block-match,
  org-babel-parse-inline-src-block-match): Inquire for language
  specific header args from properties and integrate them after other
  default header args.

This allows for header arguments to be specified as
properties (including inheritance).

#+PROPERTY: header-args:R :session "*R-property*"

:PROPERTIES:
:header-args:R: :session "*R-drawer*"
:END:
---
 lisp/ob-core.el | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index 06d2520..c719089 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -757,7 +757,7 @@ (defun org-babel-insert-header-arg ()
 	 (lang-headers (intern (concat "org-babel-header-args:" lang)))
 	 (headers (org-babel-combine-header-arg-lists
 		   org-babel-common-header-args-w-values
-		   (if (boundp lang-headers) (eval lang-headers) nil)))
+		   (when (boundp lang-headers) (eval lang-headers))))
 	 (arg (org-icompleting-read
 	       "Header Arg: "
 	       (mapcar
@@ -1309,6 +1309,9 @@ (defun org-babel-parse-src-block-match ()
   (let* ((block-indentation (length (match-string 1)))
 	 (lang (org-no-properties (match-string 2)))
          (lang-headers (intern (concat "org-babel-default-header-args:" lang)))
+	 (lang-props (save-match-data
+		       (org-entry-get (point) (concat "header-args:" lang)
+				      'inherit 'literal-nil)))
 	 (switches (match-string 3))
          (body (org-no-properties
 		(let* ((body (match-string 5))
@@ -1329,8 +1332,9 @@ (defun org-babel-parse-src-block-match ()
               (buffer-string)))
 	  (org-babel-merge-params
 	   org-babel-default-header-args
-	   (if (boundp lang-headers) (eval lang-headers) nil)
+	   (when (boundp lang-headers) (eval lang-headers))
            (org-babel-params-from-properties lang)
+	   (org-babel-parse-header-arguments lang-props)
 	   (org-babel-parse-header-arguments
             (org-no-properties (or (match-string 4) ""))))
 	  switches
@@ -1339,6 +1343,9 @@ (defun org-babel-parse-src-block-match ()
 (defun org-babel-parse-inline-src-block-match ()
   "Parse the results from a match of the `org-babel-inline-src-block-regexp'."
   (let* ((lang (org-no-properties (match-string 2)))
+	 (lang-props (save-match-data
+		       (org-entry-get (point) (concat "header-args:" lang)
+				      'inherit 'literal-nil)))
          (lang-headers (intern (concat "org-babel-default-header-args:" lang))))
     (list lang
           (org-unescape-code-in-string (org-no-properties (match-string 5)))
-- 
1.8.2.1


[-- Attachment #4: Type: text/plain, Size: 187 bytes --]



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: :session question

[Achim Gratz]

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 (help is
> welcome).  Also, a new-style form of specifying header arguments for all
> languages (to then deprecate the old form) is missing at the moment
> since I'd like to get feedback on the language specific side first.

No comments?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> 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 write tests and documentation (help is
>> welcome).  Also, a new-style form of specifying header arguments for all
>> languages (to then deprecate the old form) is missing at the moment
>> since I'd like to get feedback on the language specific side first.
>
> No comments?
>

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.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 asking for a way to
specify header args at a finer granularity than just file variables
would have a say.

As a clarification: I'm not changing property syntax at all, I'm adding
new properties that happen to have values that look like the header
arguments to a source block.  I've also implemented default
(non-language-specific) header arguments just now.  Unless you use the
new property names none of the current behaviour changes (I do think the
old properties should be removed some time later when people had time to
convert their documents), but using the new property names will take
precedence.  This means if you specify 'cache "yes"' and also
'header-args :cache "no"' via properties, then the latter will take
effect.

Documentation and tests are still missing, but it shouldn't take too
long I hope.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: :session question -- and changes to #+Property: syntax

[Andreas Leha]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> 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 hoping that one of the users that was asking for a way to
> specify header args at a finer granularity than just file variables
> would have a say.
>
> As a clarification: I'm not changing property syntax at all, I'm adding
> new properties that happen to have values that look like the header
> arguments to a source block.  I've also implemented default
> (non-language-specific) header arguments just now.  Unless you use the
> new property names none of the current behaviour changes (I do think the
> old properties should be removed some time later when people had time to
> convert their documents), but using the new property names will take
> precedence.  This means if you specify 'cache "yes"' and also
> 'header-args :cache "no"' via properties, then the latter will take
> effect.
>
> Documentation and tests are still missing, but it shouldn't take too
> long I hope.
>

I just applied your patches.  Besides a quick test that went very well,
I can not say much.  The functionality is exactly what would help me a
lot to separate session information for R and shell blocks.  But given
the example in the code, this is known to you.

I would love to see that functionality in org and did not experience any
problems after applying the patches.

Regards,
Andreas

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 me explain.  The
first patch that makes Org use the same regex in all places where a
property is used does indeed change some behaviour, but not the syntax
of the property line:

:PROPERTY: VALUE

where PROPERTY can contain any non-whitespace character (in
correspondence to how the keyword PROPERTY is treated in org.el since it
is not explicitly specified in org-element).

However, there were other places in Org where a more restricted syntax
for properties in property drawers was used, which would have precluded
the use of ":" in property names and made it impossible to overwrite an
inherited property from a #+PROPERTY: line that has such a property
name.

I've taken org-element as the authoritative source for the syntax and
eliminated the other interpretations based on the fact that while the
behaviour visible in the buffer (highlighting, prompts, etc.) would hint
differently, the actual property handling was using the syntax used in
org-element already.  Hence if documents existed that had mistakenly
made use of these differences, they were already broken and would be
interpreted via the property API as they are now also shown after this
change.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> 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 understand what you're getting at, let me explain.  The
> first patch that makes Org use the same regex in all places where a
> property is used does indeed change some behaviour, but not the syntax
> of the property line:
>
> :PROPERTY: VALUE
>
> where PROPERTY can contain any non-whitespace character (in
> correspondence to how the keyword PROPERTY is treated in org.el since it
> is not explicitly specified in org-element).
>
> However, there were other places in Org where a more restricted syntax
> for properties in property drawers was used, which would have precluded
> the use of ":" in property names and made it impossible to overwrite an
> inherited property from a #+PROPERTY: line that has such a property
> name.
>
> I've taken org-element as the authoritative source for the syntax and
> eliminated the other interpretations based on the fact that while the
> behaviour visible in the buffer (highlighting, prompts, etc.) would hint
> differently, the actual property handling was using the syntax used in
> org-element already.  Hence if documents existed that had mistakenly
> made use of these differences, they were already broken and would be
> interpreted via the property API as they are now also shown after this
> change.
>

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.

There are stable releases precisely so that we can experiment
interactively on the development head.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 part as well, but I'll need
another week or so for properly documenting it in the manual and setting
up a test.  Unless someone urgently wants to do something with it, I'd
rather push these things together.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: :session question

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]


top post - sorry: I overlooked this thread somehow.

Eric Schulte <schulte.eric@gmail.com> writes:

> Achim Gratz <Stromeko@nexgo.de> 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*" :exports none
>>
>> should work.
>
> I hate to change syntax, but the syntax you mention above does look both
> appealing and natural.  Even with working file local variables [1].

I agree - it looks very intuitive.

>
>> I've checked that the property interface returns the data as expected,
>> but I haven't implemented anything yet.  It does not seem to be an
>> overly difficult endeavour, however.
>>
>
> That is very good news.  With that portion working I would agree that
> this should be a fairly straightforward task.
>
>>
>>>> But importantly, there should be no way to set a default session name
>>>> without also specifying the language, regardless of which way one
>>>> tries to set this up.
>>>
>>> If you can think of a clean way to implement this then we should go for
>>> it.  I doubt many existing configurations rely on this behavior.
>>
>> General settings for all languages should be effected by
>>
>> #+PROPERTY: header-args :results value :exports none
>>
>> and there'd be a list of header arguments (or specific values) that are
>> either ignored or warned about when not associated with a particular
>> language.
>>
>> BTW, I think the current property syntax for header arguments should be
>> deprecated since it is the only place where the leading ":" is missing
>> for those.
>>
>> Comments, thoughts?
>>
>
> 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

Shame on my head - here are now a few comments (and praises) following
in next emails.

Cheers,

Rainer

> valuable than my own in this regard (as I'm not a heavy #+Property
> user).
>
> Thanks for the clean and initially tested implementation idea!
>
>>
>>
>> Regards,
>> Achim.
>
>
> Footnotes: 
>
> [1]  Thanks to Bastien my patch allowing variables like
>      `org-babel-default-header-args:R' to be set file-local has been
>      applied to Emacs.

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: :session question

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

Achim Gratz <Stromeko@nexgo.de> 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 write tests and documentation (help is
>> welcome).  Also, a new-style form of specifying header arguments for all
>> languages (to then deprecate the old form) is missing at the moment
>> since I'd like to get feedback on the language specific side first.
>
> No comments?

Not tested, but it I like the idea and the syntax - very nice indeed.

Cheers,

Rainer

>
>
> Regards,
> Achim.


-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: :session question -- and changes to #+Property: syntax

[Rainer M Krug]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Hi Achim,
>
> Achim Gratz <Stromeko@nexgo.de> 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 hoping that one of the users that was asking for a way to
>> specify header args at a finer granularity than just file variables
>> would have a say.
>>
>> As a clarification: I'm not changing property syntax at all, I'm adding
>> new properties that happen to have values that look like the header
>> arguments to a source block.  I've also implemented default
>> (non-language-specific) header arguments just now.  Unless you use the
>> new property names none of the current behaviour changes (I do think the
>> old properties should be removed some time later when people had time to
>> convert their documents), but using the new property names will take
>> precedence.  This means if you specify 'cache "yes"' and also
>> 'header-args :cache "no"' via properties, then the latter will take
>> effect.
>>
>> Documentation and tests are still missing, but it shouldn't take too
>> long I hope.
>>
>
> I just applied your patches.  Besides a quick test that went very well,
> I can not say much.  The functionality is exactly what would help me a
> lot to separate session information for R and shell blocks.  But given
> the example in the code, this is known to you.
>
> I would love to see that functionality in org and did not experience any
> problems after applying the patches.

OK - I will change my syntax to the new property syntax and report back,
likely not before middle of the week.

Thanks,

Rainer

>
> Regards,
> Andreas
>
>
>
<#secure method=pgpmime mode=sign>

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

Re: :session question -- and changes to #+Property: syntax

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]


Achim Gratz <Stromeko@nexgo.de> 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 change.  I can push that second part as well, but I'll need
> another week or so for properly documenting it in the manual and setting
> up a test.  Unless someone urgently wants to do something with it, I'd
> rather push these things together.

As mentioned, I would then change my optional syntax of PROPERTY
tomorrow. If you prefer earlier feedback, I could give it.

Cheers,

Rainer


>
>
> Regards,
> Achim.


-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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
manual), so I've just pushed the actual code change to master.  There's
minimal documentation in the commit message.

Any old-style properties (cache, session…) should still work, so please
test this first before doing the changes to your documents.  If you
simply add new-style default properties (not specific to any language),
simply use property "header-args".  This should _override_ any still
existing old-style properties for the same header argument (please test
this as well).  Finally, the non-language-specific properties will be
ignored if a language-specific property for the same header argument
exists.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 the definition and then executes the source block
there (this may be in another file even).

2. The evaluation of header arguments assumes emacs-lisp as a language.


These two combined make it somewhat difficult to use properties to
control the behaviour of LOB calls and understand what is happening and
why.  A workaround is to beam the source to the place of call via noweb
syntax.  The first point could perhaps be addressed in a cleaner way by
using org-babel-current-src-block-location when calling org-entry-get,
but I'm not sure yet if it is always correctly set.  Another thorny
question is how to deal with another layer of calls that might evaluate
properties again.  A last option would be to introduce another header
argument that can be used to inject the properties into the argument
list of the call and, if set, would suppress any property evaluation in
downstream calls.

For the second, I think that "lob" should be treated as a language for
the purpose of anything *-default-header-args* so these settings can be
independently controlled.


Thoughts, comments?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: :session question -- and changes to #+Property: syntax

[Michael Brand]

Hi Achim

On Tue, Jun 18, 2013 at 10:41 PM, Achim Gratz <Stromeko@nexgo.de> 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 of the call.  This is simply how org-babel-process-params
> works, it jumps to the definition and then executes the source block
> there (this may be in another file even).
>
> 2. The evaluation of header arguments assumes emacs-lisp as a language.

I guess you do not mean the language of the source block, else see
below for an example with shell.

>
>
> These two combined make it somewhat difficult to use properties to
> control the behaviour of LOB calls and understand what is happening and
> why.  A workaround is to beam the source to the place of call via noweb
> syntax.  The first point could perhaps be addressed in a cleaner way by
> using org-babel-current-src-block-location when calling org-entry-get,
> but I'm not sure yet if it is always correctly set.

My intention is to ensure this with an ERT, see my patch here:
http://lists.gnu.org/archive/html/emacs-orgmode/2013-06/msg00738.html

> [...]

Michael

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Achim Gratz <Stromeko@nexgo.de> 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.  The attached org-mode file demonstrates.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: header-eval-location.org --]
[-- Type: text/x-org, Size: 363 bytes --]

* first
  :PROPERTIES:
  :CUSTOM_ID: first
  :END:

#+name: heading-id
#+begin_src emacs-lisp :var point=(point)
  (format "%s at %d" (org-entry-get point "CUSTOM_ID") point)
#+end_src

#+RESULTS: heading-id
: first at 53

* second
  :PROPERTIES:
  :CUSTOM_ID: second
  :END:

#+call: heading-id(point=(point))

#+RESULTS: heading-id(point=(point))
: first at 53

[-- Attachment #3: Type: text/plain, Size: 2232 bytes --]


> This is simply how org-babel-process-params works, it jumps to the
> definition and then executes the source block there (this may be in
> another file even).
>
> 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.

>
> These two combined make it somewhat difficult to use properties to
> control the behaviour of LOB calls and understand what is happening and
> why.  A workaround is to beam the source to the place of call via noweb
> syntax.

This seem a little Rube Goldberg'ish to me.

> The first point could perhaps be addressed in a cleaner way by using
> org-babel-current-src-block-location when calling org-entry-get, but
> I'm not sure yet if it is always correctly set.

I think the best way to handle the first issue would be to use the
recently introduced `org-babel-current-src-block-location' variable, and
jump back to that location when evaluation header arguments.

> Another thorny question is how to deal with another layer of calls
> that might evaluate properties again.

If this is something we need to support, then we would want to turn the
`org-babel-current-src-block-location' variable into a list onto which
we push and pop locations.  Presumably it would then be possible to
evaluate each header argument at the correct location.

> A last option would be to introduce another header argument that can
> be used to inject the properties into the argument list of the call
> and, if set, would suppress any property evaluation in downstream
> calls.
>

I'm not sure I fully understand this solution.

>
> For the second, I think that "lob" should be treated as a language for
> the purpose of anything *-default-header-args* so these settings can be
> independently controlled.
>

I don't know what this means.  I'm either mis-understanding your second
issue, or I strongly disagree with it.  I do not think it should be
possible to embed arbitrary language source code into header arguments.

Cheers,

>
>
> Thoughts, comments?
>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 second, I think that "lob" should be treated as a language for
>> the purpose of anything *-default-header-args* so these settings can be
>> independently controlled.
>
> I don't know what this means.  I'm either mis-understanding your second
> issue, or I strongly disagree with it.  I do not think it should be
> possible to embed arbitrary language source code into header arguments.

I'm talking about the ephemeral source block that org-babel-lob-execute
constructs.  This is an emacs-lisp block and I see indeed no use of
using a different language there, but I don't think it should
necessarily use the default header arguments for all other emacs-lisp
blocks.  If these header arguments must be changeable, rather than
simply fixed, my suggestion is to use org-babel-default-header-args:lob
for that (and the moral equivalent for properties) so that setting some
strange default haeder args for elisp blocks doesn't inadvertently take
out LOB calls.


>> These two combined make it somewhat difficult to use properties to
>> control the behaviour of LOB calls and understand what is happening and
>> why.  A workaround is to beam the source to the place of call via noweb
>> syntax.
>
> This seem a little Rube Goldberg'ish to me.

That's actually a somewhat natural looking construct in Babel; certainly
not the most elegant, but it gets the job done.

> I think the best way to handle the first issue would be to use the
> recently introduced `org-babel-current-src-block-location' variable, and
> jump back to that location when evaluation header arguments.

I still have to convince myself that this works for this purpose, but
yes, that'd be the most obvious solution if the properties should only
be evaluated from the site of call.  If anything, the resulting
behaviour for nested Babel calls is more difficult to explain than what
we have now however.

>> Another thorny question is how to deal with another layer of calls
>> that might evaluate properties again.
>
> If this is something we need to support, then we would want to turn the
> `org-babel-current-src-block-location' variable into a list onto which
> we push and pop locations.  Presumably it would then be possible to
> evaluate each header argument at the correct location.

That may not be as easy as you make it sound in the above sentence.
Anyway, if we had such a (hypothetical) facility, I'm not sure if the
additional control over the execution produces a net benefit over the
increased complexity.

>> A last option would be to introduce another header argument that can
>> be used to inject the properties into the argument list of the call
>> and, if set, would suppress any property evaluation in downstream
>> calls.
>
> I'm not sure I fully understand this solution.

Since it is another hypothetical solution, I'm not sure yet either.  The
idea is to record only the original call site in
org-babel-current-src-block-location and hand (probably a list of)
additional call sites or properties evaluated at those sites over to the
source block as a header argument.  This would have the benefit that the
called function might be able to decide what to do with those, in
particular overwrite or delete it.  This allows yet more control, but
see above.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

Achim Gratz <Stromeko@nexgo.de> 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 argument.
> […]
>>> For the second, I think that "lob" should be treated as a language for
>>> the purpose of anything *-default-header-args* so these settings can be
>>> independently controlled.
>>
>> I don't know what this means.  I'm either mis-understanding your second
>> issue, or I strongly disagree with it.  I do not think it should be
>> possible to embed arbitrary language source code into header arguments.
>
> I'm talking about the ephemeral source block that org-babel-lob-execute
> constructs.  This is an emacs-lisp block and I see indeed no use of
> using a different language there, but I don't think it should
> necessarily use the default header arguments for all other emacs-lisp
> blocks.  If these header arguments must be changeable, rather than
> simply fixed, my suggestion is to use org-babel-default-header-args:lob
> for that (and the moral equivalent for properties) so that setting some
> strange default haeder args for elisp blocks doesn't inadvertently take
> out LOB calls.
>

Oh, I understand now.  I would also be happy with using *no* header
arguments for this ephemeral elisp block if that is easily accomplished.

>
>
>>> These two combined make it somewhat difficult to use properties to
>>> control the behaviour of LOB calls and understand what is happening and
>>> why.  A workaround is to beam the source to the place of call via noweb
>>> syntax.
>>
>> This seem a little Rube Goldberg'ish to me.
>
> That's actually a somewhat natural looking construct in Babel; certainly
> not the most elegant, but it gets the job done.
>
>> I think the best way to handle the first issue would be to use the
>> recently introduced `org-babel-current-src-block-location' variable, and
>> jump back to that location when evaluation header arguments.
>
> I still have to convince myself that this works for this purpose, but
> yes, that'd be the most obvious solution if the properties should only
> be evaluated from the site of call.  If anything, the resulting
> behaviour for nested Babel calls is more difficult to explain than what
> we have now however.
>

I agree.  This sounds like it would probably be overkill.

>
>>> Another thorny question is how to deal with another layer of calls
>>> that might evaluate properties again.
>>
>> If this is something we need to support, then we would want to turn the
>> `org-babel-current-src-block-location' variable into a list onto which
>> we push and pop locations.  Presumably it would then be possible to
>> evaluate each header argument at the correct location.
>
> That may not be as easy as you make it sound in the above sentence.
> Anyway, if we had such a (hypothetical) facility, I'm not sure if the
> additional control over the execution produces a net benefit over the
> increased complexity.
>

Agreed.

>
>>> A last option would be to introduce another header argument that can
>>> be used to inject the properties into the argument list of the call
>>> and, if set, would suppress any property evaluation in downstream
>>> calls.
>>
>> I'm not sure I fully understand this solution.
>
> Since it is another hypothetical solution, I'm not sure yet either.  The
> idea is to record only the original call site in
> org-babel-current-src-block-location and hand (probably a list of)
> additional call sites or properties evaluated at those sites over to the
> source block as a header argument.  This would have the benefit that the
> called function might be able to decide what to do with those, in
> particular overwrite or delete it.  This allows yet more control, but
> see above.
>

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...).

Cheers,

>
>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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-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 if that new behaviour
replaces the old one or yet another header argument or option switches
between old and new.  I guess it could be arranged so that the old-style
properties kept the old behaviour and the new-style properties followed
the new…


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

>> 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 if that new behaviour
> replaces the old one or yet another header argument or option switches
> between old and new.  I guess it could be arranged so that the old-style
> properties kept the old behaviour and the new-style properties followed
> the new…
>

Introducing another header argument controlling this setting would add
too much complexity.  I think we either stick with the existing behavior
or (preferably) change the default behavior.

Thanks for taking these on!

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 from
the header arguments is used in two places and there's another
not-quite-exact copy of this in ob-exp that would need attention at the
same time.

>> 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 if that new behaviour
> replaces the old one or yet another header argument or option switches
> between old and new.  I guess it could be arranged so that the old-style
> properties kept the old behaviour and the new-style properties followed
> the new…

I've pushed this to master, with documentation and testing.  Old style
property-based header arguments keep the old behaviour of looking up the
properties at the point of source block definition for backwards
compatibility and are now deprecated.  The new header-args[:lang]
properties use the location of the call as recorded in
`org-babel-current-src-block-location'.



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: :session question -- and changes to #+Property: syntax

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

>>> 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 if that new behaviour
>> replaces the old one or yet another header argument or option switches
>> between old and new.  I guess it could be arranged so that the old-style
>> properties kept the old behaviour and the new-style properties followed
>> the new…
>
> I've pushed this to master, with documentation and testing.  Old style
> property-based header arguments keep the old behaviour of looking up the
> properties at the point of source block definition for backwards
> compatibility and are now deprecated.  The new header-args[:lang]
> properties use the location of the call as recorded in
> `org-babel-current-src-block-location'.
>

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.

You implemented location-specific look up of header argument properties,
I just pushed up location-specific evaluation of elisp embedded in
header arguments as shown in the attached example file.

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: header-eval-location.org --]
[-- Type: text/x-org, Size: 867 bytes --]

* First
  :PROPERTIES:
  :CUSTOM_ID: one
  :END:

#+name: heading-id
#+begin_src emacs-lisp :var point=(point) :var loc=(format "%S" org-babel-current-src-block-location)
  (format "property %S at %d really %s" (org-entry-get point "CUSTOM_ID") point loc)
#+end_src

#+RESULTS: heading-id
: property "one" at 70 really 70

* Second
  :PROPERTIES:
  :CUSTOM_ID: two
  :END:

Call with all header arguments at the point of execution

#+call: heading-id(point=(point))

#+RESULTS: heading-id(point=(point))
: property "two" at 433 really #<marker at 433 in header-eval-location.org>

#+call: heading-id()

#+RESULTS: heading-id()
: property "two" at 582 really #<marker at 582 in header-eval-location.org>

Another call from a code block rather than a call line.

#+begin_src emacs-lisp :var in=heading-id()
  in
#+end_src

#+RESULTS:
: property "two" at 762 really 762

[-- Attachment #3: Type: text/plain, Size: 46 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte

Re: :session question -- and changes to #+Property: syntax

[Achim Gratz]

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 properties,
> I just pushed up location-specific evaluation of elisp embedded in
> header arguments as shown in the attached example file.

Great, thank you.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada