From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [BABEL] "unset" :var definitions for subtree Date: Fri, 11 Feb 2011 15:05:45 +0100 Message-ID: <4D554239.1020701@gmail.com> References: <4D500BEC.1080300@gmail.com> <87bp2koeir.fsf@gmail.com> <4D53A2D2.2080300@gmail.com> <87r5bfn8dg.fsf@gmail.com> <4D553291.9090700@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=59211 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PntdB-0003Td-0Q for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:05:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pntd8-0000CV-Gu for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:05:52 -0500 Received: from mail-fx0-f41.google.com ([209.85.161.41]:49019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pntd8-0000C6-13 for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 09:05:50 -0500 Received: by fxm12 with SMTP id 12so2893744fxm.0 for ; Fri, 11 Feb 2011 06:05:49 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org 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 writes: > >> On 02/11/2011 01:19 PM, Dan Davison wrote: >>> "Eric Schulte" writes: >>> >>>> Rainer M Krug writes: >>>> >>>>> On 02/10/2011 02:27 AM, Eric Schulte wrote: >>>>>> Rainer M Krug 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-----