[Orgmode] Re: [BABEL] "unset" :var definitions for subtree

[Dan Davison]

Rainer M Krug <address@hidden> writes:

> On 02/10/2011 05:48 PM, Eric Schulte wrote:
>> Rainer M Krug <address@hidden> writes:
>> 
>>> On 02/10/2011 02:27 AM, Eric Schulte wrote:
>>>> Rainer M Krug <address@hidden> 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