From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Moe Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Mon, 24 Oct 2011 13:37:29 +0200 Message-ID: <4EA54DF9.40307@christianmoe.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> <87fwil10o2.fsf@gmail.com> <4EA31457.3090800@christianmoe.com> Reply-To: mail@christianmoe.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIIo0-0003hg-7s for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 07:35:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIInx-0005ZH-UW for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 07:35:00 -0400 Received: from b1.hitrost.net ([91.185.211.67]:21333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIInx-0005Vo-LC for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 07:34:57 -0400 In-Reply-To: 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: Rainer M Krug Cc: Sebastien Vauban , emacs-orgmode@gnu.org > This all sounds very interesting, but I have problems understanding > the advantages - possibly because I only had one coffee this morning. It may not be feasible and the disadvantages may outnumber the advantages; we'll see. But having several coffees under my belt already, I'll argue my corner. :-) To recapitulate, I'm proposing that the values of (declared) variables for code blocks could be assigned from properties with the same names, so that: :PROPERTIES: :var: x=1, y=2, z=-3 :END: could also, and interchangeably, be written: :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: Here setting the `var' property with variable names, but without assignments, would declare that the variables are to be passed to the src block, and prompt Babel to look for the values in properties with the same names. I think some of the advantages should be clear. First: ------ It would easily let code blocks collect data from Org entry properties, without having to use lisp expressions or first collecting the properties in a dynamic block and then referencing the d.b. This would be nice particularly when your data is already in outline/property form. A second advantage: ------------------- It would allow a great deal of flexibility in passing variables according to position in the outline hierarchy. #+BEGIN_EXAMPLE * Some default settings :PROPERTIES: :x: 1 :y: 2 :z: -3 :var: x, y, z :END: ** For all cases where y=5 :PROPERTIES: :y: 5 :END: *** A case where x=1, y=5, z=-3 #+begin_src R (...) #+end_src *** A case where x=1, y=5, z=8: no need to specify y again #+begin_src R :var z=8 (...) #+end_src (z could alternatively have been specified as a property, same as y above) #+END_EXAMPLE This modular re-use of values from higher up in the outline, on any number of levels, should more than compensate for the loss of buffer-wide assignments with the #+BABEL header. With a single :var: property for passing arguments, on the other hand, this is not possible. You have to re-assign values to all three variables on each level. (Note: Eric's idea for accumulative properties, on the other hand, /would/ allow you to do this with a single :var: property.) > > #+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name)) > #+PROPERTY: SVNSTATE ( symbol-name (vc-state (or > (buffer-file-name) org-current-export-file))) > #+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) > org-current-export-file)) 'up-to-date) 0 13) > #+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz" > > > I think this syntax opens the door for dangerous typos - If you type e.g: > > #+PROPERTY: vat x=10 > > what would this be? it should have been > > #+PROPERTY: var x=10 > > but now? Now there would be a :vat: property with the value "x=10". It will not be passed to any code block because (as I imagine the scheme) any variables to be passed to a code block still need to be /declared/ with a :var: property or :var header argument, so it will not conflict with any `vat' variable you might have defined in the code. Instead, you will notice the typo when your code block results in an error message that x is missing, same as now. The result of misspelling var under my scheme would be the same as misspelling it now. > One could allow this syntax in the case that the variable has > been defined before, by using the var syntax: To simplify your example, you think this is permissible: #+PROPERTY: var x, y, z #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) but this is not: #+PROPERTY: x 1 #+PROPERTY: y (1+ 1) #+PROPERTY: z (- 0 3) #+PROPERTY: var x, y, z As I imagine the scheme, it wouldn't matter and the two are interchangeable. The `#+PROPERTY: y (1+ 1)' assignment, in and of itself, would only create a property :y: with the string value "(1+ 1)". When Babel began to execute a code block, it would first look up the value of the property :var: at point to see what variables to pass, and the order of the PROPERTY headers is not important. It would then look for the values of the properties :x:, :y: and :z: at point, and only then, knowing that these are variables for a code block, would it evaluate any lisp expressions in these values. A third advantage: ------------------ It would provide one way to solve your problem -- very long assignment expressions that are difficult to group on a line. It is not necessarily the best way to solve that specific problem, compared with the various options Eric came up with, such as #+PROPERTY+:. > > But this would not make > > #+PROPERTY+: > > redundant, but rather enhance it. Possibly; my solution only applies to the :var passed to a code block; there may be other property assignments that it would be good to be able to split over several lines. Also, I can certainly see the attraction of the analogous #+TBLFM+: -- though I'm fine with the existing `C-c '' solution for that, and would be equally happy to see that solution extended to solve your problem. Yours, Christian