From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: [BABEL] "unset" :var definitions for subtree Date: Fri, 11 Feb 2011 09:32:00 +0000 Message-ID: References: <4D500BEC.1080300@gmail.com> <87bp2koeir.fsf@gmail.com> <4D53A2D2.2080300@gmail.com> <87r5bfn8dg.fsf@gmail.com> <4D54FAA0.3040309@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=59579 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnpMG-0003Zt-Ij for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:32:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnpME-00022u-Vd for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:32:08 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:64877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnpME-00022p-Nd for emacs-orgmode@gnu.org; Fri, 11 Feb 2011 04:32:06 -0500 Received: by wyj26 with SMTP id 26so2350113wyj.0 for ; Fri, 11 Feb 2011 01:32:05 -0800 (PST) In-Reply-To: <4D54FAA0.3040309@gmail.com> (Rainer M. Krug's message of "Fri, 11 Feb 2011 10:00:16 +0100") 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: Rainer M Krug Cc: emacs-orgmode Rainer M Krug writes: > 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. 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