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 10:00:16 +0100 Message-ID: <4D54FAA0.3040309@gmail.com> References: <4D500BEC.1080300@gmail.com> <87bp2koeir.fsf@gmail.com> <4D53A2D2.2080300@gmail.com> <87r5bfn8dg.fsf@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=47991 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pnosr-0000OB-3r for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:01:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pnosp-0005bs-Fk for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:01:45 -0500 Received: from mail-fx0-f41.google.com ([209.85.161.41]:48374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pnosp-0005bo-5b for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:01:43 -0500 Received: by fxm12 with SMTP id 12so2601424fxm.0 for ; Fri, 11 Feb 2011 01:01:42 -0800 (PST) In-Reply-To: <87r5bfn8dg.fsf@gmail.com> 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: Eric Schulte Cc: emacs-orgmode -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2011 05:48 PM, Eric Schulte wrote: > 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. 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-----