From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Mon, 31 Oct 2011 12:53:09 -0600 Message-ID: <874nypkn6y.fsf@gmail.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> <4ea5a95b.059dec0a.606e.0c92@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKwz1-0001Is-RF for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 14:53:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RKwz0-0006u7-7v for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 14:53:19 -0400 Received: from mail-qw0-f41.google.com ([209.85.216.41]:51494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RKwyz-0006u3-Vq for emacs-orgmode@gnu.org; Mon, 31 Oct 2011 14:53:18 -0400 Received: by qadc11 with SMTP id c11so6214011qad.0 for ; Mon, 31 Oct 2011 11:53:17 -0700 (PDT) In-Reply-To: <4ea5a95b.059dec0a.606e.0c92@mx.google.com> (Darlan Cavalcante Moreira's message of "Mon, 24 Oct 2011 15:07:16 -0300") 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: Darlan Cavalcante Moreira Cc: Sebastien Vauban , emacs-orgmode@gnu.org, mail@christianmoe.com It is now possible to specify multi-line properties using a property block. This should make it more natural to specify many file-wide variables through properties. For example, #+begin_property var foo=1, bar=2, baz=3, qux=4 #+end_property #+begin_src emacs-lisp (+ foo bar baz qux) #+end_src #+results: : 10 Cheers -- Eric Darlan Cavalcante Moreira writes: > 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/ -- Eric Schulte http://cs.unm.edu/~eschulte/