* [BABEL] "unset" :var definitions for subtree
@ 2011-02-07 15:12 Rainer M Krug
2011-02-10 1:27 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-07 15:12 UTC (permalink / raw)
To: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
For one project, I am usinr org to write submit scripte to a cluster
runing torqu. The important bit in this is, that between the shebang and
the code, no other executable line must occur. As I am using variables
in org (:var) they will occur just after the shebang, which causes a
problem for torque. So, my question is, is there a way to "unset"
variables defined by using :var for a subtree?
#+BABEL: :session *R* :results output :exports both :tangle
Analysis_sensitivity.R :var RESULTSDIR="/media/Results/" :var
ANALYSISDIR="~/Documents/Projects/analysis/"
* submit script (SA.sub)
:PROPERTIES:
:tangle: ./SA.sub
:exports: code
:END:
#+begin_src sh
#PBS -j y
#PBS -M Rainer@krugs.de
#PBS -V
#PBS -l nodes=1:mem=4gb
##
cd $PBS_O_WORKDIR
#+end_src
I would need the tangled code to be :
#!/bin/bash
#PBS -j y
#PBS -M Rainer@krugs.de
#PBS -V
#PBS -l nodes=1:mem=4gb
##
cd $PBS_O_WORKDIR
But it is
#!/bin/bash
RESULTSDIR=/media/Results/
ANALYSISDIR=~/Documents/Projects/analysis/
#PBS -j y
#PBS -M Rainer@krugs.de
#PBS -V
#PBS -l nodes=1:mem=4gb
##
cd $PBS_O_WORKDIR
But RESULTSDIR and ANALYSISDIR is used in the remainder of the document
(several other subtrees)
Any help appreciated,
Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1QC+wACgkQoYgNqgF2egramwCeKbj6CbfK0ZBF03ZkfJBTbhc5
9pQAniXZum0sK3GX4ZxEzIAGRPu3fMxM
=zO07
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-07 15:12 [BABEL] "unset" :var definitions for subtree Rainer M Krug
@ 2011-02-10 1:27 ` Eric Schulte
2011-02-10 8:33 ` Rainer M Krug
0 siblings, 1 reply; 26+ messages in thread
From: Eric Schulte @ 2011-02-10 1:27 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
Rainer M Krug <r.m.krug@gmail.com> writes:
> Hi
>
> For one project, I am usinr org to write submit scripte to a cluster
> runing torqu. The important bit in this is, that between the shebang and
> the code, no other executable line must occur. As I am using variables
> in org (:var) they will occur just after the shebang, which causes a
> problem for torque. So, my question is, is there a way to "unset"
> variables defined by using :var for a subtree?
>
Hi Rainer,
Interesting question... unfortunately I don't think that removing
variables from header arguments is possible under the current setup.
Perhaps in your case you could add a function to the post-tangle hook,
which recognizes when it is being called in a just-tangled torqu script
(maybe by searching for a series of #PBS lines), and then removes any
lines between the shebang and the first #PBS line?
More generally, I wonder what a natural method would be to allow
unsetting of pre-set header arguments for local blocks or subtrees?
This may only apply to the :var header argument, as most others have a
default setting which can be actively set. If you have any ideas for a
natural syntax for such an operation I'd be happy to hear it.
Cheers -- Eric
>
> #+BABEL: :session *R* :results output :exports both :tangle
> Analysis_sensitivity.R :var RESULTSDIR="/media/Results/" :var
> ANALYSISDIR="~/Documents/Projects/analysis/"
>
>
> * submit script (SA.sub)
> :PROPERTIES:
> :tangle: ./SA.sub
> :exports: code
> :END:
> #+begin_src sh
> #PBS -j y
> #PBS -M Rainer@krugs.de
> #PBS -V
> #PBS -l nodes=1:mem=4gb
> ##
> cd $PBS_O_WORKDIR
> #+end_src
>
> I would need the tangled code to be :
>
> #!/bin/bash
> #PBS -j y
> #PBS -M Rainer@krugs.de
> #PBS -V
> #PBS -l nodes=1:mem=4gb
> ##
> cd $PBS_O_WORKDIR
>
> But it is
>
> #!/bin/bash
> RESULTSDIR=/media/Results/
> ANALYSISDIR=~/Documents/Projects/analysis/
> #PBS -j y
> #PBS -M Rainer@krugs.de
> #PBS -V
> #PBS -l nodes=1:mem=4gb
> ##
> cd $PBS_O_WORKDIR
>
>
> But RESULTSDIR and ANALYSISDIR is used in the remainder of the document
> (several other subtrees)
>
> Any help appreciated,
>
> Rainer
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-10 1:27 ` Eric Schulte
@ 2011-02-10 8:33 ` Rainer M Krug
2011-02-10 16:48 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-10 8:33 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/10/2011 02:27 AM, Eric Schulte wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Hi
>>
>> For one project, I am usinr org to write submit scripte to a cluster
>> runing torqu. The important bit in this is, that between the shebang and
>> the code, no other executable line must occur. As I am using variables
>> in org (:var) they will occur just after the shebang, which causes a
>> problem for torque. So, my question is, is there a way to "unset"
>> variables defined by using :var for a subtree?
>>
>
> Hi Rainer,
>
> Interesting question... unfortunately I don't think that removing
> variables from header arguments is possible under the current setup.
>
> Perhaps in your case you could add a function to the post-tangle hook,
> which recognizes when it is being called in a just-tangled torqu script
> (maybe by searching for a series of #PBS lines), and then removes any
> lines between the shebang and the first #PBS line?
That is also an option - what I am using at the moment is to use
:no-expand as a code block specific header argument. But this raises the
other question:
Can I set the :no-expand in a properties block? As far as I understand,
in the properties block I have the argument and the value - but what do
I do with :noexpand?
:PROPERTIES:
:var: A=13
:no-expand
:END:
>
> More generally, I wonder what a natural method would be to allow
> unsetting of pre-set header arguments for local blocks or subtrees?
> This may only apply to the :var header argument, as most others have a
> default setting which can be actively set. If you have any ideas for a
> natural syntax for such an operation I'd be happy to hear it.
First solution (probably the easiest to implement) would be along the
lines of the :no-expand header argument -
:expand-var yes
and
:expand-var no
This could possibly be expanded to
:expand-var A B C
which would expand only the variables A B and C
One step further: one could define groups of variables, like
:var-group X=A,B,C
or a similar syntax
and then
:expand-var X
would expand A B and C
This all would not be real unset - but a possibility for unsetting would be
:var B=
or
:var-unset B
i.e. if no value is specified in :var, the variable will be removed
(i.e. unset) - one could also use a null value (if it exists in elisp):
:var B=(null)
But this raises another question of mine:
I tried to use two :var headers in a properties block, but it only used
the first - did I miss something here?
Cheers,
Rainer
>
> Cheers -- Eric
>
>>
>> #+BABEL: :session *R* :results output :exports both :tangle
>> Analysis_sensitivity.R :var RESULTSDIR="/media/Results/" :var
>> ANALYSISDIR="~/Documents/Projects/analysis/"
>>
>>
>> * submit script (SA.sub)
>> :PROPERTIES:
>> :tangle: ./SA.sub
>> :exports: code
>> :END:
>> #+begin_src sh
>> #PBS -j y
>> #PBS -M Rainer@krugs.de
>> #PBS -V
>> #PBS -l nodes=1:mem=4gb
>> ##
>> cd $PBS_O_WORKDIR
>> #+end_src
>>
>> I would need the tangled code to be :
>>
>> #!/bin/bash
>> #PBS -j y
>> #PBS -M Rainer@krugs.de
>> #PBS -V
>> #PBS -l nodes=1:mem=4gb
>> ##
>> cd $PBS_O_WORKDIR
>>
>> But it is
>>
>> #!/bin/bash
>> RESULTSDIR=/media/Results/
>> ANALYSISDIR=~/Documents/Projects/analysis/
>> #PBS -j y
>> #PBS -M Rainer@krugs.de
>> #PBS -V
>> #PBS -l nodes=1:mem=4gb
>> ##
>> cd $PBS_O_WORKDIR
>>
>>
>> But RESULTSDIR and ANALYSISDIR is used in the remainder of the document
>> (several other subtrees)
>>
>> Any help appreciated,
>>
>> Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1TotIACgkQoYgNqgF2egr+6wCfXk2HxVpLA6pfAExRJDsWi/j/
5YwAn1bINit/4aB5wFwWV3J3v7piIXhL
=ctxl
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-10 8:33 ` Rainer M Krug
@ 2011-02-10 16:48 ` Eric Schulte
2011-02-11 9:00 ` Rainer M Krug
2011-02-11 12:19 ` Dan Davison
0 siblings, 2 replies; 26+ messages in thread
From: Eric Schulte @ 2011-02-10 16:48 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
Rainer M Krug <r.m.krug@gmail.com> writes:
> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> Hi
>>>
>>> For one project, I am usinr org to write submit scripte to a cluster
>>> runing torqu. The important bit in this is, that between the shebang and
>>> the code, no other executable line must occur. As I am using variables
>>> in org (:var) they will occur just after the shebang, which causes a
>>> problem for torque. So, my question is, is there a way to "unset"
>>> variables defined by using :var for a subtree?
>>>
>>
>> Hi Rainer,
>>
>> Interesting question... unfortunately I don't think that removing
>> variables from header arguments is possible under the current setup.
>>
>> Perhaps in your case you could add a function to the post-tangle hook,
>> which recognizes when it is being called in a just-tangled torqu script
>> (maybe by searching for a series of #PBS lines), and then removes any
>> lines between the shebang and the first #PBS line?
>
> That is also an option - what I am using at the moment is to use
> :no-expand as a code block specific header argument. But this raises the
> other question:
>
> Can I set the :no-expand in a properties block? As far as I understand,
> in the properties block I have the argument and the value - but what do
> I do with :noexpand?
>
> :PROPERTIES:
> :var: A=13
> :no-expand
> :END:
>
You can just set it to "yes" or really any value you like (the value
will be ignored). I did however have to add "no-expand" to the list of
header argument names searched for in property blocks -- I just pushed
up a patch to this effect.
>
>>
>> More generally, I wonder what a natural method would be to allow
>> unsetting of pre-set header arguments for local blocks or subtrees?
>> This may only apply to the :var header argument, as most others have a
>> default setting which can be actively set. If you have any ideas for a
>> natural syntax for such an operation I'd be happy to hear it.
>
> First solution (probably the easiest to implement) would be along the
> lines of the :no-expand header argument -
>
> :expand-var yes
> and
> :expand-var no
>
> This could possibly be expanded to
> :expand-var A B C
>
> which would expand only the variables A B and C
>
> One step further: one could define groups of variables, like
> :var-group X=A,B,C
> or a similar syntax
>
> and then
> :expand-var X
> would expand A B and C
>
> This all would not be real unset - but a possibility for unsetting would be
>
> :var B=
>
> or
>
> :var-unset B
>
> i.e. if no value is specified in :var, the variable will be removed
> (i.e. unset) - one could also use a null value (if it exists in elisp):
>
> :var B=(null)
>
Thanks for the ideas,
I think you're right that something along the lines of the above should
be the easiest to implement, however after reading these suggestions,
I'm thinking that more generally there are a couple of other header
arguments which could need to be unset, namely
- file
- dir
- session
- shebang
some of these (like session) accept a "none" value which has the effect
of un-setting the header argument.
It would be nice to generalize whatever solution we apply across all
types of header argument (both for implementation and for user
simplicity). The simplest option would probably be to ensure that
setting any header argument to :none would remove all instances of that
header argument. The only problem there is cases like var, where you
might not want to remove all :var's. Maybe this could be expanded
s.t. :none could take arguments, e.g.
:header :none(A, B)
which would remove all instances of the "header" header argument whose
value is or is named "A" or "B"? Or does that look too funky?
>
> But this raises another question of mine:
>
> I tried to use two :var headers in a properties block, but it only used
> the first - did I miss something here?
>
Nope, it appears that property blocks (like a hash) assume that there is
only one instance of each key->value pair, so once it is satisfied it
will quit looking for more instances. Maybe the following alternative
will suffice
Best -- Eric
** two vars in a properties block -- not possible
:PROPERTIES:
:var: test1=7
:var: test2=8
:END:
#+begin_src emacs-lisp
(message "test1=%S test2=%S" test1 test2)
#+end_src
results in Error
: let: Symbol's value as variable is void: test2
*** an alternative
:PROPERTIES:
:var: tests=all-tests
:END:
#+tblname: all-tests
- 7
- 8
#+begin_src emacs-lisp :var eric=89
(message "test1=%S test2=%S" (first tests) (second tests))
#+end_src
#+results:
: test1=7 test2=8
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-10 16:48 ` Eric Schulte
@ 2011-02-11 9:00 ` Rainer M Krug
2011-02-11 9:32 ` Dan Davison
2011-02-11 12:19 ` Dan Davison
1 sibling, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 9:00 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/10/2011 05:48 PM, Eric Schulte wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> Hi
>>>>
>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>> runing torqu. The important bit in this is, that between the shebang and
>>>> the code, no other executable line must occur. As I am using variables
>>>> in org (:var) they will occur just after the shebang, which causes a
>>>> problem for torque. So, my question is, is there a way to "unset"
>>>> variables defined by using :var for a subtree?
>>>>
>>>
>>> Hi Rainer,
>>>
>>> Interesting question... unfortunately I don't think that removing
>>> variables from header arguments is possible under the current setup.
>>>
>>> Perhaps in your case you could add a function to the post-tangle hook,
>>> which recognizes when it is being called in a just-tangled torqu script
>>> (maybe by searching for a series of #PBS lines), and then removes any
>>> lines between the shebang and the first #PBS line?
>>
>> That is also an option - what I am using at the moment is to use
>> :no-expand as a code block specific header argument. But this raises the
>> other question:
>>
>> Can I set the :no-expand in a properties block? As far as I understand,
>> in the properties block I have the argument and the value - but what do
>> I do with :noexpand?
>>
>> :PROPERTIES:
>> :var: A=13
>> :no-expand
>> :END:
>>
>
> You can just set it to "yes" or really any value you like (the value
> will be ignored). I did however have to add "no-expand" to the list of
> header argument names searched for in property blocks -- I just pushed
> up a patch to this effect.
Thanks - I'll try it today and come back if it does not work.
>
>>
>>>
>>> More generally, I wonder what a natural method would be to allow
>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>> This may only apply to the :var header argument, as most others have a
>>> default setting which can be actively set. If you have any ideas for a
>>> natural syntax for such an operation I'd be happy to hear it.
>>
>> First solution (probably the easiest to implement) would be along the
>> lines of the :no-expand header argument -
>>
>> :expand-var yes
>> and
>> :expand-var no
>>
>> This could possibly be expanded to
>> :expand-var A B C
>>
>> which would expand only the variables A B and C
>>
>> One step further: one could define groups of variables, like
>> :var-group X=A,B,C
>> or a similar syntax
>>
>> and then
>> :expand-var X
>> would expand A B and C
>>
>> This all would not be real unset - but a possibility for unsetting would be
>>
>> :var B=
>>
>> or
>>
>> :var-unset B
>>
>> i.e. if no value is specified in :var, the variable will be removed
>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>
>> :var B=(null)
>>
>
> Thanks for the ideas,
>
> I think you're right that something along the lines of the above should
> be the easiest to implement, however after reading these suggestions,
> I'm thinking that more generally there are a couple of other header
> arguments which could need to be unset, namely
> - file
> - dir
> - session
> - shebang
> some of these (like session) accept a "none" value which has the effect
> of un-setting the header argument.
True - haven't thought about those (and did not know about :dir useful
one!). And the :session might definitely come in handy - I have cases,
where I reset it manually before evaluating certain sections of the block.
>
> It would be nice to generalize whatever solution we apply across all
> types of header argument (both for implementation and for user
> simplicity).
Absolutely - coherent solutions are definitely the best.
> The simplest option would probably be to ensure that
> setting any header argument to :none would remove all instances of that
> header argument.
Agreed - makes perfect sense. But probably for readibility use something
like:
: header :remove()
or
:header :remove
> The only problem there is cases like var, where you
> might not want to remove all :var's. Maybe this could be expanded
> s.t. :none could take arguments, e.g.
>
> :header :none(A, B)
>
> which would remove all instances of the "header" header argument whose
> value is or is named "A" or "B"?
I would stick to the name of the variable - that is more consistent.
But instead of :none() I would suggest :remove :
:header :remove(A, B)
and if one wants to remove all variables with *value "A"*, one could use
:header :remove("A")
Or does that look too funky?
No - I like it.
For consistency, one could also have a function :set() which could be
used as follow:
:header :set(A=12, B=13)
to set the "header" header argument A to 12 and B to 13.
And then probably use :unset instead of :remove?
Just thinking along while I am typing...
>
>>
>> But this raises another question of mine:
>>
>> I tried to use two :var headers in a properties block, but it only used
>> the first - did I miss something here?
>>
>
> Nope, it appears that property blocks (like a hash) assume that there is
> only one instance of each key->value pair, so once it is satisfied it
> will quit looking for more instances.
But not always - there are exceptions, e.g. #+LATEX_HEADER: of which I
can specify more then one.
I am asking, because I have a horribly long line of #+BABEL: :var ....
and would really like to split it in two.
> Maybe the following alternative
> will suffice
>
> Best -- Eric
>
> ** two vars in a properties block -- not possible
> :PROPERTIES:
> :var: test1=7
> :var: test2=8
> :END:
>
> #+begin_src emacs-lisp
> (message "test1=%S test2=%S" test1 test2)
> #+end_src
>
> results in Error
> : let: Symbol's value as variable is void: test2
>
> *** an alternative
> :PROPERTIES:
> :var: tests=all-tests
> :END:
>
> #+tblname: all-tests
> - 7
> - 8
>
> #+begin_src emacs-lisp :var eric=89
> (message "test1=%S test2=%S" (first tests) (second tests))
> #+end_src
>
> #+results:
> : test1=7 test2=8
That's sneaky - I like that solution. But I would have to rename my
variables in my code blocks - but I must say I like it. I'll probably
use this - it keeps the variables nicely together.
Just an idea:
:var: :in_table(all-variables)
#+tblname: all-tests
- - 7
- - 8
#+tblname: all-variables
| A | 20 |
| B | "next value" |
| C | 13 |
| test | all-tests |
which would create the variables A with value 20, B with value "next
value" and C with value 13, and the variable tests would be based on the
table all-tests (i.e. test1 = 7, test2 = 8).
That would be *really* neat and useful to use. as one would have a
nicely formatted table of all variables and their values.
One could even go one step further and say that when no value is
specified in the second column, the variable is removed and if the
variable already exists it is overwritten.
In this case, the limitation of one line :var only would not be a
problem any more.
While we are at variables, it could be useful to rename or copy
variables as well:
rename A to B:
:var :rename(A, B)
or copy A to B
:var :copy(A, B)
But probably not that useful.
Cheers and thanks,
Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1U+qAACgkQoYgNqgF2egoO/gCfTEziASCsBe8wRnHe2dT6bAFS
pPQAn1Stn4zPgUsdyksqBJ2j1WHDUCDD
=IBgl
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 9:00 ` Rainer M Krug
@ 2011-02-11 9:32 ` Dan Davison
2011-02-11 10:22 ` Rainer M Krug
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-11 9:32 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
Rainer M Krug <r.m.krug@gmail.com> writes:
> On 02/10/2011 05:48 PM, Eric Schulte wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>
>>>>> Hi
>>>>>
>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>> the code, no other executable line must occur. As I am using variables
>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>> variables defined by using :var for a subtree?
>>>>>
>>>>
>>>> Hi Rainer,
>>>>
>>>> Interesting question... unfortunately I don't think that removing
>>>> variables from header arguments is possible under the current setup.
>>>>
>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>> which recognizes when it is being called in a just-tangled torqu script
>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>> lines between the shebang and the first #PBS line?
>>>
>>> That is also an option - what I am using at the moment is to use
>>> :no-expand as a code block specific header argument. But this raises the
>>> other question:
>>>
>>> Can I set the :no-expand in a properties block? As far as I understand,
>>> in the properties block I have the argument and the value - but what do
>>> I do with :noexpand?
>>>
>>> :PROPERTIES:
>>> :var: A=13
>>> :no-expand
>>> :END:
>>>
>>
>> You can just set it to "yes" or really any value you like (the value
>> will be ignored). I did however have to add "no-expand" to the list of
>> header argument names searched for in property blocks -- I just pushed
>> up a patch to this effect.
>
> Thanks - I'll try it today and come back if it does not work.
>
>>
>>>
>>>>
>>>> More generally, I wonder what a natural method would be to allow
>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>> This may only apply to the :var header argument, as most others have a
>>>> default setting which can be actively set. If you have any ideas for a
>>>> natural syntax for such an operation I'd be happy to hear it.
>>>
>>> First solution (probably the easiest to implement) would be along the
>>> lines of the :no-expand header argument -
>>>
>>> :expand-var yes
>>> and
>>> :expand-var no
>>>
>>> This could possibly be expanded to
>>> :expand-var A B C
>>>
>>> which would expand only the variables A B and C
>>>
>>> One step further: one could define groups of variables, like
>>> :var-group X=A,B,C
>>> or a similar syntax
>>>
>>> and then
>>> :expand-var X
>>> would expand A B and C
>>>
>>> This all would not be real unset - but a possibility for unsetting would be
>>>
>>> :var B=
>>>
>>> or
>>>
>>> :var-unset B
>>>
>>> i.e. if no value is specified in :var, the variable will be removed
>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>
>>> :var B=(null)
>>>
>>
>> Thanks for the ideas,
>>
>> I think you're right that something along the lines of the above should
>> be the easiest to implement, however after reading these suggestions,
>> I'm thinking that more generally there are a couple of other header
>> arguments which could need to be unset, namely
>> - file
>> - dir
>> - session
>> - shebang
>> some of these (like session) accept a "none" value which has the effect
>> of un-setting the header argument.
>
> True - haven't thought about those (and did not know about :dir useful
> one!). And the :session might definitely come in handy - I have cases,
> where I reset it manually before evaluating certain sections of the block.
>
>>
>> It would be nice to generalize whatever solution we apply across all
>> types of header argument (both for implementation and for user
>> simplicity).
>
> Absolutely - coherent solutions are definitely the best.
>
>> The simplest option would probably be to ensure that
>> setting any header argument to :none would remove all instances of that
>> header argument.
>
> Agreed - makes perfect sense. But probably for readibility use something
> like:
>
> : header :remove()
>
> or
>
> :header :remove
>
>> The only problem there is cases like var, where you
>> might not want to remove all :var's. Maybe this could be expanded
>> s.t. :none could take arguments, e.g.
>>
>> :header :none(A, B)
>>
>> which would remove all instances of the "header" header argument whose
>> value is or is named "A" or "B"?
>
> I would stick to the name of the variable - that is more consistent.
>
> But instead of :none() I would suggest :remove :
>
> :header :remove(A, B)
>
> and if one wants to remove all variables with *value "A"*, one could use
>
> :header :remove("A")
>
> Or does that look too funky?
>
> No - I like it.
I'm concerned that all this is looking rather complex. And I'm a bit
dubious about the :xxx syntax -- those should correspond to keys in an
association list. Could we step back a moment -- would someone mind
giving me a concrete example of a problem whose solution requires these
new features?
>
> For consistency, one could also have a function :set() which could be
> used as follow:
>
> :header :set(A=12, B=13)
>
> to set the "header" header argument A to 12 and B to 13.
>
> And then probably use :unset instead of :remove?
>
> Just thinking along while I am typing...
>
>
>>
>>>
>>> But this raises another question of mine:
>>>
>>> I tried to use two :var headers in a properties block, but it only used
>>> the first - did I miss something here?
>>>
>>
>> Nope, it appears that property blocks (like a hash) assume that there is
>> only one instance of each key->value pair, so once it is satisfied it
>> will quit looking for more instances.
>
> But not always - there are exceptions, e.g. #+LATEX_HEADER: of which I
> can specify more then one.
> I am asking, because I have a horribly long line of #+BABEL: :var ....
> and would really like to split it in two.
I believe that I fixed that at 05ef2ae7c (2011/01/20) -- i.e., you can
split it in two.
Dan
>
>> Maybe the following alternative
>> will suffice
>>
>> Best -- Eric
>>
>> ** two vars in a properties block -- not possible
>> :PROPERTIES:
>> :var: test1=7
>> :var: test2=8
>> :END:
>>
>> #+begin_src emacs-lisp
>> (message "test1=%S test2=%S" test1 test2)
>> #+end_src
>>
>> results in Error
>> : let: Symbol's value as variable is void: test2
>>
>> *** an alternative
>> :PROPERTIES:
>> :var: tests=all-tests
>> :END:
>>
>> #+tblname: all-tests
>> - 7
>> - 8
>>
>> #+begin_src emacs-lisp :var eric=89
>> (message "test1=%S test2=%S" (first tests) (second tests))
>> #+end_src
>>
>> #+results:
>> : test1=7 test2=8
>
> That's sneaky - I like that solution. But I would have to rename my
> variables in my code blocks - but I must say I like it. I'll probably
> use this - it keeps the variables nicely together.
>
> Just an idea:
>
> :var: :in_table(all-variables)
>
> #+tblname: all-tests
> - 7
> - 8
>
> #+tblname: all-variables
> | A | 20 |
> | B | "next value" |
> | C | 13 |
> | test | all-tests |
>
> which would create the variables A with value 20, B with value "next
> value" and C with value 13, and the variable tests would be based on the
> table all-tests (i.e. test1 = 7, test2 = 8).
>
> That would be *really* neat and useful to use. as one would have a
> nicely formatted table of all variables and their values.
>
> One could even go one step further and say that when no value is
> specified in the second column, the variable is removed and if the
> variable already exists it is overwritten.
>
> In this case, the limitation of one line :var only would not be a
> problem any more.
>
> While we are at variables, it could be useful to rename or copy
> variables as well:
>
> rename A to B:
>
> :var :rename(A, B)
>
> or copy A to B
>
> :var :copy(A, B)
>
> But probably not that useful.
>
> Cheers and thanks,
>
> Rainer
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 9:32 ` Dan Davison
@ 2011-02-11 10:22 ` Rainer M Krug
2011-02-11 11:55 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 10:22 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2011 10:32 AM, Dan Davison wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 02/10/2011 05:48 PM, Eric Schulte wrote:
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>>> the code, no other executable line must occur. As I am using variables
>>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>>> variables defined by using :var for a subtree?
>>>>>>
>>>>>
>>>>> Hi Rainer,
>>>>>
>>>>> Interesting question... unfortunately I don't think that removing
>>>>> variables from header arguments is possible under the current setup.
>>>>>
>>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>>> which recognizes when it is being called in a just-tangled torqu script
>>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>>> lines between the shebang and the first #PBS line?
>>>>
>>>> That is also an option - what I am using at the moment is to use
>>>> :no-expand as a code block specific header argument. But this raises the
>>>> other question:
>>>>
>>>> Can I set the :no-expand in a properties block? As far as I understand,
>>>> in the properties block I have the argument and the value - but what do
>>>> I do with :noexpand?
>>>>
>>>> :PROPERTIES:
>>>> :var: A=13
>>>> :no-expand
>>>> :END:
>>>>
>>>
>>> You can just set it to "yes" or really any value you like (the value
>>> will be ignored). I did however have to add "no-expand" to the list of
>>> header argument names searched for in property blocks -- I just pushed
>>> up a patch to this effect.
>>
>> Thanks - I'll try it today and come back if it does not work.
>>
>>>
>>>>
>>>>>
>>>>> More generally, I wonder what a natural method would be to allow
>>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>>> This may only apply to the :var header argument, as most others have a
>>>>> default setting which can be actively set. If you have any ideas for a
>>>>> natural syntax for such an operation I'd be happy to hear it.
>>>>
>>>> First solution (probably the easiest to implement) would be along the
>>>> lines of the :no-expand header argument -
>>>>
>>>> :expand-var yes
>>>> and
>>>> :expand-var no
>>>>
>>>> This could possibly be expanded to
>>>> :expand-var A B C
>>>>
>>>> which would expand only the variables A B and C
>>>>
>>>> One step further: one could define groups of variables, like
>>>> :var-group X=A,B,C
>>>> or a similar syntax
>>>>
>>>> and then
>>>> :expand-var X
>>>> would expand A B and C
>>>>
>>>> This all would not be real unset - but a possibility for unsetting would be
>>>>
>>>> :var B=
>>>>
>>>> or
>>>>
>>>> :var-unset B
>>>>
>>>> i.e. if no value is specified in :var, the variable will be removed
>>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>>
>>>> :var B=(null)
>>>>
>>>
>>> Thanks for the ideas,
>>>
>>> I think you're right that something along the lines of the above should
>>> be the easiest to implement, however after reading these suggestions,
>>> I'm thinking that more generally there are a couple of other header
>>> arguments which could need to be unset, namely
>>> - file
>>> - dir
>>> - session
>>> - shebang
>>> some of these (like session) accept a "none" value which has the effect
>>> of un-setting the header argument.
>>
>> True - haven't thought about those (and did not know about :dir useful
>> one!). And the :session might definitely come in handy - I have cases,
>> where I reset it manually before evaluating certain sections of the block.
>>
>>>
>>> It would be nice to generalize whatever solution we apply across all
>>> types of header argument (both for implementation and for user
>>> simplicity).
>>
>> Absolutely - coherent solutions are definitely the best.
>>
>>> The simplest option would probably be to ensure that
>>> setting any header argument to :none would remove all instances of that
>>> header argument.
>>
>> Agreed - makes perfect sense. But probably for readibility use something
>> like:
>>
>> : header :remove()
>>
>> or
>>
>> :header :remove
>>
>>> The only problem there is cases like var, where you
>>> might not want to remove all :var's. Maybe this could be expanded
>>> s.t. :none could take arguments, e.g.
>>>
>>> :header :none(A, B)
>>>
>>> which would remove all instances of the "header" header argument whose
>>> value is or is named "A" or "B"?
>>
>> I would stick to the name of the variable - that is more consistent.
>>
>> But instead of :none() I would suggest :remove :
>>
>> :header :remove(A, B)
>>
>> and if one wants to remove all variables with *value "A"*, one could use
>>
>> :header :remove("A")
>>
>> Or does that look too funky?
>>
>> No - I like it.
>
> I'm concerned that all this is looking rather complex. And I'm a bit
> dubious about the :xxx syntax -- those should correspond to keys in an
> association list. Could we step back a moment -- would someone mind
> giving me a concrete example of a problem whose solution requires these
> new features?
Here is my situation:
I am using org-babel to write analysis for a cluster environment, which
uses torque. To make my scripts flexible, I am using variables defined
in the beginning of the org document.
Everything works fine for after tangling in most of the scripts, but in
the submission script for the cluster (a nash scripd with definitions
for processing of the cluster job, following *directly/* after the
shebang, this causes problems, as the options are expected directly
after the shebang, and when variables are defined in the org file, these
will be included directly after the shebang. This results in torque not
finding the parameter it needs to successfully process the job.
So at the moment, I am using :no-expand to avoid this, but the general
idea rose of unsetting (removing) variables defined in :var on a subtree
level or code block level.
I agree - that whole issue sounds complex, but a more nuanced way of
handling :var defined variables in org, would make :var much easier to
use and more flexible (especially in babel, coming closer to really
being used as a meta programming language).
I do not suggest to include everything immediately, but two things could
be seen as a first step:
a way to unset (remove) variables, like discussed
:var :unset(A)
:var :unset(A, B)
:var :unset()
to unset / remove the variables A, A and B and all variables respectively.
For consistency,
:var :set(A, 13)
:var :set(B, "Hello world")
*could* be to included to set the variables.
In a further step, the :set() and :unset() could be used for the other
header arguments Eric mentioned.
I must admit, I am not clear what you men with "those should correspond
to keys in an association list" - I am definitely not a lisp / elisp
person and only a regular user of emacs / org mode / ESS.
Hope this clarifies my suggestion a bit,
Cheers,
Rainer
>
>>
>> For consistency, one could also have a function :set() which could be
>> used as follow:
>>
>> :header :set(A=12, B=13)
>>
>> to set the "header" header argument A to 12 and B to 13.
>>
>> And then probably use :unset instead of :remove?
>>
>> Just thinking along while I am typing...
>>
>>
>>>
>>>>
>>>> But this raises another question of mine:
>>>>
>>>> I tried to use two :var headers in a properties block, but it only used
>>>> the first - did I miss something here?
>>>>
>>>
>>> Nope, it appears that property blocks (like a hash) assume that there is
>>> only one instance of each key->value pair, so once it is satisfied it
>>> will quit looking for more instances.
>>
>> But not always - there are exceptions, e.g. #+LATEX_HEADER: of which I
>> can specify more then one.
>> I am asking, because I have a horribly long line of #+BABEL: :var ....
>> and would really like to split it in two.
>
> I believe that I fixed that at 05ef2ae7c (2011/01/20) -- i.e., you can
> split it in two.
Org-mode version 7.4 (release_7.4.338.gda8dc) (updated this morning)
Thanks - that makes life easier. When I use
#+BABEL: :var A=13
#+BABEL: :var B=14
Both are defined - but it still does not work in a properties block (as
in the Eris's example).
>
> Dan
>
>>
>>> Maybe the following alternative
>>> will suffice
>>>
>>> Best -- Eric
>>>
>>> ** two vars in a properties block -- not possible
>>> :PROPERTIES:
>>> :var: test1=7
>>> :var: test2=8
>>> :END:
>>>
>>> #+begin_src emacs-lisp
>>> (message "test1=%S test2=%S" test1 test2)
>>> #+end_src
>>>
>>> results in Error
>>> : let: Symbol's value as variable is void: test2
>>>
>>> *** an alternative
>>> :PROPERTIES:
>>> :var: tests=all-tests
>>> :END:
>>>
>>> #+tblname: all-tests
>>> - 7
>>> - 8
>>>
>>> #+begin_src emacs-lisp :var eric=89
>>> (message "test1=%S test2=%S" (first tests) (second tests))
>>> #+end_src
>>>
>>> #+results:
>>> : test1=7 test2=8
>>
>> That's sneaky - I like that solution. But I would have to rename my
>> variables in my code blocks - but I must say I like it. I'll probably
>> use this - it keeps the variables nicely together.
>>
>> Just an idea:
>>
>> :var: :in_table(all-variables)
>>
>> #+tblname: all-tests
>> - 7
>> - 8
>>
>> #+tblname: all-variables
>> | A | 20 |
>> | B | "next value" |
>> | C | 13 |
>> | test | all-tests |
>>
>> which would create the variables A with value 20, B with value "next
>> value" and C with value 13, and the variable tests would be based on the
>> table all-tests (i.e. test1 = 7, test2 = 8).
>>
>> That would be *really* neat and useful to use. as one would have a
>> nicely formatted table of all variables and their values.
>>
>> One could even go one step further and say that when no value is
>> specified in the second column, the variable is removed and if the
>> variable already exists it is overwritten.
>>
>> In this case, the limitation of one line :var only would not be a
>> problem any more.
>>
>> While we are at variables, it could be useful to rename or copy
>> variables as well:
>>
>> rename A to B:
>>
>> :var :rename(A, B)
>>
>> or copy A to B
>>
>> :var :copy(A, B)
>>
>> But probably not that useful.
>>
>> Cheers and thanks,
>>
>> Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VDcsACgkQoYgNqgF2egoXGgCeMscC89HtKR+EN5ckP/ldPzfr
q3kAn38V5fzWvDGqUlhq33Q8TPo6JlYk
=dn/f
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 10:22 ` Rainer M Krug
@ 2011-02-11 11:55 ` Dan Davison
2011-02-11 12:29 ` Rainer M Krug
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-11 11:55 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
Rainer M Krug <r.m.krug@gmail.com> writes:
> On 02/11/2011 10:32 AM, Dan Davison wrote:
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> On 02/10/2011 05:48 PM, Eric Schulte wrote:
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>
>>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>>>> the code, no other executable line must occur. As I am using variables
>>>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>>>> variables defined by using :var for a subtree?
>>>>>>>
>>>>>>
>>>>>> Hi Rainer,
>>>>>>
>>>>>> Interesting question... unfortunately I don't think that removing
>>>>>> variables from header arguments is possible under the current setup.
>>>>>>
>>>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>>>> which recognizes when it is being called in a just-tangled torqu script
>>>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>>>> lines between the shebang and the first #PBS line?
>>>>>
>>>>> That is also an option - what I am using at the moment is to use
>>>>> :no-expand as a code block specific header argument. But this raises the
>>>>> other question:
>>>>>
>>>>> Can I set the :no-expand in a properties block? As far as I understand,
>>>>> in the properties block I have the argument and the value - but what do
>>>>> I do with :noexpand?
>>>>>
>>>>> :PROPERTIES:
>>>>> :var: A=13
>>>>> :no-expand
>>>>> :END:
>>>>>
>>>>
>>>> You can just set it to "yes" or really any value you like (the value
>>>> will be ignored). I did however have to add "no-expand" to the list of
>>>> header argument names searched for in property blocks -- I just pushed
>>>> up a patch to this effect.
>>>
>>> Thanks - I'll try it today and come back if it does not work.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> More generally, I wonder what a natural method would be to allow
>>>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>>>> This may only apply to the :var header argument, as most others have a
>>>>>> default setting which can be actively set. If you have any ideas for a
>>>>>> natural syntax for such an operation I'd be happy to hear it.
>>>>>
>>>>> First solution (probably the easiest to implement) would be along the
>>>>> lines of the :no-expand header argument -
>>>>>
>>>>> :expand-var yes
>>>>> and
>>>>> :expand-var no
>>>>>
>>>>> This could possibly be expanded to
>>>>> :expand-var A B C
>>>>>
>>>>> which would expand only the variables A B and C
>>>>>
>>>>> One step further: one could define groups of variables, like
>>>>> :var-group X=A,B,C
>>>>> or a similar syntax
>>>>>
>>>>> and then
>>>>> :expand-var X
>>>>> would expand A B and C
>>>>>
>>>>> This all would not be real unset - but a possibility for unsetting would be
>>>>>
>>>>> :var B=
>>>>>
>>>>> or
>>>>>
>>>>> :var-unset B
>>>>>
>>>>> i.e. if no value is specified in :var, the variable will be removed
>>>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>>>
>>>>> :var B=(null)
>>>>>
>>>>
>>>> Thanks for the ideas,
>>>>
>>>> I think you're right that something along the lines of the above should
>>>> be the easiest to implement, however after reading these suggestions,
>>>> I'm thinking that more generally there are a couple of other header
>>>> arguments which could need to be unset, namely
>>>> - file
>>>> - dir
>>>> - session
>>>> - shebang
>>>> some of these (like session) accept a "none" value which has the effect
>>>> of un-setting the header argument.
>>>
>>> True - haven't thought about those (and did not know about :dir useful
>>> one!). And the :session might definitely come in handy - I have cases,
>>> where I reset it manually before evaluating certain sections of the block.
>>>
>>>>
>>>> It would be nice to generalize whatever solution we apply across all
>>>> types of header argument (both for implementation and for user
>>>> simplicity).
>>>
>>> Absolutely - coherent solutions are definitely the best.
>>>
>>>> The simplest option would probably be to ensure that
>>>> setting any header argument to :none would remove all instances of that
>>>> header argument.
>>>
>>> Agreed - makes perfect sense. But probably for readibility use something
>>> like:
>>>
>>> : header :remove()
>>>
>>> or
>>>
>>> :header :remove
>>>
>>>> The only problem there is cases like var, where you
>>>> might not want to remove all :var's. Maybe this could be expanded
>>>> s.t. :none could take arguments, e.g.
>>>>
>>>> :header :none(A, B)
>>>>
>>>> which would remove all instances of the "header" header argument whose
>>>> value is or is named "A" or "B"?
>>>
>>> I would stick to the name of the variable - that is more consistent.
>>>
>>> But instead of :none() I would suggest :remove :
>>>
>>> :header :remove(A, B)
>>>
>>> and if one wants to remove all variables with *value "A"*, one could use
>>>
>>> :header :remove("A")
>>>
>>> Or does that look too funky?
>>>
>>> No - I like it.
>>
>> I'm concerned that all this is looking rather complex. And I'm a bit
>> dubious about the :xxx syntax -- those should correspond to keys in an
>> association list. Could we step back a moment -- would someone mind
>> giving me a concrete example of a problem whose solution requires these
>> new features?
>
Hi Rainer,
> Here is my situation:
>
> I am using org-babel to write analysis for a cluster environment, which
> uses torque. To make my scripts flexible, I am using variables defined
> in the beginning of the org document.
> Everything works fine for after tangling in most of the scripts, but in
> the submission script for the cluster (a nash scripd with definitions
> for processing of the cluster job, following *directly/* after the
> shebang, this causes problems, as the options are expected directly
> after the shebang, and when variables are defined in the org file, these
> will be included directly after the shebang. This results in torque not
> finding the parameter it needs to successfully process the job.
>
> So at the moment, I am using :no-expand to avoid this,
But don't you need the variables?
OK, so let's have a concrete example to play with. Here are two ideas --
are either of these any good for you?
1. Use noweb to include the variables
-------------------------------------------
#+srcname: set-variables
#+begin_src sh
A=13
B=14
#+end_src
#+begin_src sh :tangle script.sh :noweb yes :shebang #!/bin/bash
#$ -cwd
<<set-variables>>
#+end_src
-------------------------------------------
2. It should be possible somehow to include the options together with
the shebang, or to replace :shebang with a more general "preamble"
concept. Or to make :shebang accept a code block as its value.
--------------------------------------------
#+BABEL: :var A=13
#+BABEL: :var B=14
#+header: :shebang #!/bin/bash #$ -cwd
#+begin_src sh :tangle script.sh
# empty
#+end_src
--------------------------------------------
[...]
> I must admit, I am not clear what you men with "those should correspond
> to keys in an association list" - I am definitely not a lisp / elisp
> person and only a regular user of emacs / org mode / ESS.
In the header lines, words that start with a colon are the *names* of
options, and the bits inbetween are the *values* of those options. So
I'm just whinging about using a word starting with a colon for something
which is essentially a value.
I'm going to put some separate suggestions that involve code changes in
a separate reply.
Dan
>
> Hope this clarifies my suggestion a bit,
>
> Cheers,
>
> Rainer
>
>
>>
>>>
>>> For consistency, one could also have a function :set() which could be
>>> used as follow:
>>>
>>> :header :set(A=12, B=13)
>>>
>>> to set the "header" header argument A to 12 and B to 13.
>>>
>>> And then probably use :unset instead of :remove?
>>>
>>> Just thinking along while I am typing...
>>>
>>>
>>>>
>>>>>
>>>>> But this raises another question of mine:
>>>>>
>>>>> I tried to use two :var headers in a properties block, but it only used
>>>>> the first - did I miss something here?
>>>>>
>>>>
>>>> Nope, it appears that property blocks (like a hash) assume that there is
>>>> only one instance of each key->value pair, so once it is satisfied it
>>>> will quit looking for more instances.
>>>
>>> But not always - there are exceptions, e.g. #+LATEX_HEADER: of which I
>>> can specify more then one.
>>> I am asking, because I have a horribly long line of #+BABEL: :var ....
>>> and would really like to split it in two.
>>
>> I believe that I fixed that at 05ef2ae7c (2011/01/20) -- i.e., you can
>> split it in two.
>
> Org-mode version 7.4 (release_7.4.338.gda8dc) (updated this morning)
>
> Thanks - that makes life easier. When I use
>
> #+BABEL: :var A=13
> #+BABEL: :var B=14
>
> Both are defined - but it still does not work in a properties block (as
> in the Eris's example).
>
>
>
>>
>> Dan
>>
>>>
>>>> Maybe the following alternative
>>>> will suffice
>>>>
>>>> Best -- Eric
>>>>
>>>> ** two vars in a properties block -- not possible
>>>> :PROPERTIES:
>>>> :var: test1=7
>>>> :var: test2=8
>>>> :END:
>>>>
>>>> #+begin_src emacs-lisp
>>>> (message "test1=%S test2=%S" test1 test2)
>>>> #+end_src
>>>>
>>>> results in Error
>>>> : let: Symbol's value as variable is void: test2
>>>>
>>>> *** an alternative
>>>> :PROPERTIES:
>>>> :var: tests=all-tests
>>>> :END:
>>>>
>>>> #+tblname: all-tests
>>>> - 7
>>>> - 8
>>>>
>>>> #+begin_src emacs-lisp :var eric=89
>>>> (message "test1=%S test2=%S" (first tests) (second tests))
>>>> #+end_src
>>>>
>>>> #+results:
>>>> : test1=7 test2=8
>>>
>>> That's sneaky - I like that solution. But I would have to rename my
>>> variables in my code blocks - but I must say I like it. I'll probably
>>> use this - it keeps the variables nicely together.
>>>
>>> Just an idea:
>>>
>>> :var: :in_table(all-variables)
>>>
>>> #+tblname: all-tests
>>> - 7
>>> - 8
>>>
>>> #+tblname: all-variables
>>> | A | 20 |
>>> | B | "next value" |
>>> | C | 13 |
>>> | test | all-tests |
>>>
>>> which would create the variables A with value 20, B with value "next
>>> value" and C with value 13, and the variable tests would be based on the
>>> table all-tests (i.e. test1 = 7, test2 = 8).
>>>
>>> That would be *really* neat and useful to use. as one would have a
>>> nicely formatted table of all variables and their values.
>>>
>>> One could even go one step further and say that when no value is
>>> specified in the second column, the variable is removed and if the
>>> variable already exists it is overwritten.
>>>
>>> In this case, the limitation of one line :var only would not be a
>>> problem any more.
>>>
>>> While we are at variables, it could be useful to rename or copy
>>> variables as well:
>>>
>>> rename A to B:
>>>
>>> :var :rename(A, B)
>>>
>>> or copy A to B
>>>
>>> :var :copy(A, B)
>>>
>>> But probably not that useful.
>>>
>>> Cheers and thanks,
>>>
>>> Rainer
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-10 16:48 ` Eric Schulte
2011-02-11 9:00 ` Rainer M Krug
@ 2011-02-11 12:19 ` Dan Davison
2011-02-11 12:58 ` Rainer M Krug
2011-02-11 14:16 ` Eric Schulte
1 sibling, 2 replies; 26+ messages in thread
From: Dan Davison @ 2011-02-11 12:19 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode, Rainer M Krug
"Eric Schulte" <schulte.eric@gmail.com> writes:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> Hi
>>>>
>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>> runing torqu. The important bit in this is, that between the shebang and
>>>> the code, no other executable line must occur. As I am using variables
>>>> in org (:var) they will occur just after the shebang, which causes a
>>>> problem for torque. So, my question is, is there a way to "unset"
>>>> variables defined by using :var for a subtree?
>>>>
>>>
>>> Hi Rainer,
>>>
>>> Interesting question... unfortunately I don't think that removing
>>> variables from header arguments is possible under the current setup.
>>>
>>> Perhaps in your case you could add a function to the post-tangle hook,
>>> which recognizes when it is being called in a just-tangled torqu script
>>> (maybe by searching for a series of #PBS lines), and then removes any
>>> lines between the shebang and the first #PBS line?
>>
>> That is also an option - what I am using at the moment is to use
>> :no-expand as a code block specific header argument. But this raises the
>> other question:
>>
>> Can I set the :no-expand in a properties block? As far as I understand,
>> in the properties block I have the argument and the value - but what do
>> I do with :noexpand?
>>
>> :PROPERTIES:
>> :var: A=13
>> :no-expand
>> :END:
>>
>
> You can just set it to "yes" or really any value you like (the value
> will be ignored). I did however have to add "no-expand" to the list of
> header argument names searched for in property blocks -- I just pushed
> up a patch to this effect.
>
>>
>>>
>>> More generally, I wonder what a natural method would be to allow
>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>> This may only apply to the :var header argument, as most others have a
>>> default setting which can be actively set. If you have any ideas for a
>>> natural syntax for such an operation I'd be happy to hear it.
>>
>> First solution (probably the easiest to implement) would be along the
>> lines of the :no-expand header argument -
>>
>> :expand-var yes
>> and
>> :expand-var no
>>
>> This could possibly be expanded to
>> :expand-var A B C
>>
>> which would expand only the variables A B and C
>>
>> One step further: one could define groups of variables, like
>> :var-group X=A,B,C
>> or a similar syntax
>>
>> and then
>> :expand-var X
>> would expand A B and C
>>
>> This all would not be real unset - but a possibility for unsetting would be
>>
>> :var B=
>>
>> or
>>
>> :var-unset B
>>
>> i.e. if no value is specified in :var, the variable will be removed
>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>
>> :var B=(null)
>>
>
> Thanks for the ideas,
>
> I think you're right that something along the lines of the above should
> be the easiest to implement, however after reading these suggestions,
> I'm thinking that more generally there are a couple of other header
> arguments which could need to be unset, namely
> - file
> - dir
> - session
> - shebang
> some of these (like session) accept a "none" value which has the effect
> of un-setting the header argument.
>
> It would be nice to generalize whatever solution we apply across all
> types of header argument (both for implementation and for user
> simplicity).
Some half thought-through suggestions. Sorry if this is a bit
disorganized.
I wonder whether we should be using Org property inheritance here. If it
were possible to turn off property inheritance temporarily for the
execution of the block, then it could be prevented from inheriting the
header args that you don't want it to inherit. Perhaps babel could offer
a :bind header argument, which specifies the values of lisp variables in
a let-binding which encloses the src block execution?
#+header: :bind org-babel-use-property-inheritance nil
#+begin_src sh :tangle script.sh :shebang #!/bin/bash
#$ -cwd
#+end_src
with a patch along these lines
+(defvar org-babel-use-property-inheritance t
+ "When looking for org-babel header arguments in in-buffer
+ properties, this variable is passed as the INHERIT argument to
+ the function `org-enrty-get'")
+
(defvar org-file-properties)
(defun org-babel-params-from-properties (&optional lang)
"Retrieve parameters specified as properties.
@@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
(lambda (header-arg)
(and (setq val
(or (condition-case nil
- (org-entry-get (point) header-arg t)
+ (org-entry-get (point) header-arg org-babel-use-property-inheritance)
(error nil))
(cdr (assoc header-arg org-file-properties))))
(cons (intern (concat ":" header-arg))
In fact, that might be more widely useful in Org -- it would offer a
sort of 'subtree local variables', as an analog of buffer local
variables. Like any other babel variable, BIND could be set in a
property drawer, but perhaps other subtree-specific Org operations such
as export and tangling could honour BIND by enclosing their execution in
the appropriate let binding? Variables bound by BIND in enclosing
subtrees should be shadowed by those bound in more local subtrees, of
course.
On a related note, I wonder whether the #+BABEL line should be
re-implemented so that it works via setting org-file-properties?
I.e. made equivalent to a #+PROPERTIES line?
Finally, a feature for babel power users could be to offer a hook
function which allows modification of the source block data structure
immediately prior to execution. In the babel code, source blocks are
basically converted into an elisp data structure that tends to be called
`info'. We could have org-babel-src-block-modification-hook each
function of which would be passed the value of info and given the
opportunity to change it just before execution. For anyone who's
prepared to write elisp, that would permit a wide class of
modifications, such as knocking out the :var variables.
And this hook could be set at a subtree level by a BIND property...
Dan
> The simplest option would probably be to ensure that
> setting any header argument to :none would remove all instances of that
> header argument. The only problem there is cases like var, where you
> might not want to remove all :var's. Maybe this could be expanded
> s.t. :none could take arguments, e.g.
>
> :header :none(A, B)
>
> which would remove all instances of the "header" header argument whose
> value is or is named "A" or "B"? Or does that look too funky?
>
>>
>> But this raises another question of mine:
>>
>> I tried to use two :var headers in a properties block, but it only used
>> the first - did I miss something here?
>>
>
> Nope, it appears that property blocks (like a hash) assume that there is
> only one instance of each key->value pair, so once it is satisfied it
> will quit looking for more instances. Maybe the following alternative
> will suffice
>
> Best -- Eric
>
> ** two vars in a properties block -- not possible
> :PROPERTIES:
> :var: test1=7
> :var: test2=8
> :END:
>
> #+begin_src emacs-lisp
> (message "test1=%S test2=%S" test1 test2)
> #+end_src
>
> results in Error
> : let: Symbol's value as variable is void: test2
>
> *** an alternative
> :PROPERTIES:
> :var: tests=all-tests
> :END:
>
> #+tblname: all-tests
> - 7
> - 8
>
> #+begin_src emacs-lisp :var eric=89
> (message "test1=%S test2=%S" (first tests) (second tests))
> #+end_src
>
> #+results:
> : test1=7 test2=8
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 11:55 ` Dan Davison
@ 2011-02-11 12:29 ` Rainer M Krug
2011-02-11 13:49 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 12:29 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2011 12:55 PM, Dan Davison wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 02/11/2011 10:32 AM, Dan Davison wrote:
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> On 02/10/2011 05:48 PM, Eric Schulte wrote:
>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>
>>>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>>>>> the code, no other executable line must occur. As I am using variables
>>>>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>>>>> variables defined by using :var for a subtree?
>>>>>>>>
>>>>>>>
>>>>>>> Hi Rainer,
>>>>>>>
>>>>>>> Interesting question... unfortunately I don't think that removing
>>>>>>> variables from header arguments is possible under the current setup.
>>>>>>>
>>>>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>>>>> which recognizes when it is being called in a just-tangled torqu script
>>>>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>>>>> lines between the shebang and the first #PBS line?
>>>>>>
>>>>>> That is also an option - what I am using at the moment is to use
>>>>>> :no-expand as a code block specific header argument. But this raises the
>>>>>> other question:
>>>>>>
>>>>>> Can I set the :no-expand in a properties block? As far as I understand,
>>>>>> in the properties block I have the argument and the value - but what do
>>>>>> I do with :noexpand?
>>>>>>
>>>>>> :PROPERTIES:
>>>>>> :var: A=13
>>>>>> :no-expand
>>>>>> :END:
>>>>>>
>>>>>
>>>>> You can just set it to "yes" or really any value you like (the value
>>>>> will be ignored). I did however have to add "no-expand" to the list of
>>>>> header argument names searched for in property blocks -- I just pushed
>>>>> up a patch to this effect.
>>>>
>>>> Thanks - I'll try it today and come back if it does not work.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> More generally, I wonder what a natural method would be to allow
>>>>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>>>>> This may only apply to the :var header argument, as most others have a
>>>>>>> default setting which can be actively set. If you have any ideas for a
>>>>>>> natural syntax for such an operation I'd be happy to hear it.
>>>>>>
>>>>>> First solution (probably the easiest to implement) would be along the
>>>>>> lines of the :no-expand header argument -
>>>>>>
>>>>>> :expand-var yes
>>>>>> and
>>>>>> :expand-var no
>>>>>>
>>>>>> This could possibly be expanded to
>>>>>> :expand-var A B C
>>>>>>
>>>>>> which would expand only the variables A B and C
>>>>>>
>>>>>> One step further: one could define groups of variables, like
>>>>>> :var-group X=A,B,C
>>>>>> or a similar syntax
>>>>>>
>>>>>> and then
>>>>>> :expand-var X
>>>>>> would expand A B and C
>>>>>>
>>>>>> This all would not be real unset - but a possibility for unsetting would be
>>>>>>
>>>>>> :var B=
>>>>>>
>>>>>> or
>>>>>>
>>>>>> :var-unset B
>>>>>>
>>>>>> i.e. if no value is specified in :var, the variable will be removed
>>>>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>>>>
>>>>>> :var B=(null)
>>>>>>
>>>>>
>>>>> Thanks for the ideas,
>>>>>
>>>>> I think you're right that something along the lines of the above should
>>>>> be the easiest to implement, however after reading these suggestions,
>>>>> I'm thinking that more generally there are a couple of other header
>>>>> arguments which could need to be unset, namely
>>>>> - file
>>>>> - dir
>>>>> - session
>>>>> - shebang
>>>>> some of these (like session) accept a "none" value which has the effect
>>>>> of un-setting the header argument.
>>>>
>>>> True - haven't thought about those (and did not know about :dir useful
>>>> one!). And the :session might definitely come in handy - I have cases,
>>>> where I reset it manually before evaluating certain sections of the block.
>>>>
>>>>>
>>>>> It would be nice to generalize whatever solution we apply across all
>>>>> types of header argument (both for implementation and for user
>>>>> simplicity).
>>>>
>>>> Absolutely - coherent solutions are definitely the best.
>>>>
>>>>> The simplest option would probably be to ensure that
>>>>> setting any header argument to :none would remove all instances of that
>>>>> header argument.
>>>>
>>>> Agreed - makes perfect sense. But probably for readibility use something
>>>> like:
>>>>
>>>> : header :remove()
>>>>
>>>> or
>>>>
>>>> :header :remove
>>>>
>>>>> The only problem there is cases like var, where you
>>>>> might not want to remove all :var's. Maybe this could be expanded
>>>>> s.t. :none could take arguments, e.g.
>>>>>
>>>>> :header :none(A, B)
>>>>>
>>>>> which would remove all instances of the "header" header argument whose
>>>>> value is or is named "A" or "B"?
>>>>
>>>> I would stick to the name of the variable - that is more consistent.
>>>>
>>>> But instead of :none() I would suggest :remove :
>>>>
>>>> :header :remove(A, B)
>>>>
>>>> and if one wants to remove all variables with *value "A"*, one could use
>>>>
>>>> :header :remove("A")
>>>>
>>>> Or does that look too funky?
>>>>
>>>> No - I like it.
>>>
>>> I'm concerned that all this is looking rather complex. And I'm a bit
>>> dubious about the :xxx syntax -- those should correspond to keys in an
>>> association list. Could we step back a moment -- would someone mind
>>> giving me a concrete example of a problem whose solution requires these
>>> new features?
>>
>
> Hi Rainer,
>
>> Here is my situation:
>>
>> I am using org-babel to write analysis for a cluster environment, which
>> uses torque. To make my scripts flexible, I am using variables defined
>> in the beginning of the org document.
>> Everything works fine for after tangling in most of the scripts, but in
>> the submission script for the cluster (a nash scripd with definitions
>> for processing of the cluster job, following *directly/* after the
>> shebang, this causes problems, as the options are expected directly
>> after the shebang, and when variables are defined in the org file, these
>> will be included directly after the shebang. This results in torque not
>> finding the parameter it needs to successfully process the job.
>>
>> So at the moment, I am using :no-expand to avoid this,
>
> But don't you need the variables?
I need them, but not in the submit script.
>
> OK, so let's have a concrete example to play with. Here are two ideas --
> are either of these any good for you?
>
> 1. Use noweb to include the variables
>
> -------------------------------------------
> #+srcname: set-variables
> #+begin_src sh
> A=13
> B=14
> #+end_src
>
> #+begin_src sh :tangle script.sh :noweb yes :shebang #!/bin/bash
> #$ -cwd
> <<set-variables>>
> #+end_src
I have scripts in R and in bash and I wold like to be able to use the
same variables in both script types - so no and yes - at the moment this
would work, but definitely would not be my favourite solution.
In addition, I like that the variable definition are in org and not in a
source block somewhere.
> -------------------------------------------
>
> 2. It should be possible somehow to include the options together with
> the shebang, or to replace :shebang with a more general "preamble"
> concept. Or to make :shebang accept a code block as its value.
>
> --------------------------------------------
> #+BABEL: :var A=13
> #+BABEL: :var B=14
>
> #+header: :shebang #!/bin/bash #$ -cwd
> #+begin_src sh :tangle script.sh
> # empty
> #+end_src
> --------------------------------------------
Similar to above - should work, but now the options for torque are
hidden in the shebang - which is not to nice, but should work - although
changing the options is not nearly as nice as if the options are in the
source block.
>
> [...]
>
>> I must admit, I am not clear what you men with "those should correspond
>> to keys in an association list" - I am definitely not a lisp / elisp
>> person and only a regular user of emacs / org mode / ESS.
>
> In the header lines, words that start with a colon are the *names* of
> options, and the bits inbetween are the *values* of those options. So
> I'm just whinging about using a word starting with a colon for something
> which is essentially a value.
OK - point taken.
>
> I'm going to put some separate suggestions that involve code changes in
> a separate reply.
>
> Dan
>
>
>
>>
>> Hope this clarifies my suggestion a bit,
>>
>> Cheers,
>>
>> Rainer
>>
>>
>>>
>>>>
>>>> For consistency, one could also have a function :set() which could be
>>>> used as follow:
>>>>
>>>> :header :set(A=12, B=13)
>>>>
>>>> to set the "header" header argument A to 12 and B to 13.
>>>>
>>>> And then probably use :unset instead of :remove?
>>>>
>>>> Just thinking along while I am typing...
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> But this raises another question of mine:
>>>>>>
>>>>>> I tried to use two :var headers in a properties block, but it only used
>>>>>> the first - did I miss something here?
>>>>>>
>>>>>
>>>>> Nope, it appears that property blocks (like a hash) assume that there is
>>>>> only one instance of each key->value pair, so once it is satisfied it
>>>>> will quit looking for more instances.
>>>>
>>>> But not always - there are exceptions, e.g. #+LATEX_HEADER: of which I
>>>> can specify more then one.
>>>> I am asking, because I have a horribly long line of #+BABEL: :var ....
>>>> and would really like to split it in two.
>>>
>>> I believe that I fixed that at 05ef2ae7c (2011/01/20) -- i.e., you can
>>> split it in two.
>>
>> Org-mode version 7.4 (release_7.4.338.gda8dc) (updated this morning)
>>
>> Thanks - that makes life easier. When I use
>>
>> #+BABEL: :var A=13
>> #+BABEL: :var B=14
>>
>> Both are defined - but it still does not work in a properties block (as
>> in the Eris's example).
>>
>>
>>
>>>
>>> Dan
>>>
>>>>
>>>>> Maybe the following alternative
>>>>> will suffice
>>>>>
>>>>> Best -- Eric
>>>>>
>>>>> ** two vars in a properties block -- not possible
>>>>> :PROPERTIES:
>>>>> :var: test1=7
>>>>> :var: test2=8
>>>>> :END:
>>>>>
>>>>> #+begin_src emacs-lisp
>>>>> (message "test1=%S test2=%S" test1 test2)
>>>>> #+end_src
>>>>>
>>>>> results in Error
>>>>> : let: Symbol's value as variable is void: test2
>>>>>
>>>>> *** an alternative
>>>>> :PROPERTIES:
>>>>> :var: tests=all-tests
>>>>> :END:
>>>>>
>>>>> #+tblname: all-tests
>>>>> - 7
>>>>> - 8
>>>>>
>>>>> #+begin_src emacs-lisp :var eric=89
>>>>> (message "test1=%S test2=%S" (first tests) (second tests))
>>>>> #+end_src
>>>>>
>>>>> #+results:
>>>>> : test1=7 test2=8
>>>>
>>>> That's sneaky - I like that solution. But I would have to rename my
>>>> variables in my code blocks - but I must say I like it. I'll probably
>>>> use this - it keeps the variables nicely together.
>>>>
>>>> Just an idea:
>>>>
>>>> :var: :in_table(all-variables)
>>>>
>>>> #+tblname: all-tests
>>>> - 7
>>>> - 8
>>>>
>>>> #+tblname: all-variables
>>>> | A | 20 |
>>>> | B | "next value" |
>>>> | C | 13 |
>>>> | test | all-tests |
>>>>
>>>> which would create the variables A with value 20, B with value "next
>>>> value" and C with value 13, and the variable tests would be based on the
>>>> table all-tests (i.e. test1 = 7, test2 = 8).
>>>>
>>>> That would be *really* neat and useful to use. as one would have a
>>>> nicely formatted table of all variables and their values.
>>>>
>>>> One could even go one step further and say that when no value is
>>>> specified in the second column, the variable is removed and if the
>>>> variable already exists it is overwritten.
>>>>
>>>> In this case, the limitation of one line :var only would not be a
>>>> problem any more.
>>>>
>>>> While we are at variables, it could be useful to rename or copy
>>>> variables as well:
>>>>
>>>> rename A to B:
>>>>
>>>> :var :rename(A, B)
>>>>
>>>> or copy A to B
>>>>
>>>> :var :copy(A, B)
>>>>
>>>> But probably not that useful.
>>>>
>>>> Cheers and thanks,
>>>>
>>>> Rainer
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VK8YACgkQoYgNqgF2egroxgCfRiu5UwdWE+6Xk/7x3/yPS5AK
FaIAnAgX5xYe1UbdO65RHxMC7ta2SHE9
=Wqzm
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 12:19 ` Dan Davison
@ 2011-02-11 12:58 ` Rainer M Krug
2011-02-11 13:41 ` Dan Davison
2011-02-11 14:16 ` Eric Schulte
1 sibling, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 12:58 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2011 01:19 PM, Dan Davison wrote:
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>
>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>
>>>>> Hi
>>>>>
>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>> the code, no other executable line must occur. As I am using variables
>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>> variables defined by using :var for a subtree?
>>>>>
>>>>
>>>> Hi Rainer,
>>>>
>>>> Interesting question... unfortunately I don't think that removing
>>>> variables from header arguments is possible under the current setup.
>>>>
>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>> which recognizes when it is being called in a just-tangled torqu script
>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>> lines between the shebang and the first #PBS line?
>>>
>>> That is also an option - what I am using at the moment is to use
>>> :no-expand as a code block specific header argument. But this raises the
>>> other question:
>>>
>>> Can I set the :no-expand in a properties block? As far as I understand,
>>> in the properties block I have the argument and the value - but what do
>>> I do with :noexpand?
>>>
>>> :PROPERTIES:
>>> :var: A=13
>>> :no-expand
>>> :END:
>>>
>>
>> You can just set it to "yes" or really any value you like (the value
>> will be ignored). I did however have to add "no-expand" to the list of
>> header argument names searched for in property blocks -- I just pushed
>> up a patch to this effect.
>>
>>>
>>>>
>>>> More generally, I wonder what a natural method would be to allow
>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>> This may only apply to the :var header argument, as most others have a
>>>> default setting which can be actively set. If you have any ideas for a
>>>> natural syntax for such an operation I'd be happy to hear it.
>>>
>>> First solution (probably the easiest to implement) would be along the
>>> lines of the :no-expand header argument -
>>>
>>> :expand-var yes
>>> and
>>> :expand-var no
>>>
>>> This could possibly be expanded to
>>> :expand-var A B C
>>>
>>> which would expand only the variables A B and C
>>>
>>> One step further: one could define groups of variables, like
>>> :var-group X=A,B,C
>>> or a similar syntax
>>>
>>> and then
>>> :expand-var X
>>> would expand A B and C
>>>
>>> This all would not be real unset - but a possibility for unsetting would be
>>>
>>> :var B=
>>>
>>> or
>>>
>>> :var-unset B
>>>
>>> i.e. if no value is specified in :var, the variable will be removed
>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>
>>> :var B=(null)
>>>
>>
>> Thanks for the ideas,
>>
>> I think you're right that something along the lines of the above should
>> be the easiest to implement, however after reading these suggestions,
>> I'm thinking that more generally there are a couple of other header
>> arguments which could need to be unset, namely
>> - file
>> - dir
>> - session
>> - shebang
>> some of these (like session) accept a "none" value which has the effect
>> of un-setting the header argument.
>>
>> It would be nice to generalize whatever solution we apply across all
>> types of header argument (both for implementation and for user
>> simplicity).
>
> Some half thought-through suggestions. Sorry if this is a bit
> disorganized.
>
> I wonder whether we should be using Org property inheritance here. If it
> were possible to turn off property inheritance temporarily for the
> execution of the block, then it could be prevented from inheriting the
> header args that you don't want it to inherit. Perhaps babel could offer
> a :bind header argument, which specifies the values of lisp variables in
> a let-binding which encloses the src block execution?
The whole logic in org is that, if I understand correctly, of the
smaller unit (e.g. file -> subtree -> ... -> code block) inheriting
properties, variables, ... from the next larger unit - introducing a
possibility to disable inheritance, would introduce a completely new
level of complexity. I think that one should rather introduce a way of
unsetting e.g. variable values to have the same effect, but still
sticking with the whole inheritance logic.
I reslly think that it might be dangerous to open the possibility to
break this inheritance principle.
>
> #+header: :bind org-babel-use-property-inheritance nil
> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
> #$ -cwd
> #+end_src
>
> with a patch along these lines
>
> +(defvar org-babel-use-property-inheritance t
> + "When looking for org-babel header arguments in in-buffer
> + properties, this variable is passed as the INHERIT argument to
> + the function `org-enrty-get'")
> +
> (defvar org-file-properties)
> (defun org-babel-params-from-properties (&optional lang)
> "Retrieve parameters specified as properties.
> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
> (lambda (header-arg)
> (and (setq val
> (or (condition-case nil
> - (org-entry-get (point) header-arg t)
> + (org-entry-get (point) header-arg org-babel-use-property-inheritance)
> (error nil))
> (cdr (assoc header-arg org-file-properties))))
> (cons (intern (concat ":" header-arg))
>
>
> In fact, that might be more widely useful in Org -- it would offer a
> sort of 'subtree local variables', as an analog of buffer local
> variables.
If I define a variable in a PROPERTIES block, it is only valid in the
subtree - so don't we have that already?
> Like any other babel variable, BIND could be set in a
> property drawer, but perhaps other subtree-specific Org operations such
> as export and tangling could honour BIND by enclosing their execution in
> the appropriate let binding? Variables bound by BIND in enclosing
> subtrees should be shadowed by those bound in more local subtrees, of
> course.
>
> On a related note, I wonder whether the #+BABEL line should be
> re-implemented so that it works via setting org-file-properties?
> I.e. made equivalent to a #+PROPERTIES line?
Yes please - I was not even aware that they were gone - only surprised
that some things did not work any more as expected.
So how can I now define multiple variables?
in a properties drawer multiple :var does not work? Could you give a
simple example how to define variables A and B?
I think I am now completely confused.
>
> Finally, a feature for babel power users could be to offer a hook
> function which allows modification of the source block data structure
> immediately prior to execution. In the babel code, source blocks are
> basically converted into an elisp data structure that tends to be called
> `info'. We could have org-babel-src-block-modification-hook each
> function of which would be passed the value of info and given the
> opportunity to change it just before execution. For anyone who's
> prepared to write elisp, that would permit a wide class of
> modifications, such as knocking out the :var variables.
>
> And this hook could be set at a subtree level by a BIND property...
Sorry - now you have lost me.
All I suggested was a way to unset a variable ...
>
> Dan
>
>
>
>
>> The simplest option would probably be to ensure that
>> setting any header argument to :none would remove all instances of that
>> header argument. The only problem there is cases like var, where you
>> might not want to remove all :var's. Maybe this could be expanded
>> s.t. :none could take arguments, e.g.
>>
>> :header :none(A, B)
>>
>> which would remove all instances of the "header" header argument whose
>> value is or is named "A" or "B"? Or does that look too funky?
>>
>>>
>>> But this raises another question of mine:
>>>
>>> I tried to use two :var headers in a properties block, but it only used
>>> the first - did I miss something here?
>>>
>>
>> Nope, it appears that property blocks (like a hash) assume that there is
>> only one instance of each key->value pair, so once it is satisfied it
>> will quit looking for more instances. Maybe the following alternative
>> will suffice
>>
>> Best -- Eric
>>
>> ** two vars in a properties block -- not possible
>> :PROPERTIES:
>> :var: test1=7
>> :var: test2=8
>> :END:
>>
>> #+begin_src emacs-lisp
>> (message "test1=%S test2=%S" test1 test2)
>> #+end_src
>>
>> results in Error
>> : let: Symbol's value as variable is void: test2
>>
>> *** an alternative
>> :PROPERTIES:
>> :var: tests=all-tests
>> :END:
>>
>> #+tblname: all-tests
>> - 7
>> - 8
>>
>> #+begin_src emacs-lisp :var eric=89
>> (message "test1=%S test2=%S" (first tests) (second tests))
>> #+end_src
>>
>> #+results:
>> : test1=7 test2=8
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VMpAACgkQoYgNqgF2egod9ACggrItU1JmMsTeCndZtXgYhR9p
J8UAoInCP50UZpodWMj5TXsfOQIrAH8N
=AyR7
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 12:58 ` Rainer M Krug
@ 2011-02-11 13:41 ` Dan Davison
2011-02-11 14:05 ` Rainer M Krug
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-11 13:41 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
Rainer M Krug <r.m.krug@gmail.com> writes:
> On 02/11/2011 01:19 PM, Dan Davison wrote:
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>>> the code, no other executable line must occur. As I am using variables
>>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>>> variables defined by using :var for a subtree?
>>>>>>
>>>>>
>>>>> Hi Rainer,
>>>>>
>>>>> Interesting question... unfortunately I don't think that removing
>>>>> variables from header arguments is possible under the current setup.
>>>>>
>>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>>> which recognizes when it is being called in a just-tangled torqu script
>>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>>> lines between the shebang and the first #PBS line?
>>>>
>>>> That is also an option - what I am using at the moment is to use
>>>> :no-expand as a code block specific header argument. But this raises the
>>>> other question:
>>>>
>>>> Can I set the :no-expand in a properties block? As far as I understand,
>>>> in the properties block I have the argument and the value - but what do
>>>> I do with :noexpand?
>>>>
>>>> :PROPERTIES:
>>>> :var: A=13
>>>> :no-expand
>>>> :END:
>>>>
>>>
>>> You can just set it to "yes" or really any value you like (the value
>>> will be ignored). I did however have to add "no-expand" to the list of
>>> header argument names searched for in property blocks -- I just pushed
>>> up a patch to this effect.
>>>
>>>>
>>>>>
>>>>> More generally, I wonder what a natural method would be to allow
>>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>>> This may only apply to the :var header argument, as most others have a
>>>>> default setting which can be actively set. If you have any ideas for a
>>>>> natural syntax for such an operation I'd be happy to hear it.
>>>>
>>>> First solution (probably the easiest to implement) would be along the
>>>> lines of the :no-expand header argument -
>>>>
>>>> :expand-var yes
>>>> and
>>>> :expand-var no
>>>>
>>>> This could possibly be expanded to
>>>> :expand-var A B C
>>>>
>>>> which would expand only the variables A B and C
>>>>
>>>> One step further: one could define groups of variables, like
>>>> :var-group X=A,B,C
>>>> or a similar syntax
>>>>
>>>> and then
>>>> :expand-var X
>>>> would expand A B and C
>>>>
>>>> This all would not be real unset - but a possibility for unsetting would be
>>>>
>>>> :var B=
>>>>
>>>> or
>>>>
>>>> :var-unset B
>>>>
>>>> i.e. if no value is specified in :var, the variable will be removed
>>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>>
>>>> :var B=(null)
>>>>
>>>
>>> Thanks for the ideas,
>>>
>>> I think you're right that something along the lines of the above should
>>> be the easiest to implement, however after reading these suggestions,
>>> I'm thinking that more generally there are a couple of other header
>>> arguments which could need to be unset, namely
>>> - file
>>> - dir
>>> - session
>>> - shebang
>>> some of these (like session) accept a "none" value which has the effect
>>> of un-setting the header argument.
>>>
>>> It would be nice to generalize whatever solution we apply across all
>>> types of header argument (both for implementation and for user
>>> simplicity).
>>
>> Some half thought-through suggestions. Sorry if this is a bit
>> disorganized.
>> I wonder whether we should be using Org property inheritance here. If it
>> were possible to turn off property inheritance temporarily for the
>> execution of the block, then it could be prevented from inheriting the
>> header args that you don't want it to inherit. Perhaps babel could offer
>> a :bind header argument, which specifies the values of lisp variables in
>> a let-binding which encloses the src block execution?
>
> The whole logic in org is that, if I understand correctly, of the
> smaller unit (e.g. file -> subtree -> ... -> code block) inheriting
> properties, variables, ... from the next larger unit - introducing a
> possibility to disable inheritance, would introduce a completely new
> level of complexity.
> I think that one should rather introduce a way of
> unsetting e.g. variable values to have the same effect, but still
> sticking with the whole inheritance logic.
> I reslly think that it might be dangerous to open the possibility to
> break this inheritance principle.
Hi Rainer,
Org already has a way to disable inheritance in general, and on a
property-by-property basis. See
http://orgmode.org/manual/Property-inheritance.html#Property-inheritance
and the docstrings for the variable org-use-property-inheritance and the
function org-entry-get.
It seems that what you want to do can be described as disabling
inheritance of the :var properties for a specific block. So I'm
suggesting that it may be more parsimonious to do this with the existing
Org inheritance mechanisms than to introduce new babel header arguments
specifically for this purpose.
>
>>
>> #+header: :bind org-babel-use-property-inheritance nil
>> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
>> #$ -cwd
>> #+end_src
>>
>> with a patch along these lines
>>
>> +(defvar org-babel-use-property-inheritance t
>> + "When looking for org-babel header arguments in in-buffer
>> + properties, this variable is passed as the INHERIT argument to
>> + the function `org-enrty-get'")
>> +
>> (defvar org-file-properties)
>> (defun org-babel-params-from-properties (&optional lang)
>> "Retrieve parameters specified as properties.
>> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
>> (lambda (header-arg)
>> (and (setq val
>> (or (condition-case nil
>> - (org-entry-get (point) header-arg t)
>> + (org-entry-get (point) header-arg org-babel-use-property-inheritance)
>> (error nil))
>> (cdr (assoc header-arg org-file-properties))))
>> (cons (intern (concat ":" header-arg))
>>
>>
>> In fact, that might be more widely useful in Org -- it would offer a
>> sort of 'subtree local variables', as an analog of buffer local
>> variables.
>
> If I define a variable in a PROPERTIES block, it is only valid in the
> subtree - so don't we have that already?
Here I was talking about emacs-lisp variables being "local to a
particular subtree"; as opposed to Org properties.
>> Like any other babel variable, BIND could be set in a
>> property drawer, but perhaps other subtree-specific Org operations such
>> as export and tangling could honour BIND by enclosing their execution in
>> the appropriate let binding? Variables bound by BIND in enclosing
>> subtrees should be shadowed by those bound in more local subtrees, of
>> course.
>>
>> On a related note, I wonder whether the #+BABEL line should be
>> re-implemented so that it works via setting org-file-properties?
>> I.e. made equivalent to a #+PROPERTIES line?
>
> Yes please - I was not even aware that they were gone
They are not gone. By "re-implemented" I mean implemented in a different
way from how they are currently implemented.
> - only surprised
> that some things did not work any more as expected.
>
> So how can I now define multiple variables?
I don't know :)
> in a properties drawer multiple :var does not work? Could you give a
> simple example how to define variables A and B?
Yes, I've always been a bit uncomfortable with this. As Eric says, Org
properties are supposed to be a bit like a hash, with unique keys.
>
> I think I am now completely confused.
>
>>
>> Finally, a feature for babel power users could be to offer a hook
>> function which allows modification of the source block data structure
>> immediately prior to execution. In the babel code, source blocks are
>> basically converted into an elisp data structure that tends to be called
>> `info'. We could have org-babel-src-block-modification-hook each
>> function of which would be passed the value of info and given the
>> opportunity to change it just before execution. For anyone who's
>> prepared to write elisp, that would permit a wide class of
>> modifications, such as knocking out the :var variables.
>>
>> And this hook could be set at a subtree level by a BIND property...
>
> Sorry - now you have lost me.
> All I suggested was a way to unset a variable ...
I am also suggesting some possible ways to do that, while trying to
avoid special-case solutions. The issue you raised initially was not how
to unset variables, but rather how to prevent stuff getting inbetween
the shebang and the torque options, but it has led to some interesting
ideas. We should probably bear in mind that unsetting variables is
really a hack in the context of your original problem. Even if we make
it possible, what is the solution when we want the variables?
Dan
>
>
>>
>> Dan
>>
>>
>>
>>
>>> The simplest option would probably be to ensure that
>>> setting any header argument to :none would remove all instances of that
>>> header argument. The only problem there is cases like var, where you
>>> might not want to remove all :var's. Maybe this could be expanded
>>> s.t. :none could take arguments, e.g.
>>>
>>> :header :none(A, B)
>>>
>>> which would remove all instances of the "header" header argument whose
>>> value is or is named "A" or "B"? Or does that look too funky?
>>>
>>>>
>>>> But this raises another question of mine:
>>>>
>>>> I tried to use two :var headers in a properties block, but it only used
>>>> the first - did I miss something here?
>>>>
>>>
>>> Nope, it appears that property blocks (like a hash) assume that there is
>>> only one instance of each key->value pair, so once it is satisfied it
>>> will quit looking for more instances. Maybe the following alternative
>>> will suffice
>>>
>>> Best -- Eric
>>>
>>> ** two vars in a properties block -- not possible
>>> :PROPERTIES:
>>> :var: test1=7
>>> :var: test2=8
>>> :END:
>>>
>>> #+begin_src emacs-lisp
>>> (message "test1=%S test2=%S" test1 test2)
>>> #+end_src
>>>
>>> results in Error
>>> : let: Symbol's value as variable is void: test2
>>>
>>> *** an alternative
>>> :PROPERTIES:
>>> :var: tests=all-tests
>>> :END:
>>>
>>> #+tblname: all-tests
>>> - 7
>>> - 8
>>>
>>> #+begin_src emacs-lisp :var eric=89
>>> (message "test1=%S test2=%S" (first tests) (second tests))
>>> #+end_src
>>>
>>> #+results:
>>> : test1=7 test2=8
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 12:29 ` Rainer M Krug
@ 2011-02-11 13:49 ` Dan Davison
2011-02-11 13:56 ` Rainer M Krug
2011-02-12 22:54 ` Eric Schulte
0 siblings, 2 replies; 26+ messages in thread
From: Dan Davison @ 2011-02-11 13:49 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode
[...]
>> 2. It should be possible somehow to include the options together with
>> the shebang, or to replace :shebang with a more general "preamble"
>> concept. Or to make :shebang accept a code block as its value.
>>
>> --------------------------------------------
>> #+BABEL: :var A=13
>> #+BABEL: :var B=14
>>
>> #+header: :shebang #!/bin/bash #$ -cwd
>> #+begin_src sh :tangle script.sh
>> # empty
>> #+end_src
>> --------------------------------------------
>
> Similar to above - should work, but now the options for torque are
> hidden in the shebang - which is not to nice, but should work - although
> changing the options is not nearly as nice as if the options are in the
> source block.
It seems that we should be able to put the preamble lines in a src
block. This works, but only after making an alteration to the sbe
function (below) so that it will allow multiple line results. Maybe Eric
will have some ideas here.
---------------------------------------
#+BABEL: :var A=13
#+BABEL: :var B=14
#+srcname: sheb
#+begin_src sh :results output
echo '#!/bin/bash'
echo '#$ -cwd'
#+end_src
#+header: :shebang (sbe sheb)
#+begin_src sh :tangle script.sh
# empty
#+end_src
---------------------------------------
(setq source-block (symbol-name source-block)))
- (org-babel-table-truncate-at-newline ;; org-table cells can't be multi-line
(if (and source-block (> (length source-block) 0))
(let ((params
(eval `(org-babel-parse-header-arguments
@@ -116,7 +115,7 @@ example above."
")")))))
(org-babel-execute-src-block
nil (list "emacs-lisp" "results" params) '((:results . "silent"))))
- ""))))
+ "")))
Dan
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 13:49 ` Dan Davison
@ 2011-02-11 13:56 ` Rainer M Krug
2011-02-12 22:54 ` Eric Schulte
1 sibling, 0 replies; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 13:56 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2011 02:49 PM, Dan Davison wrote:
> [...]
>>> 2. It should be possible somehow to include the options together with
>>> the shebang, or to replace :shebang with a more general "preamble"
>>> concept. Or to make :shebang accept a code block as its value.
>>>
>>> --------------------------------------------
>>> #+BABEL: :var A=13
>>> #+BABEL: :var B=14
>>>
>>> #+header: :shebang #!/bin/bash #$ -cwd
>>> #+begin_src sh :tangle script.sh
>>> # empty
>>> #+end_src
>>> --------------------------------------------
>>
>> Similar to above - should work, but now the options for torque are
>> hidden in the shebang - which is not to nice, but should work - although
>> changing the options is not nearly as nice as if the options are in the
>> source block.
>
> It seems that we should be able to put the preamble lines in a src
> block. This works, but only after making an alteration to the sbe
> function (below) so that it will allow multiple line results. Maybe Eric
> will have some ideas here.
I think that would be a good idea and make it much more flexible.
If one could then have a source block which would only consist of the
text and not with e.g. echo '', I think it would be perfect.
>
> ---------------------------------------
> #+BABEL: :var A=13
> #+BABEL: :var B=14
>
> #+srcname: sheb
> #+begin_src sh :results output
> echo '#!/bin/bash'
> echo '#$ -cwd'
> #+end_src
>
> #+header: :shebang (sbe sheb)
> #+begin_src sh :tangle script.sh
> # empty
> #+end_src
> ---------------------------------------
>
>
> (setq source-block (symbol-name source-block)))
> - (org-babel-table-truncate-at-newline ;; org-table cells can't be multi-line
> (if (and source-block (> (length source-block) 0))
> (let ((params
> (eval `(org-babel-parse-header-arguments
> @@ -116,7 +115,7 @@ example above."
> ")")))))
> (org-babel-execute-src-block
> nil (list "emacs-lisp" "results" params) '((:results . "silent"))))
> - ""))))
> + "")))
>
>
> Dan
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VQCEACgkQoYgNqgF2egqnvgCcDSl/VCKmgUqXsegDSxuQOAyo
4RgAnj+I+sunbYC5UtY67llifgdgw8Vr
=lRR9
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 13:41 ` Dan Davison
@ 2011-02-11 14:05 ` Rainer M Krug
2011-02-12 23:12 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Rainer M Krug @ 2011-02-11 14:05 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/11/2011 02:41 PM, Dan Davison wrote:
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> On 02/11/2011 01:19 PM, Dan Davison wrote:
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>
>>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> For one project, I am usinr org to write submit scripte to a cluster
>>>>>>> runing torqu. The important bit in this is, that between the shebang and
>>>>>>> the code, no other executable line must occur. As I am using variables
>>>>>>> in org (:var) they will occur just after the shebang, which causes a
>>>>>>> problem for torque. So, my question is, is there a way to "unset"
>>>>>>> variables defined by using :var for a subtree?
>>>>>>>
>>>>>>
>>>>>> Hi Rainer,
>>>>>>
>>>>>> Interesting question... unfortunately I don't think that removing
>>>>>> variables from header arguments is possible under the current setup.
>>>>>>
>>>>>> Perhaps in your case you could add a function to the post-tangle hook,
>>>>>> which recognizes when it is being called in a just-tangled torqu script
>>>>>> (maybe by searching for a series of #PBS lines), and then removes any
>>>>>> lines between the shebang and the first #PBS line?
>>>>>
>>>>> That is also an option - what I am using at the moment is to use
>>>>> :no-expand as a code block specific header argument. But this raises the
>>>>> other question:
>>>>>
>>>>> Can I set the :no-expand in a properties block? As far as I understand,
>>>>> in the properties block I have the argument and the value - but what do
>>>>> I do with :noexpand?
>>>>>
>>>>> :PROPERTIES:
>>>>> :var: A=13
>>>>> :no-expand
>>>>> :END:
>>>>>
>>>>
>>>> You can just set it to "yes" or really any value you like (the value
>>>> will be ignored). I did however have to add "no-expand" to the list of
>>>> header argument names searched for in property blocks -- I just pushed
>>>> up a patch to this effect.
>>>>
>>>>>
>>>>>>
>>>>>> More generally, I wonder what a natural method would be to allow
>>>>>> unsetting of pre-set header arguments for local blocks or subtrees?
>>>>>> This may only apply to the :var header argument, as most others have a
>>>>>> default setting which can be actively set. If you have any ideas for a
>>>>>> natural syntax for such an operation I'd be happy to hear it.
>>>>>
>>>>> First solution (probably the easiest to implement) would be along the
>>>>> lines of the :no-expand header argument -
>>>>>
>>>>> :expand-var yes
>>>>> and
>>>>> :expand-var no
>>>>>
>>>>> This could possibly be expanded to
>>>>> :expand-var A B C
>>>>>
>>>>> which would expand only the variables A B and C
>>>>>
>>>>> One step further: one could define groups of variables, like
>>>>> :var-group X=A,B,C
>>>>> or a similar syntax
>>>>>
>>>>> and then
>>>>> :expand-var X
>>>>> would expand A B and C
>>>>>
>>>>> This all would not be real unset - but a possibility for unsetting would be
>>>>>
>>>>> :var B=
>>>>>
>>>>> or
>>>>>
>>>>> :var-unset B
>>>>>
>>>>> i.e. if no value is specified in :var, the variable will be removed
>>>>> (i.e. unset) - one could also use a null value (if it exists in elisp):
>>>>>
>>>>> :var B=(null)
>>>>>
>>>>
>>>> Thanks for the ideas,
>>>>
>>>> I think you're right that something along the lines of the above should
>>>> be the easiest to implement, however after reading these suggestions,
>>>> I'm thinking that more generally there are a couple of other header
>>>> arguments which could need to be unset, namely
>>>> - file
>>>> - dir
>>>> - session
>>>> - shebang
>>>> some of these (like session) accept a "none" value which has the effect
>>>> of un-setting the header argument.
>>>>
>>>> It would be nice to generalize whatever solution we apply across all
>>>> types of header argument (both for implementation and for user
>>>> simplicity).
>>>
>>> Some half thought-through suggestions. Sorry if this is a bit
>>> disorganized.
>
>>> I wonder whether we should be using Org property inheritance here. If it
>>> were possible to turn off property inheritance temporarily for the
>>> execution of the block, then it could be prevented from inheriting the
>>> header args that you don't want it to inherit. Perhaps babel could offer
>>> a :bind header argument, which specifies the values of lisp variables in
>>> a let-binding which encloses the src block execution?
>
>>
>> The whole logic in org is that, if I understand correctly, of the
>> smaller unit (e.g. file -> subtree -> ... -> code block) inheriting
>> properties, variables, ... from the next larger unit - introducing a
>> possibility to disable inheritance, would introduce a completely new
>> level of complexity.
>> I think that one should rather introduce a way of
>> unsetting e.g. variable values to have the same effect, but still
>> sticking with the whole inheritance logic.
>> I reslly think that it might be dangerous to open the possibility to
>> break this inheritance principle.
>
> Hi Rainer,
>
> Org already has a way to disable inheritance in general, and on a
> property-by-property basis. See
>
> http://orgmode.org/manual/Property-inheritance.html#Property-inheritance
>
> and the docstrings for the variable org-use-property-inheritance and the
> function org-entry-get.
>
> It seems that what you want to do can be described as disabling
> inheritance of the :var properties for a specific block.
Agreed - that would solve my problem.
> So I'm
> suggesting that it may be more parsimonious to do this with the existing
> Org inheritance mechanisms than to introduce new babel header arguments
> specifically for this purpose.
Agreed here.
>
>>
>>>
>>> #+header: :bind org-babel-use-property-inheritance nil
>>> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
>>> #$ -cwd
>>> #+end_src
>>>
>>> with a patch along these lines
>>>
>>> +(defvar org-babel-use-property-inheritance t
>>> + "When looking for org-babel header arguments in in-buffer
>>> + properties, this variable is passed as the INHERIT argument to
>>> + the function `org-enrty-get'")
>>> +
>>> (defvar org-file-properties)
>>> (defun org-babel-params-from-properties (&optional lang)
>>> "Retrieve parameters specified as properties.
>>> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
>>> (lambda (header-arg)
>>> (and (setq val
>>> (or (condition-case nil
>>> - (org-entry-get (point) header-arg t)
>>> + (org-entry-get (point) header-arg org-babel-use-property-inheritance)
>>> (error nil))
>>> (cdr (assoc header-arg org-file-properties))))
>>> (cons (intern (concat ":" header-arg))
>>>
>>>
>>> In fact, that might be more widely useful in Org -- it would offer a
>>> sort of 'subtree local variables', as an analog of buffer local
>>> variables.
>>
>> If I define a variable in a PROPERTIES block, it is only valid in the
>> subtree - so don't we have that already?
>
> Here I was talking about emacs-lisp variables being "local to a
> particular subtree"; as opposed to Org properties.
Sorry - misundeerstandeing on my side.
>
>>> Like any other babel variable, BIND could be set in a
>>> property drawer, but perhaps other subtree-specific Org operations such
>>> as export and tangling could honour BIND by enclosing their execution in
>>> the appropriate let binding? Variables bound by BIND in enclosing
>>> subtrees should be shadowed by those bound in more local subtrees, of
>>> course.
>>>
>>> On a related note, I wonder whether the #+BABEL line should be
>>> re-implemented so that it works via setting org-file-properties?
>>> I.e. made equivalent to a #+PROPERTIES line?
>>
>> Yes please - I was not even aware that they were gone
>
> They are not gone. By "re-implemented" I mean implemented in a different
> way from how they are currently implemented.
I was already worried that I missed something crucial.
>
>> - only surprised
>> that some things did not work any more as expected.
>>
>> So how can I now define multiple variables?
>
> I don't know :)
Could Eric help here?
>
>> in a properties drawer multiple :var does not work? Could you give a
>> simple example how to define variables A and B?
>
> Yes, I've always been a bit uncomfortable with this. As Eric says, Org
> properties are supposed to be a bit like a hash, with unique keys.
So based on this, I can only define a single variable per properties drawer?
>
>>
>> I think I am now completely confused.
>>
>>>
>>> Finally, a feature for babel power users could be to offer a hook
>>> function which allows modification of the source block data structure
>>> immediately prior to execution. In the babel code, source blocks are
>>> basically converted into an elisp data structure that tends to be called
>>> `info'. We could have org-babel-src-block-modification-hook each
>>> function of which would be passed the value of info and given the
>>> opportunity to change it just before execution. For anyone who's
>>> prepared to write elisp, that would permit a wide class of
>>> modifications, such as knocking out the :var variables.
>>>
>>> And this hook could be set at a subtree level by a BIND property...
>>
>> Sorry - now you have lost me.
>
>> All I suggested was a way to unset a variable ...
>
> I am also suggesting some possible ways to do that, while trying to
> avoid special-case solutions. The issue you raised initially was not how
> to unset variables, but rather how to prevent stuff getting inbetween
> the shebang and the torque options, but it has led to some interesting
> ideas. We should probably bear in mind that unsetting variables is
> really a hack in the context of your original problem. Even if we make
> it possible, what is the solution when we want the variables?
Correct in all regards - the best solution is the one you suggested in
your other email to enable multi-line "shebangs", or, as you used the
term, introduce a preamble, which is inserted directly after the
shebang, which can contain multiple lines.
Cheers,
Rainer
>
> Dan
>
>
>>
>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>> The simplest option would probably be to ensure that
>>>> setting any header argument to :none would remove all instances of that
>>>> header argument. The only problem there is cases like var, where you
>>>> might not want to remove all :var's. Maybe this could be expanded
>>>> s.t. :none could take arguments, e.g.
>>>>
>>>> :header :none(A, B)
>>>>
>>>> which would remove all instances of the "header" header argument whose
>>>> value is or is named "A" or "B"? Or does that look too funky?
>>>>
>>>>>
>>>>> But this raises another question of mine:
>>>>>
>>>>> I tried to use two :var headers in a properties block, but it only used
>>>>> the first - did I miss something here?
>>>>>
>>>>
>>>> Nope, it appears that property blocks (like a hash) assume that there is
>>>> only one instance of each key->value pair, so once it is satisfied it
>>>> will quit looking for more instances. Maybe the following alternative
>>>> will suffice
>>>>
>>>> Best -- Eric
>>>>
>>>> ** two vars in a properties block -- not possible
>>>> :PROPERTIES:
>>>> :var: test1=7
>>>> :var: test2=8
>>>> :END:
>>>>
>>>> #+begin_src emacs-lisp
>>>> (message "test1=%S test2=%S" test1 test2)
>>>> #+end_src
>>>>
>>>> results in Error
>>>> : let: Symbol's value as variable is void: test2
>>>>
>>>> *** an alternative
>>>> :PROPERTIES:
>>>> :var: tests=all-tests
>>>> :END:
>>>>
>>>> #+tblname: all-tests
>>>> - 7
>>>> - 8
>>>>
>>>> #+begin_src emacs-lisp :var eric=89
>>>> (message "test1=%S test2=%S" (first tests) (second tests))
>>>> #+end_src
>>>>
>>>> #+results:
>>>> : test1=7 test2=8
>>>>
>>>> _______________________________________________
>>>> Emacs-orgmode mailing list
>>>> Please use `Reply All' to send replies to the list.
>>>> Emacs-orgmode@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- --
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa
Tel: +33 - (0)9 53 10 27 44
Cell: +27 - (0)8 39 47 90 42
Fax (SA): +27 - (0)8 65 16 27 82
Fax (D) : +49 - (0)3 21 21 25 22 44
Fax (FR): +33 - (0)9 58 10 27 44
email: Rainer@krugs.de
Skype: RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VQjkACgkQoYgNqgF2egpVbgCfbcTWfs6tu6I2TvRqQRENXhcp
8wsAni2+iqm12hjRbQuCRixeYCC0nu7b
=60CG
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 12:19 ` Dan Davison
2011-02-11 12:58 ` Rainer M Krug
@ 2011-02-11 14:16 ` Eric Schulte
2011-02-11 14:45 ` Dan Davison
1 sibling, 1 reply; 26+ messages in thread
From: Eric Schulte @ 2011-02-11 14:16 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Rainer M Krug
Hi Dan,
Many interesting suggestions, but I don't see how any of them are
simpler (either conceptually or in terms of implementation) than
defining a way to "unset" a variable previously set at a higher level of
generality. Is it the concept or the syntax of the previous suggestions
that you find objectionable?
I thought that either the :remove or :unset options suggested by Rainer
seemed intuitive. I understand your point about not using a keyword,
and I agree (especially as our parsing is currently based on the
assumption that keywords are header arguments). So maybe the
following...
this would unset all variables
#+begin_src emacs-lisp :var unset
;; code
#+end_src
this would unset only the variable A
#+begin_src emacs-lisp :var unset(A)
;; code
#+end_src
approaching this from another direction, we could have an :unset header
argument, which takes as arguments the names of other header arguments
to unset. Could be used like this...
#+begin_src emacs-lisp :unset '(var noweb)
;; code
#+end_src
although it's not clear how to use such a construct to unset particular
variables...
So what do you think? Should we explore syntactic options, or is there
something wrong with the very idea of a way of unsetting previously
bound header arguments?
Thanks -- Eric
More Comments in-line below:
[...]
>>
>> It would be nice to generalize whatever solution we apply across all
>> types of header argument (both for implementation and for user
>> simplicity).
>
> Some half thought-through suggestions. Sorry if this is a bit
> disorganized.
>
> I wonder whether we should be using Org property inheritance here. If
> it were possible to turn off property inheritance temporarily for the
> execution of the block, then it could be prevented from inheriting the
> header args that you don't want it to inherit.
Turning off property inheritance would break inheritance of *all* types
of header argument (which is probably not desirable) and would not be
useful for default values set in e.g., org-babel-default-header-args.
Also, how is this simpler than unsetting header arguments?
> Perhaps babel could offer a :bind header argument, which specifies the
> values of lisp variables in a let-binding which encloses the src block
> execution?
>
hmm, that is certainly an interesting Idea, and (separate from this
discussion of the need to unset variables) may be very useful in some
contexts -- although changing the lexical scope during the execution of
a code block probably wouldn't be normal usage. In fact in many cases
this would have no effect because we explicitly ensure variables have
the value needed my our code, so often the user would end up with
situations like the following
;; babel code
(let ((some-org-variable 'user-desired-value))
;; more babel processing
;; ...
;; variable is about to be used
(let ((some-org-variable 'babel-default-value)) ; <- we set explicitly
;; code that uses `some-org-variable'
))
>
> #+header: :bind org-babel-use-property-inheritance nil
> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
> #$ -cwd
> #+end_src
>
> with a patch along these lines
>
> +(defvar org-babel-use-property-inheritance t
> + "When looking for org-babel header arguments in in-buffer
> + properties, this variable is passed as the INHERIT argument to
> + the function `org-enrty-get'")
> +
> (defvar org-file-properties)
> (defun org-babel-params-from-properties (&optional lang)
> "Retrieve parameters specified as properties.
> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
> (lambda (header-arg)
> (and (setq val
> (or (condition-case nil
> - (org-entry-get (point) header-arg t)
> + (org-entry-get (point) header-arg org-babel-use-property-inheritance)
> (error nil))
> (cdr (assoc header-arg org-file-properties))))
> (cons (intern (concat ":" header-arg))
>
So you dealt with the issue I noticed above by defining a separate
variable which the user *could* override with a `let'. This would work
but would require
- rewriting of our code to use custom babel versions of many emacs variables
- requiring users to know both the normal and babel names of these
variables to effectively modify them using this :bind header argument
Again, this seems much more complex than introducing a way to unset
header arguments.
[...]
>
> On a related note, I wonder whether the #+BABEL line should be
> re-implemented so that it works via setting org-file-properties?
> I.e. made equivalent to a #+PROPERTIES line?
>
Could we just remove #+Babel: lines entirely and use #+property: lines,
which I guess would mean reading in org-file-properties rather than
parsing #+Babel lines. I agree this sounds like a good idea.
>
> Finally, a feature for babel power users could be to offer a hook
> function which allows modification of the source block data structure
> immediately prior to execution. In the babel code, source blocks are
> basically converted into an elisp data structure that tends to be called
> `info'. We could have org-babel-src-block-modification-hook each
> function of which would be passed the value of info and given the
> opportunity to change it just before execution. For anyone who's
> prepared to write elisp, that would permit a wide class of
> modifications, such as knocking out the :var variables.
>
I agree that this sounds powerful, but it is certainly not simple. For
adding such complexity I would need to see a motivating example of where
this is needed. When would this be easier than simply using :no-expand
and writing a code block verbatim as desired?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 14:16 ` Eric Schulte
@ 2011-02-11 14:45 ` Dan Davison
2011-02-12 23:13 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-11 14:45 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode, Rainer M Krug
"Eric Schulte" <schulte.eric@gmail.com> writes:
> Hi Dan,
>
> Many interesting suggestions, but I don't see how any of them are
> simpler (either conceptually or in terms of implementation) than
> defining a way to "unset" a variable previously set at a higher level of
> generality. Is it the concept or the syntax of the previous suggestions
> that you find objectionable?
>
> I thought that either the :remove or :unset options suggested by Rainer
> seemed intuitive. I understand your point about not using a keyword,
> and I agree (especially as our parsing is currently based on the
> assumption that keywords are header arguments). So maybe the
> following...
>
> this would unset all variables
> #+begin_src emacs-lisp :var unset
> ;; code
> #+end_src
>
> this would unset only the variable A
> #+begin_src emacs-lisp :var unset(A)
> ;; code
> #+end_src
>
> approaching this from another direction, we could have an :unset header
> argument, which takes as arguments the names of other header arguments
> to unset. Could be used like this...
>
> #+begin_src emacs-lisp :unset '(var noweb)
> ;; code
> #+end_src
>
> although it's not clear how to use such a construct to unset particular
> variables...
>
> So what do you think? Should we explore syntactic options, or is there
> something wrong with the very idea of a way of unsetting previously
> bound header arguments?
I agree, the things I was talking about don't end up being simpler in
terms of usage for this case. My thinking was that variable unsetting
might be something that would be required fairly rarely, and so it might
be worth appropriate to support it as part of a more general/powerful
mechanism tied into Org properties, or even that hook.
Before we proceed with the variable unsetting, could someone provide a
motivating example, just to convince ourselves that the extra features
are justified? (The conclusion of another message was that the torque
script example was more a motivating example for shebang/preamble
processing than for variable unsetting.)
Dan
>
> Thanks -- Eric
>
> More Comments in-line below:
>
> [...]
>>>
>>> It would be nice to generalize whatever solution we apply across all
>>> types of header argument (both for implementation and for user
>>> simplicity).
>>
>> Some half thought-through suggestions. Sorry if this is a bit
>> disorganized.
>>
>> I wonder whether we should be using Org property inheritance here. If
>> it were possible to turn off property inheritance temporarily for the
>> execution of the block, then it could be prevented from inheriting the
>> header args that you don't want it to inherit.
>
> Turning off property inheritance would break inheritance of *all* types
> of header argument (which is probably not desirable) and would not be
> useful for default values set in e.g., org-babel-default-header-args.
>
> Also, how is this simpler than unsetting header arguments?
>
>> Perhaps babel could offer a :bind header argument, which specifies the
>> values of lisp variables in a let-binding which encloses the src block
>> execution?
>>
>
> hmm, that is certainly an interesting Idea, and (separate from this
> discussion of the need to unset variables) may be very useful in some
> contexts -- although changing the lexical scope during the execution of
> a code block probably wouldn't be normal usage. In fact in many cases
> this would have no effect because we explicitly ensure variables have
> the value needed my our code, so often the user would end up with
> situations like the following
>
> ;; babel code
> (let ((some-org-variable 'user-desired-value))
> ;; more babel processing
> ;; ...
> ;; variable is about to be used
> (let ((some-org-variable 'babel-default-value)) ; <- we set explicitly
> ;; code that uses `some-org-variable'
> ))
>
>>
>> #+header: :bind org-babel-use-property-inheritance nil
>> #+begin_src sh :tangle script.sh :shebang #!/bin/bash
>> #$ -cwd
>> #+end_src
>>
>> with a patch along these lines
>>
>> +(defvar org-babel-use-property-inheritance t
>> + "When looking for org-babel header arguments in in-buffer
>> + properties, this variable is passed as the INHERIT argument to
>> + the function `org-enrty-get'")
>> +
>> (defvar org-file-properties)
>> (defun org-babel-params-from-properties (&optional lang)
>> "Retrieve parameters specified as properties.
>> @@ -864,7 +870,7 @@ may be specified in the properties of the current outline entry."
>> (lambda (header-arg)
>> (and (setq val
>> (or (condition-case nil
>> - (org-entry-get (point) header-arg t)
>> + (org-entry-get (point) header-arg org-babel-use-property-inheritance)
>> (error nil))
>> (cdr (assoc header-arg org-file-properties))))
>> (cons (intern (concat ":" header-arg))
>>
>
> So you dealt with the issue I noticed above by defining a separate
> variable which the user *could* override with a `let'. This would work
> but would require
> - rewriting of our code to use custom babel versions of many emacs variables
> - requiring users to know both the normal and babel names of these
> variables to effectively modify them using this :bind header argument
>
> Again, this seems much more complex than introducing a way to unset
> header arguments.
>
> [...]
>>
>> On a related note, I wonder whether the #+BABEL line should be
>> re-implemented so that it works via setting org-file-properties?
>> I.e. made equivalent to a #+PROPERTIES line?
>>
>
> Could we just remove #+Babel: lines entirely and use #+property: lines,
> which I guess would mean reading in org-file-properties rather than
> parsing #+Babel lines. I agree this sounds like a good idea.
>
>>
>> Finally, a feature for babel power users could be to offer a hook
>> function which allows modification of the source block data structure
>> immediately prior to execution. In the babel code, source blocks are
>> basically converted into an elisp data structure that tends to be called
>> `info'. We could have org-babel-src-block-modification-hook each
>> function of which would be passed the value of info and given the
>> opportunity to change it just before execution. For anyone who's
>> prepared to write elisp, that would permit a wide class of
>> modifications, such as knocking out the :var variables.
>>
>
> I agree that this sounds powerful, but it is certainly not simple. For
> adding such complexity I would need to see a motivating example of where
> this is needed. When would this be easier than simply using :no-expand
> and writing a code block verbatim as desired?
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 13:49 ` Dan Davison
2011-02-11 13:56 ` Rainer M Krug
@ 2011-02-12 22:54 ` Eric Schulte
1 sibling, 0 replies; 26+ messages in thread
From: Eric Schulte @ 2011-02-12 22:54 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Rainer M Krug
Dan Davison <dandavison7@gmail.com> writes:
> [...]
>>> 2. It should be possible somehow to include the options together with
>>> the shebang, or to replace :shebang with a more general "preamble"
>>> concept. Or to make :shebang accept a code block as its value.
>>>
>>> --------------------------------------------
>>> #+BABEL: :var A=13
>>> #+BABEL: :var B=14
>>>
>>> #+header: :shebang #!/bin/bash #$ -cwd
>>> #+begin_src sh :tangle script.sh
>>> # empty
>>> #+end_src
>>> --------------------------------------------
>>
>> Similar to above - should work, but now the options for torque are
>> hidden in the shebang - which is not to nice, but should work - although
>> changing the options is not nearly as nice as if the options are in the
>> source block.
>
> It seems that we should be able to put the preamble lines in a src
> block. This works, but only after making an alteration to the sbe
> function (below) so that it will allow multiple line results. Maybe Eric
> will have some ideas here.
>
I'm happy for your patch below to be applied, although maybe replace
org-babel-table-truncate-at-newline with org-babel-trim, so that
leading/trailing newlines are still removed. It would be nice to retain
org-babel-table-truncate-at-newline if we could tell which evaluations
were headed for a variable -- although this behavior doesn't seem worth
the addition of a new argument to sbe.
>
> ---------------------------------------
> #+BABEL: :var A=13
> #+BABEL: :var B=14
>
> #+srcname: sheb
> #+begin_src sh :results output
> echo '#!/bin/bash'
> echo '#$ -cwd'
> #+end_src
>
> #+header: :shebang (sbe sheb)
> #+begin_src sh :tangle script.sh
> # empty
> #+end_src
> ---------------------------------------
>
>
> (setq source-block (symbol-name source-block)))
> - (org-babel-table-truncate-at-newline ;; org-table cells can't be multi-line
> (if (and source-block (> (length source-block) 0))
> (let ((params
> (eval `(org-babel-parse-header-arguments
> @@ -116,7 +115,7 @@ example above."
> ")")))))
> (org-babel-execute-src-block
> nil (list "emacs-lisp" "results" params) '((:results . "silent"))))
> - ""))))
> + "")))
>
>
> Dan
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 14:05 ` Rainer M Krug
@ 2011-02-12 23:12 ` Eric Schulte
2011-02-13 1:21 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Eric Schulte @ 2011-02-12 23:12 UTC (permalink / raw)
To: Rainer M Krug; +Cc: emacs-orgmode, Dan Davison
[...]
>> It seems that what you want to do can be described as disabling
>> inheritance of the :var properties for a specific block.
>
> Agreed - that would solve my problem.
>
>> So I'm suggesting that it may be more parsimonious to do this with
>> the existing Org inheritance mechanisms than to introduce new babel
>> header arguments specifically for this purpose.
>
> Agreed here.
>
If this is possible, then I'm all for it, however I do not think that it
is currently possible to "disinherit" specific properties. Note: do to
the way babel collects properties, I don't think that temporarily
changing the value of `org-use-property-inheritance' will be sufficient.
[...]
>>>
>>> So how can I now define multiple variables?
>>
>> I don't know :)
>
> Could Eric help here?
>
>>
>>> in a properties drawer multiple :var does not work? Could you give a
>>> simple example how to define variables A and B?
>>
>> Yes, I've always been a bit uncomfortable with this. As Eric says, Org
>> properties are supposed to be a bit like a hash, with unique keys.
>
> So based on this, I can only define a single variable per properties drawer?
>
I'm not sure how this should be solved. Would it be possible/desirable
to allow multiple settings of the same key in Org-mode properties? That
seems like it could be a destructive change across all of Org-mode.
Maybe we could extend the :var header argument to support the following
syntax...
#+begin_src emacs-lisp :var A=1 B=3
;; code
#+end_src
or
** two vars in a properties block
:PROPERTIES:
:var: test1=7 test2=8
:END:
That shouldn't be overly difficult, and should solve our requirements.
Sound good? -- Eric
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-11 14:45 ` Dan Davison
@ 2011-02-12 23:13 ` Eric Schulte
2011-02-13 1:38 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Eric Schulte @ 2011-02-12 23:13 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Rainer M Krug
[...]
>
> I agree, the things I was talking about don't end up being simpler in
> terms of usage for this case. My thinking was that variable unsetting
> might be something that would be required fairly rarely, and so it might
> be worth appropriate to support it as part of a more general/powerful
> mechanism tied into Org properties, or even that hook.
>
It does sound like if there were a way to disable inheritance for
certain properties for certain sub-trees of a document, then that would
be ideal -- although I can't imagine how such functionality would be
implemented. Can we think of an Org-wide syntax for disinheriting
specific properties?
>
> Before we proceed with the variable unsetting, could someone provide a
> motivating example, just to convince ourselves that the extra features
> are justified? (The conclusion of another message was that the torque
> script example was more a motivating example for shebang/preamble
> processing than for variable unsetting.)
>
Certainly.
1. taking Rainer's first example, lets say that you want a variable
specified for all but one code block in a file (maybe that one code
block is the source of the value of the variable). In this case it
would be much simpler to specify the variable file-wide, and then
unset the variable for that one code block.
2. say you want the same session for /nearly/ every code block in a
file.
3. same for :dir, :file, or :shebang...
So, in summary, I am all for a general org-mode wide solution for
disinheriting specific properties, however, if we are unable to find
such a solution then I would lean towards implementing this for Babel
specifically.
Best -- Eric
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-12 23:12 ` Eric Schulte
@ 2011-02-13 1:21 ` Dan Davison
2011-02-13 18:28 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-13 1:21 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode, Rainer M Krug
"Eric Schulte" <schulte.eric@gmail.com> writes:
> [...]
>>> It seems that what you want to do can be described as disabling
>>> inheritance of the :var properties for a specific block.
>>
>> Agreed - that would solve my problem.
>>
>>> So I'm suggesting that it may be more parsimonious to do this with
>>> the existing Org inheritance mechanisms than to introduce new babel
>>> header arguments specifically for this purpose.
>>
>> Agreed here.
>>
>
> If this is possible, then I'm all for it, however I do not think that it
> is currently possible to "disinherit" specific properties. Note: do to
> the way babel collects properties, I don't think that temporarily
> changing the value of `org-use-property-inheritance' will be sufficient.
>
> [...]
>>>>
>>>> So how can I now define multiple variables?
>>>
>>> I don't know :)
>>
>> Could Eric help here?
>>
>>>
>>>> in a properties drawer multiple :var does not work? Could you give a
>>>> simple example how to define variables A and B?
>>>
>>> Yes, I've always been a bit uncomfortable with this. As Eric says, Org
>>> properties are supposed to be a bit like a hash, with unique keys.
>>
>> So based on this, I can only define a single variable per properties drawer?
>>
>
> I'm not sure how this should be solved. Would it be possible/desirable
> to allow multiple settings of the same key in Org-mode properties? That
> seems like it could be a destructive change across all of Org-mode.
> Maybe we could extend the :var header argument to support the following
> syntax...
>
> #+begin_src emacs-lisp :var A=1 B=3
> ;; code
> #+end_src
>
> or
>
> ** two vars in a properties block
> :PROPERTIES:
> :var: test1=7 test2=8
> :END:
>
> That shouldn't be overly difficult, and should solve our requirements.
Yes, that looks good.
In the following Org file
---------------------------------------
#+property: :var a=1 b=2
* h1
:PROPERTIES:
:var: c=3
:END:
** h11
:PROPERTIES:
:var: d=4 e=5 b=7
:END:
#+begin_src sh :var f=6
# code here
#+end_src
---------------------------------------
if we follow programming languages by analogy then the behavior we
should aim for is for variables a,b,c,d,e to all be set in the src
block, with b having the value 7.
I've made a start on a patch to do that -- it involves treating :var
differently from other header args. Whereas normal property inheritance
searches up the tree until the specified property is encountered, my
patch searches up the tree to the root, collecting all the :var
assignments encountered.
So perhaps we should go for a solution involving both the new ":var a=1
b=2" syntax (to allow multiple :var in the same block), and the
pluralistic inheritance described above (to allow :var to be collected
from all levels in the hierarchy).
Dan
>
> Sound good? -- Eric
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-12 23:13 ` Eric Schulte
@ 2011-02-13 1:38 ` Dan Davison
2011-02-13 18:33 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-13 1:38 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode, Rainer M Krug
"Eric Schulte" <schulte.eric@gmail.com> writes:
> [...]
>>
>> I agree, the things I was talking about don't end up being simpler in
>> terms of usage for this case. My thinking was that variable unsetting
>> might be something that would be required fairly rarely, and so it might
>> be worth appropriate to support it as part of a more general/powerful
>> mechanism tied into Org properties, or even that hook.
>>
>
> It does sound like if there were a way to disable inheritance for
> certain properties for certain sub-trees of a document, then that would
> be ideal -- although I can't imagine how such functionality would be
> implemented. Can we think of an Org-wide syntax for disinheriting
> specific properties?
I'm not sure whether or how this fits it, but it's worth noting that Org
currently documents the following
,----
| org-entry-get-with-inheritance is a Lisp function in `org.el'.
|
| (org-entry-get-with-inheritance PROPERTY &optional LITERAL-NIL)
|
| Get entry property, and search higher levels if not present.
| The search will stop at the first ancestor which has the property defined.
| If the value found is "nil", return nil to show that the property
| should be considered as undefined (this is the meaning of nil here).
| However, if LITERAL-NIL is set, return the string value "nil" instead.
`----
so that seems to suggest ":var nil" as a way of knocking out all :var
assignments, but doesn't immediately suggest how to knock out on a
per-variable basis. :var a=nil ? (Which otherwise would look for a src
block named "nil")
>> Before we proceed with the variable unsetting, could someone provide a
>> motivating example, just to convince ourselves that the extra features
>> are justified? (The conclusion of another message was that the torque
>> script example was more a motivating example for shebang/preamble
>> processing than for variable unsetting.)
>>
>
> Certainly.
>
> 1. taking Rainer's first example, lets say that you want a variable
> specified for all but one code block in a file (maybe that one code
> block is the source of the value of the variable). In this case it
> would be much simpler to specify the variable file-wide, and then
> unset the variable for that one code block.
Agreed. It's not clean, but currently in this situation one could just
set the offending variable to some other value.
> 2. say you want the same session for /nearly/ every code block in a
> file.
> 3. same for :dir, :file, or :shebang...
I'd just note that some of these already have natural values that can be
used to "unset"
:session none
:dir .
:shebang ""
:file <not sure about this one, but maybe "none" should be used...>
Dan
>
>
> So, in summary, I am all for a general org-mode wide solution for
> disinheriting specific properties, however, if we are unable to find
> such a solution then I would lean towards implementing this for Babel
> specifically.
>
> Best -- Eric
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-13 1:21 ` Dan Davison
@ 2011-02-13 18:28 ` Eric Schulte
2011-02-13 21:38 ` Dan Davison
0 siblings, 1 reply; 26+ messages in thread
From: Eric Schulte @ 2011-02-13 18:28 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Rainer M Krug
[...]
>> Maybe we could extend the :var header argument to support the following
>> syntax...
>>
>> #+begin_src emacs-lisp :var A=1 B=3
>> ;; code
>> #+end_src
>>
>> or
>>
>> ** two vars in a properties block
>> :PROPERTIES:
>> :var: test1=7 test2=8
>> :END:
>>
>> That shouldn't be overly difficult, and should solve our requirements.
>
> Yes, that looks good.
>
> In the following Org file
>
> ---------------------------------------
> #+property: :var a=1 b=2
>
> * h1
> :PROPERTIES:
> :var: c=3
> :END:
> ** h11
> :PROPERTIES:
> :var: d=4 e=5 b=7
> :END:
>
> #+begin_src sh :var f=6
> # code here
> #+end_src
> ---------------------------------------
>
> if we follow programming languages by analogy then the behavior we
> should aim for is for variables a,b,c,d,e to all be set in the src
> block, with b having the value 7.
>
> I've made a start on a patch to do that -- it involves treating :var
> differently from other header args. Whereas normal property inheritance
> searches up the tree until the specified property is encountered, my
> patch searches up the tree to the root, collecting all the :var
> assignments encountered.
>
Maybe we should do this sort of exhaustive search for *all* header
argument types. Are there any header arguments aside from :var which
could possibly want to take multiple values collected at different
levels of inheritance? I suppose :results may also take multiple values
which could reasonably be collected across multiple levels of hierarchy.
>
> So perhaps we should go for a solution involving both the new ":var a=1
> b=2" syntax (to allow multiple :var in the same block), and the
> pluralistic inheritance described above (to allow :var to be collected
> from all levels in the hierarchy).
>
That sounds good to me. Is this code up in a repository somewhere, or
should be send patches back and forth?
Best -- Eric
>
> Dan
>
>
>
>>
>> Sound good? -- Eric
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Please use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-13 1:38 ` Dan Davison
@ 2011-02-13 18:33 ` Eric Schulte
0 siblings, 0 replies; 26+ messages in thread
From: Eric Schulte @ 2011-02-13 18:33 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode, Rainer M Krug
Dan Davison <dandavison7@gmail.com> writes:
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> [...]
>>>
>>> I agree, the things I was talking about don't end up being simpler in
>>> terms of usage for this case. My thinking was that variable unsetting
>>> might be something that would be required fairly rarely, and so it might
>>> be worth appropriate to support it as part of a more general/powerful
>>> mechanism tied into Org properties, or even that hook.
>>>
>>
>> It does sound like if there were a way to disable inheritance for
>> certain properties for certain sub-trees of a document, then that would
>> be ideal -- although I can't imagine how such functionality would be
>> implemented. Can we think of an Org-wide syntax for disinheriting
>> specific properties?
>
> I'm not sure whether or how this fits it, but it's worth noting that Org
> currently documents the following
>
> ,----
> | org-entry-get-with-inheritance is a Lisp function in `org.el'.
> |
> | (org-entry-get-with-inheritance PROPERTY &optional LITERAL-NIL)
> |
> | Get entry property, and search higher levels if not present.
> | The search will stop at the first ancestor which has the property defined.
> | If the value found is "nil", return nil to show that the property
> | should be considered as undefined (this is the meaning of nil here).
> | However, if LITERAL-NIL is set, return the string value "nil" instead.
> `----
>
> so that seems to suggest ":var nil" as a way of knocking out all :var
> assignments, but doesn't immediately suggest how to knock out on a
> per-variable basis. :var a=nil ? (Which otherwise would look for a src
> block named "nil")
>
But then (I believe) once we implement the multiple inheritance
mentioned in your other thread this would no longer work.
>
>>> Before we proceed with the variable unsetting, could someone provide a
>>> motivating example, just to convince ourselves that the extra features
>>> are justified? (The conclusion of another message was that the torque
>>> script example was more a motivating example for shebang/preamble
>>> processing than for variable unsetting.)
>>>
>>
>> Certainly.
>>
>> 1. taking Rainer's first example, lets say that you want a variable
>> specified for all but one code block in a file (maybe that one code
>> block is the source of the value of the variable). In this case it
>> would be much simpler to specify the variable file-wide, and then
>> unset the variable for that one code block.
>
> Agreed. It's not clean, but currently in this situation one could just
> set the offending variable to some other value.
>
>> 2. say you want the same session for /nearly/ every code block in a
>> file.
>> 3. same for :dir, :file, or :shebang...
>
> I'd just note that some of these already have natural values that can be
> used to "unset"
>
> :session none
> :dir .
> :shebang ""
>
> :file <not sure about this one, but maybe "none" should be used...>
>
So the question seems to be, do we pick some /magic/ values for :var and
:file, similar to "none" for sessions, or do we unify this unsetting
behavior into a single magic value that can be used to unset any header
argument. The later seems cleaner to me.
Best -- Eric
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-13 18:28 ` Eric Schulte
@ 2011-02-13 21:38 ` Dan Davison
2011-02-14 19:22 ` Eric Schulte
0 siblings, 1 reply; 26+ messages in thread
From: Dan Davison @ 2011-02-13 21:38 UTC (permalink / raw)
To: Eric Schulte; +Cc: emacs-orgmode
"Eric Schulte" <schulte.eric@gmail.com> writes:
> [...]
>>> Maybe we could extend the :var header argument to support the following
>>> syntax...
>>>
>>> #+begin_src emacs-lisp :var A=1 B=3
>>> ;; code
>>> #+end_src
>>>
>>> or
>>>
>>> ** two vars in a properties block
>>> :PROPERTIES:
>>> :var: test1=7 test2=8
>>> :END:
>>>
>>> That shouldn't be overly difficult, and should solve our requirements.
>>
>> Yes, that looks good.
>>
>> In the following Org file
>>
>> ---------------------------------------
>> #+property: :var a=1 b=2
>>
>> * h1
>> :PROPERTIES:
>> :var: c=3
>> :END:
>> ** h11
>> :PROPERTIES:
>> :var: d=4 e=5 b=7
>> :END:
>>
>> #+begin_src sh :var f=6
>> # code here
>> #+end_src
>> ---------------------------------------
>>
>> if we follow programming languages by analogy then the behavior we
>> should aim for is for variables a,b,c,d,e to all be set in the src
>> block, with b having the value 7.
>>
>> I've made a start on a patch to do that -- it involves treating :var
>> differently from other header args. Whereas normal property inheritance
>> searches up the tree until the specified property is encountered, my
>> patch searches up the tree to the root, collecting all the :var
>> assignments encountered.
>>
>
> Maybe we should do this sort of exhaustive search for *all* header
> argument types. Are there any header arguments aside from :var which
> could possibly want to take multiple values collected at different
> levels of inheritance? I suppose :results may also take multiple values
> which could reasonably be collected across multiple levels of hierarchy.
>
>>
>> So perhaps we should go for a solution involving both the new ":var a=1
>> b=2" syntax (to allow multiple :var in the same block), and the
>> pluralistic inheritance described above (to allow :var to be collected
>> from all levels in the hierarchy).
>>
>
> That sounds good to me. Is this code up in a repository somewhere, or
> should be send patches back and forth?
This is in branch ob-inherit at
https://github.com/dandavison/org-devel. I've given you write access to
the repo. The branch isn't ready to go yet, just a first
pass. Currently, with this file
-------------------------------------
#+property: var a=1
#+property: var b=2
* h1
:PROPERTIES:
:var: c=3
:END:
** h11
:PROPERTIES:
:var: b=4
:END:
#+begin_src sh :var d=5
# code here
#+end_src
-------------------------------------
C-c C-v C-v in the src block gives
---------------------------------
c=3
a=1
b=2
d=5
# code here
---------------------------------
(so b has the wrong value, but there will be more issues than just that)
Dan
>
> Best -- Eric
>
>>
>> Dan
>>
>>
>>
>>>
>>> Sound good? -- Eric
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Please use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [BABEL] "unset" :var definitions for subtree
2011-02-13 21:38 ` Dan Davison
@ 2011-02-14 19:22 ` Eric Schulte
0 siblings, 0 replies; 26+ messages in thread
From: Eric Schulte @ 2011-02-14 19:22 UTC (permalink / raw)
To: Dan Davison; +Cc: emacs-orgmode
[...]
>
> This is in branch ob-inherit at
> https://github.com/dandavison/org-devel. I've given you write access to
> the repo. The branch isn't ready to go yet, just a first
> pass. Currently, with this file
>
> -------------------------------------
> #+property: var a=1
> #+property: var b=2
>
> * h1
> :PROPERTIES:
> :var: c=3
> :END:
> ** h11
> :PROPERTIES:
> :var: b=4
> :END:
>
> #+begin_src sh :var d=5
> # code here
> #+end_src
> -------------------------------------
>
> C-c C-v C-v in the src block gives
>
> ---------------------------------
> c=3
> a=1
> b=2
> d=5
> # code here
> ---------------------------------
>
> (so b has the wrong value, but there will be more issues than just that)
>
> Dan
>
Fantastic, I'll try to dig in over the next couple of days.
Thanks -- Eric
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-02-14 19:23 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-02-07 15:12 [BABEL] "unset" :var definitions for subtree Rainer M Krug
2011-02-10 1:27 ` Eric Schulte
2011-02-10 8:33 ` Rainer M Krug
2011-02-10 16:48 ` Eric Schulte
2011-02-11 9:00 ` Rainer M Krug
2011-02-11 9:32 ` Dan Davison
2011-02-11 10:22 ` Rainer M Krug
2011-02-11 11:55 ` Dan Davison
2011-02-11 12:29 ` Rainer M Krug
2011-02-11 13:49 ` Dan Davison
2011-02-11 13:56 ` Rainer M Krug
2011-02-12 22:54 ` Eric Schulte
2011-02-11 12:19 ` Dan Davison
2011-02-11 12:58 ` Rainer M Krug
2011-02-11 13:41 ` Dan Davison
2011-02-11 14:05 ` Rainer M Krug
2011-02-12 23:12 ` Eric Schulte
2011-02-13 1:21 ` Dan Davison
2011-02-13 18:28 ` Eric Schulte
2011-02-13 21:38 ` Dan Davison
2011-02-14 19:22 ` Eric Schulte
2011-02-11 14:16 ` Eric Schulte
2011-02-11 14:45 ` Dan Davison
2011-02-12 23:13 ` Eric Schulte
2011-02-13 1:38 ` Dan Davison
2011-02-13 18:33 ` Eric Schulte
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).