From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darlan Cavalcante Moreira Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Mon, 24 Oct 2011 15:07:16 -0300 Message-ID: <4ea5a95b.059dec0a.606e.0c92@mx.google.com> References: <87pqhrih3s.fsf@gmail.com> <30891.1319141196@alphaville.dokosmarshall.org> <87fwinifqu.fsf@gmail.com> <32184.1319143892@alphaville.dokosmarshall.org> <87zkgvgxe7.fsf@gmail.com> <1405.1319147324@alphaville.dokosmarshall.org> <87zkgvfhra.fsf@gmail.com> <2127.1319148505@alphaville.dokosmarshall.org> <87vcrjfgt1.fsf@gmail.com> <80sjmmvm60.fsf@somewhere.org> <4EA129DB.4070006@christianmoe.com> <8762ji5jr6.fsf@gmail.com> <4EA1D4F9.5010302@christianmoe.com> <4ea1de9c.67b4ec0a.553d.122a@mx.google.com> <87aa8t10np.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from eggs.gnu.org ([140.186.70.92]:33802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIOvq-0001Fn-Cf for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 14:07:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIOvo-0000XJ-GQ for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 14:07:30 -0400 Received: from mail-gx0-f169.google.com ([209.85.161.169]:45775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIOvo-0000XE-9c for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 14:07:28 -0400 Received: by ggnh4 with SMTP id h4so7109727ggn.0 for ; Mon, 24 Oct 2011 11:07:27 -0700 (PDT) In-Reply-To: <87aa8t10np.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: Sebastien Vauban , emacs-orgmode@gnu.org, mail@christianmoe.com I didn't check the list for 3 days and this thread became a little hard to follow. So, forgive me if I'm "answering" the wrong E-Mail. I liked Christian's idea of using a single "var" property to tell babel which regular properties it should use as variables (ignoring any variable not defined). This would be enough for my use cases. On the other hand, some way to append values to a property, such as using some special keyword as I have suggested, could be a better solution in order to keep consistence if people want this feature for non-babel related properties. -- Darlan At Sat, 22 Oct 2011 09:53:25 -0600, Eric Schulte wrote: > > Darlan Cavalcante Moreira writes: > > > It's excellent that now babel understands multiple values in the "var" > > property (I was one of the people that wanted this), but "There Is One More > > Thing". > > > > Would it be feasible to inherit variables from parent sub-trees? > > Effectively, I'd like to append new values in lower level sub-trees, but > > AFAIK setting the var property in a sub-tree will still replace the value > > set in the parent sub-tree. > > > > Currently every new property specification entirely replaced previous > specifications with the same name. > > > > > That is, in the example below the level-2 sub-trees would not have the foo > > variable passed to babel. > > * Code with foo > > :PROPERTIES: > > :var: foo=1 > > :END: > > > > ** Code only with bar > > :PROPERTIES: > > :var: bar=2 > > :END: > > src_block > > ** Code only with baz > > :PROPERTIES: > > :var: baz=3 > > :END: > > src_block > > > > Maybe a special keyword, such as "inherit" (or "append") could be used to > > incorporate variables defined in the parent sub-tree, such that the example > > would become > > * Code with foo > > :PROPERTIES: > > :var: foo=1 > > :END: > > > > ** Code with foo and bar > > :PROPERTIES: > > :var: bar=2, inherit > > :END: > > src_block > > ** Code with foo and baz > > :PROPERTIES: > > :var: baz=3, inherit > > :END: > > src_block > > > > This should not affect global variables and "inherit" would inherit > > variables defined only in the parent sub-tree (unless it also contains the > > inherit keyword). > > > > As a use case scenario, suppose I need to perform simulations for a few > > different scenarios, each with small variations. This would allow me to > > define common variables for a scenario in a higher level sub-tree and more > > specific variables in the lower level sub-trees. > > > > This sounds somewhat similar to my suggestion in reply to Rainer's > email. > > Best -- Eric > > > > > -- > > Darlan Cavalcante > > > > > > At Fri, 21 Oct 2011 22:24:25 +0200, > > Christian Moe wrote: > >> > >> Hi, > >> > >> Yes, that works nicely, and should solve Rainer's problem. > >> I haven't been able to think of anything else that can't be handled by > >> properties. > >> > >> And I do think it's a good idea to winnow down the syntax a bit, even > >> if things break. I just like to grumble. > >> :-) > >> > >> Yours, > >> Christian > >> > >> On 10/21/11 7:37 PM, Eric Schulte wrote: > >> > Nice idea. This same issue with "var" arose when we first started > >> > allowing header arguments to be specified inside subtree properties. > >> > I've just implemented your suggestion so the following are now possible. > >> > > >> > #+PROPERTY: var foo=1, bar=2 > >> > #+PROPERTY: cache yes > >> > > >> > #+begin_src emacs-lisp > >> > (+ foo bar) > >> > #+end_src > >> > > >> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]: > >> > : 3 > >> > > >> > and > >> > > >> > #+begin_src emacs-lisp :var foo="this", bar="that" > >> > (concat foo " " bar) > >> > #+end_src > >> > > >> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]: > >> > : this that > >> > > >> > Thanks for the suggestion and I hope the above is a sufficient > >> > replacement for the now-missing #+BABEL: syntax. > >> > > >> > Cheers -- Eric > >> > >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/