Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines

[Christian Moe]

> 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