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

[Christian Moe <mail@christianmoe.com>]

Hi,

Eric Schulte wrote:
>

> I can think of three options for how to handle this situation.
>
> 1. If it turns out to be possible/desirable my preferred solution
> here would be to add general property support for appending values
> to properties when properties are over specified
(...)
>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the
> table formula helper making it more natural to edit such long
> property lines.
>
> 3. It may be possible to add syntax for extending #+PROPERTY:
> specifications across multiple lines, something like
>
> #+PROPERTY: var MAINVERSION=0,
 > #+PROPERTY+: SVNVERSION=(vc-working-revision (buffer-file-name)),
(...)

These are all interesting ideas, as was Darlan's alternative 
suggestion to Eric's suggestion (1), namely to use a special inherit 
argument.

I'd like to toss out a different idea, which I think is brilliant, but 
which may go down in flames once we've had a time to think it through. 
(And sorry if it's been proposed before; I came to Org just as 
Org-Babel was being stabilized.)

In short, let Babel assign to any declared variables of a src block 
the values of any properties at point with the same name. In other words:

- The :var header argument / :var: property could declare variables 
without assigning values, that is, you could have
`:var foo=1, bar, baz=3' to tell Babel that `bar' is a variable too.

- When a variable is declared, but no value assigned, Babel would look 
for a property (e.g. `:bar: 2') at point with the same name as the 
variable.

- If property inheritance is turned on, this means a variable can be 
specified at any level of the outline.

- If no further changes were made (such as the property accumulation 
Eric suggested), it would still be possible to /declare/ variables 
only at /one/ level of the outline besides in the code block and 
calls, since declarations all belong to the same `:var:' property. 
However, this approach would mean that declarations could be kept 
short and there would be a great deal of modularity in what values 
would be assigned.

Two examples follow.

---

Example 1.

Darlan suggested a special "inherit" argument, as follows:

* 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


Here is the same example under my proposal and with property 
inheritance turned on:

* Code with foo
   :PROPERTIES:
   :foo:      1
   :END:

** Code with foo and bar
    :PROPERTIES:
    :bar:      2
    :END:

    src_block :var foo, bar

** Code with foo and baz
    :PROPERTIES:
    :baz:      3
    :END:

    src_block :var foo, baz

Instead of declaring foo,bar and foo,baz in the src_blocks, we could 
define them once and for all at the top of the outline:

* Code with foo
   :PROPERTIES:
   :foo:      1
   :var: foo, bar, baz
   :END:

** Code with foo and bar
    :PROPERTIES:
    :bar:      2
    :END:

    src_block

** Code with foo and baz
    :PROPERTIES:
    :baz:      3
    :END:

    src_block

Under the first subhead, Org-babel would know (because the :var: 
property is inherited) to look for foo, bar and baz properties. It 
would find values for foo and bar (bar is defined as a property of 
that subhead, foo is inherited from the top-level heading). It would 
not find any value for baz. At this point, since no value could be 
assigned to baz, it would be ignored and would not be passed to the 
code block.

---

Example 2.

Let's take Rainer's problem :

On 10/22/11 5:52 PM, Eric Schulte wrote:
>>
>> #+BABEL: :var MAINVERSION=0
>> #+BABEL: :var SVNVERSION=(vc-working-revision (buffer-file-name))
>> #+BABEL: :var SVNSTATE=( symbol-name (vc-state (or (buffer-file-name) org-current-export-file)))
>> #+BABEL: :var SVNSTATENUM=(if (eq (vc-state (or (buffer-file-name) org-current-export-file)) 'up-to-date) 0 13)
>> #+BABEL: :var DISP_PACKAGE="seedDisp_0.4-13.tar.gz"
>>

Have a buffer-level property for all the long lines (sorry if my email 
client wraps these lines):

#+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"

Also, we have a buffer-level line declaring all these variables, and 
including MAINVERSION with the ordinary assignment. Thanks to last 
night's change, we can list them all on one line.

#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM, 
DISP_PACKAGE

I don't know what kind of code this example applies to, but let's 
imagine that we also have a header that resets one of these properties:

* Variant for main version 1
   :PROPERTIES:
   :MAINVERSION: 1
   :END:

...and below that, we finally have a code block, with a header that 
declares a variable locally:

#+HEADERS: :var somelocalvar="something or other"
#+BEGIN_SRC Perl
   while(...) {
      ...
   }
#+END_SRC

This should expand to something like:

#!/usr/bin/perl
use warnings;
my $MAINVERSION = 1;
my $SVNVERSION = "0.4.13";
my $SVNSTATE = "something or other"
my $SVNSTATENUM = 13;
my $DISP_PACKAGE = "seedDisp_0.4-13.tar.gz";
my $somelocalvar = "something or other";
while(...) {
    ...
}

---

OK, hopefully my idea is clear by now.

Could it be made to work?
Would it solve some problems?
Would it mess other things up even worse?

Yours,
Christian