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

[Rainer M Krug]

Eric: Thanks - but for the moment I will go with Jambunathan's suggestion
and stick with the latest version before the removal of BABEL.

For the record, I created a local branch before the removal of BABEL and
used

git checkout MyBranch

to switch to this branch. So I can keep my local git repo up-to-date and
switch back to master if I want to.
Cheers,

Rainer


On Thu, Nov 3, 2011 at 7:51 PM, Jambunathan K wrote:

>
> Rainer - if he feels uncomfortable - can choose *not* to update his git
> repo and switch his local checkout to a historical version.
>
> > [1]  to see the info page evaluate (info "(elisp)File Local
> > Variables")
>
> A usage note for adding these variables without straining the brain.
>
> M-x add-file-local-variable RET
> M-x add-file-local-variable-prop-line RET
>
> These commands are documented here.
> (info "(emacs) Specifying File Variables")
> --
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Jambunathan K]

Rainer - if he feels uncomfortable - can choose *not* to update his git
repo and switch his local checkout to a historical version.

> [1]  to see the info page evaluate (info "(elisp)File Local
> Variables")

A usage note for adding these variables without straining the brain.

M-x add-file-local-variable RET
M-x add-file-local-variable-prop-line RET

These commands are documented here.
(info "(emacs) Specifying File Variables")
-- 

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

[Eric Schulte]

>> >
>> > In order to prevent confusion or needless argument: the path I
>> >think we should back off of is the committing of these changes to
>> >master - I think the work should be done in a branch and cooked
>> >thoroughly before merging it to master.
>> >
>>
>
> Partly agree here - I was bitten by the changes, and have suspended work on
> one project until this issue stabilizes - I do not want to change my files
> after each change.
>

Hi Rainer,

In a previous thread in which you were included I suggested a solution
which works now and will continue to work in the future no matter how
this issue is resolved.  That solution is to use a multi-line file local
variable [1] to customize the org-babel-default-header-args variable.  I
should have made a bigger deal of this solution when I posted it the
first time, my apologies.

In general I think we do a good job of not breaking functionality
without on this master branch, and I think that introducing a multitude
of branches would only serve to add confusion, reduce org-wide
cooperation, and ultimately only delay rather than somehow remove them.

Best -- Eric

Footnotes: 
[1]  to see the info page evaluate (info "(elisp)File Local Variables")

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Bastien]

Hi Brian,

Brian Wightman  writes:

> Given that a common recommendation for a bug fix is to 'try commit
> blah blah blah', would it make sense to have bug fixes go onto a
> 'maint' branch (as well as master), and new features / changed
> features stay on the master branch?  

Yes, this makes sense, and this has already been suggested.

The reason why I'm not using such a scheme is 1) pure laziness
and 2) the fact that the current git scheme is "good enough".

But it might not be good enough for long, and perhaps future
maintainers will not be as lazy as I am wrt this.

Thanks for the suggestion,

-- 
 Bastien

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

[Rainer M Krug]

On Wed, Nov 2, 2011 at 1:57 PM, Brian Wightman
wrote:

> On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte 
> wrote:
> > This is also after all the development repository, and while I do try
> > very hard never to break this head of this repository at the same time I
> > think it is an acceptable place to try out new functionality.
>
> Given that a common recommendation for a bug fix is to 'try commit
> blah blah blah', would it make sense to have bug fixes go onto a
> 'maint' branch (as well as master), and new features / changed
> features stay on the master branch?  At the time when 'master' is
> ready for a new official release, it could then be merged into 'maint'
> to create the next stable point for bug fixes.
>
> Adding features on the same branch as bug fixes, when 'official
> releases' are not made frequently seems to be a formula for
> frustration.
>

Added features are not that much of a problem, but changes which affect
backward compatibility are. But there were not many in the past that I am
aware of.

Cheers,

Rainer



> Thoughts?
>
> Brian
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Rainer M Krug]

On Wed, Nov 2, 2011 at 1:18 PM, Nicolas Goaziou  wrote:

> Hello,
>
> Rainer M Krug  writes:
>
> > Then one should possibly also think of merging #+LATEX into #+PROPERTY -
> > which I think would make it more consistent (and this is a serious
> > suggestion).
>
> Are you sure you're talking about the "#+LATEX:" keywords, allowing to
> insert LaTeX code only for the LaTeX exporter? If that's the case,
> I fail to see your point.
>
> > So: all file-wide properties, #+PROPERTIES is used.
>
> "#+PROPERTIES:" isn't really about file-wide properties, but only about
> properties applying to each headline in the buffer. It's
> a generalization of the property drawers. That's quite different,
> actually. For example, "#+TITLE:" is a file-wide property that doesn't
> belong to "#+PROPERTIES:".
>
> In other words, a property should belong to "#+PROPERTIES" if it may
> have different values for different sections.
>
>
>
I am now completely confused - but that is fine. I give up for now. Just
one question: could you, Eric, please give a summary, as soon as the
changes are fixed, on how I have to change my org-files so that they are
working again?

Thanks,

Rainer





> Regards,
>
> --
> Nicolas Goaziou
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Brian Wightman]

On Tue, Nov 1, 2011 at 10:17 AM, Eric Schulte  wrote:
> This is also after all the development repository, and while I do try
> very hard never to break this head of this repository at the same time I
> think it is an acceptable place to try out new functionality.

Given that a common recommendation for a bug fix is to 'try commit
blah blah blah', would it make sense to have bug fixes go onto a
'maint' branch (as well as master), and new features / changed
features stay on the master branch?  At the time when 'master' is
ready for a new official release, it could then be merged into 'maint'
to create the next stable point for bug fixes.

Adding features on the same branch as bug fixes, when 'official
releases' are not made frequently seems to be a formula for
frustration.

Thoughts?

Brian

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

[Nicolas Goaziou]

Hello,

Rainer M Krug  writes:

> Then one should possibly also think of merging #+LATEX into #+PROPERTY -
> which I think would make it more consistent (and this is a serious
> suggestion).

Are you sure you're talking about the "#+LATEX:" keywords, allowing to
insert LaTeX code only for the LaTeX exporter? If that's the case,
I fail to see your point.

> So: all file-wide properties, #+PROPERTIES is used.

"#+PROPERTIES:" isn't really about file-wide properties, but only about
properties applying to each headline in the buffer. It's
a generalization of the property drawers. That's quite different,
actually. For example, "#+TITLE:" is a file-wide property that doesn't
belong to "#+PROPERTIES:".

In other words, a property should belong to "#+PROPERTIES" if it may
have different values for different sections.


Regards,

-- 
Nicolas Goaziou

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

[Rainer M Krug]

On Tue, Nov 1, 2011 at 4:17 PM, Eric Schulte  wrote:

> Nick Dokos  writes:
>
> > Nick Dokos  wrote:
> >
> >
> >> Can we please back off this path?
> >
> > In order to prevent confusion or needless argument: the path I think we
> > should back off of is the committing of these changes to master - I think
> > the work should be done in a branch and cooked thoroughly before merging
> > it to master.
> >
>

Partly agree here - I was bitten by the changes, and have suspended work on
one project until this issue stabilizes - I do not want to change my files
after each change.


>
> I would agree that these changes should be happening in branches if the
> problems were technical, however the issues that need to be addressed
> are social issues of consensus, and for better or worse pushing changes
> to the master branch is the best way to alert all interested actors and
> begin the consensus-building process.
>
> If these changes had been pushed up to a branch they would be sitting
> happily in that branch with no-one noticing or objecting.  They had been
> discussed at length on list before their implementation and commitance,
> but this most recent round of discussion was caused by a push to the
> master branch.
>
>
You are definitely right about that - but it is kind of forcing the issue
on to users after telling them they should use git as org is very dynamic,
which is a risky business, as it might put users of - consider a new org
user who realizes that regularly things are changing which affect him, and
he / she has to change aspects of their org files. I would say it is a
double edged sword.

This is also after all the development repository, and while I do try
> very hard never to break this head of this repository at the same time I
> think it is an acceptable place to try out new functionality.
>

Again - true, but it is always recommended on the org-list to use the git
repo, as it contains all bug fixes.


> >
> > I did not mean to imply (although I think one could easily get that
> impression
> > from my mail) backing off the property implementation (despite my
> personal
> > reservations about that).
> >
>
> OK, good, because I *do* think that properties are a natural fit for
> specifying code block parameters.  The use of subtree properties has
> already proven itself, and file-wide properties are a natural extension
> (much more natural than the introduction of a #+BABEL: header argument).
>

Then one should possibly also think of merging #+LATEX into #+PROPERTY -
which I think would make it more consistent (and this is a serious
suggestion).
So: all file-wide properties, #+PROPERTIES is used.

What would be really important, is to have one page on worg, on which this
process is documented - i.e. how files need to be changed, to be used with
which version of org. I definitely have no idea, how I have to modify my
files at the moment (there was the discussion abour source_name, name, ...
and then the #+PROPERTY - I hope I haven't missed anything?). As I said - I
have the luck, that I can wait until it stabilizes (at least I hope) - but
a regularly updated summary with changes would be very welcome (and I guess
I can speak for many org users).

Even if this step is painful for many (especially the ones not to familiar
with the inner workings of org and babel (this definitely includes me)), I
am sure that the best solution will be found (hopefully soon) and we will
have a better and stronger org-mode at hand.

Cheers,

Rainer


> While there is certainly some pain in this process I think it is nailing
> down both the needs for code block properties as well as the scope of
> what is and is not desirable functionality for properties in general.
>
> Best -- Eric
>
> >
> > Nick
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Eric Schulte]

Nick Dokos  writes:

> Nick Dokos  wrote:
>
>
>> Can we please back off this path? 
>
> In order to prevent confusion or needless argument: the path I think we
> should back off of is the committing of these changes to master - I think
> the work should be done in a branch and cooked thoroughly before merging
> it to master.
>

I would agree that these changes should be happening in branches if the
problems were technical, however the issues that need to be addressed
are social issues of consensus, and for better or worse pushing changes
to the master branch is the best way to alert all interested actors and
begin the consensus-building process.

If these changes had been pushed up to a branch they would be sitting
happily in that branch with no-one noticing or objecting.  They had been
discussed at length on list before their implementation and commitance,
but this most recent round of discussion was caused by a push to the
master branch.

This is also after all the development repository, and while I do try
very hard never to break this head of this repository at the same time I
think it is an acceptable place to try out new functionality.

>
> I did not mean to imply (although I think one could easily get that impression
> from my mail) backing off the property implementation (despite my personal
> reservations about that).
>

OK, good, because I *do* think that properties are a natural fit for
specifying code block parameters.  The use of subtree properties has
already proven itself, and file-wide properties are a natural extension
(much more natural than the introduction of a #+BABEL: header argument).

While there is certainly some pain in this process I think it is nailing
down both the needs for code block properties as well as the scope of
what is and is not desirable functionality for properties in general.

Best -- Eric

>
> Nick
>
>
>
>
>
>
>
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Nick Dokos  wrote:


> Can we please back off this path? 

In order to prevent confusion or needless argument: the path I think we
should back off of is the committing of these changes to master - I think
the work should be done in a branch and cooked thoroughly before merging
it to master.

I did not mean to imply (although I think one could easily get that impression
from my mail) backing off the property implementation (despite my personal
reservations about that).

Nick

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

[Nick Dokos]

Eric Schulte  wrote:

> My concerns with respect to a property drawer solution are two fold.
> 
> 1) In the same way that #+PROPERTY: assumes its value will live on a
>single line, property drawers assume that their values will live on a
>single line.  I don't see how it will be easier to fold multi-line
>properties into drawers than outside of drawers.
> 
> 2) It is not possible to specify file-wide properties with drawers,
>unlike with property lines.
> 
> Thanks -- Eric
> 

I felt uneasy about #+begin_property, but I could not articulate
my unease until first Nicolas and then Samuel expressed some of their
concerns.

But it seemed to me from the beginning that properties were *not* the
right fit for babel whole-file args and I'm more convinced than ever
that this is the *wrong* direction: it conflates different concepts
and it forces changes in a well established area in order to satisfy
the concerns of the other area.

Can we please back off this path? The changes are big, they affect
users' everyday work and it is not clear where they are going to end up.
Let's revert the changes to master, establish a branch, and do all this
experimentation in a branch. When it is thoroughly cooked to most
people's satisfaction, it can be merged into master. That way, people
can continue their daily work, without having to worry about changing
their files to satisfy the new changes.

Git provided exceptionally flexible branching: let's use it.

My two cents,
Nick

> Samuel Wales  writes:
> 
> > Hi Eric,
> >
> > Properties can be specified in the properties drawer.  But
> > multiple-line ones cannot at present (at least not without serializing the 
> > way
> > multiple-line macros are serialized).
> >
> > Therefore you propose new syntax for multiple-line properties.
> >
> > I propose that allowing the properties drawer to handle multiple-line
> > properties might have 3 advantages over adding block syntax.
> >
> > 1: If you want a single-line property, you have a choice.  If you want
> > a multiple-line
> > property, you have to use a block.  That seems inconsistent.
> >
> > 2: Some people would probably have use for multiple-line properties, such
> > as in org-contacts.  Doesn't have to be Babel.  People are used to the
> > properties drawer.  Also, external parsers are.
> >
> > 3: Nic objects to blocks without discussing them first.
> >
> > Perhaps upgrading properties drawer will satisfy that objection /and/ be
> > consistent /and/ allow further uses in Org.
> >
> > This all presumes we're sticking with properties for Babel.
> >
> > Samuel
> >
> > -- 
> > The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> > ===
> > Bigotry against people with serious diseases is still bigotry.
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/
> 

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

[Eric Schulte]

My concerns with respect to a property drawer solution are two fold.

1) In the same way that #+PROPERTY: assumes its value will live on a
   single line, property drawers assume that their values will live on a
   single line.  I don't see how it will be easier to fold multi-line
   properties into drawers than outside of drawers.

2) It is not possible to specify file-wide properties with drawers,
   unlike with property lines.

Thanks -- Eric

Samuel Wales  writes:

> Hi Eric,
>
> Properties can be specified in the properties drawer.  But
> multiple-line ones cannot at present (at least not without serializing the way
> multiple-line macros are serialized).
>
> Therefore you propose new syntax for multiple-line properties.
>
> I propose that allowing the properties drawer to handle multiple-line
> properties might have 3 advantages over adding block syntax.
>
> 1: If you want a single-line property, you have a choice.  If you want
> a multiple-line
> property, you have to use a block.  That seems inconsistent.
>
> 2: Some people would probably have use for multiple-line properties, such
> as in org-contacts.  Doesn't have to be Babel.  People are used to the
> properties drawer.  Also, external parsers are.
>
> 3: Nic objects to blocks without discussing them first.
>
> Perhaps upgrading properties drawer will satisfy that objection /and/ be
> consistent /and/ allow further uses in Org.
>
> This all presumes we're sticking with properties for Babel.
>
> Samuel
>
> -- 
> The Kafka Pandemic: http://thekafkapandemic.blogspot.com
> ===
> Bigotry against people with serious diseases is still bigotry.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Samuel Wales]

Hi Eric,

Properties can be specified in the properties drawer.  But
multiple-line ones cannot at present (at least not without serializing the way
multiple-line macros are serialized).

Therefore you propose new syntax for multiple-line properties.

I propose that allowing the properties drawer to handle multiple-line
properties might have 3 advantages over adding block syntax.

1: If you want a single-line property, you have a choice.  If you want
a multiple-line
property, you have to use a block.  That seems inconsistent.

2: Some people would probably have use for multiple-line properties, such
as in org-contacts.  Doesn't have to be Babel.  People are used to the
properties drawer.  Also, external parsers are.

3: Nic objects to blocks without discussing them first.

Perhaps upgrading properties drawer will satisfy that objection /and/ be
consistent /and/ allow further uses in Org.

This all presumes we're sticking with properties for Babel.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.



-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

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

[Samuel Wales]

On 2011-10-31, Eric Schulte  wrote:
> 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,

Could this be changed to work using the property drawer?

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

[Eric Schulte]

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/

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

[Eric Schulte]

"Sebastien Vauban"  writes:

> Hi Eric,
>
> Eric Schulte wrote:
>>> I think that makes sense.
>>>
>>> While thinking about all of this, and working in real-life documents, I just
>>> came back to a suggestion which I made some time ago. It goes about this
>>> enhancement:
>>>
>>> Would it be possible to specify "buffer-wide language specific" header
>>> arguments?
>>
>> Yes, this is already possible.  You can customize the
>> org-babel-default-header-args:lang variable (where "lang" is the source
>> name) as a file local variable.
>>

Hi Seb,  ^
 |
I just wanted to make sure you saw the above solution for specifying
file-wide language-specific header arguments.  Emacs' support for buffer
local variables makes this fairly easy to implement.  In fact buffer
local variables could also be used to specify multi-langauge file-wide
header arguments using the `org-babel-default-header-args' variable.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> I think that makes sense.
>>
>> While thinking about all of this, and working in real-life documents, I just
>> came back to a suggestion which I made some time ago. It goes about this
>> enhancement:
>>
>> Would it be possible to specify "buffer-wide language specific" header
>> arguments?
>
> Yes, this is already possible.  You can customize the
> org-babel-default-header-args:lang variable (where "lang" is the source
> name) as a file local variable.
>
>> That is, be able to say:
>>
>> "In this document, I want to:
>> - tangle all my .sql chunks, but no other;
>> - eval all the elisp chunks with query, but no other."
>>
>> Something we could write quite easily along the lines:
>>
>> #+PROPERTY:   tangle no
>> #+PROPERTY:   eval never
>> #+PROPERTY[SQL]:  tangle yes
>> #+PROPERTY[EMACS-LISP]:   eval query
>>
>> (the syntax used here is just a draft sample!)
>>
>
> I do not think we can customize the PROPERTY syntax as is exists outside
> of Babel.  The goal here was to piggy-back on top of rather than co-opt
> regular Org-mode syntax.

I understand that argument.

It's just that the current solution is not optimal (among others) for
documents mixing R and shell code: you don't want your "session" property to
be common between both languages (shell code sent to your R terminal, or
vice-versa).

But it's nice this case is already handled in a more generic way than on the
code blocks themselves, and I can live with that. Thanks again for your help.

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Eric Schulte]

> I think that makes sense.
>
> While thinking about all of this, and working in real-life documents, I just
> came back to a suggestion which I made some time ago. It goes about this
> enhancement:
>
> Would it be possible to specify "buffer-wide language specific" header
> arguments?
>

Yes, this is already possible.  You can customize the
org-babel-default-header-args:lang variable (where "lang" is the source
name) as a file local variable.

>
> That is, be able to say:
>
> "In this document, I want to:
> - tangle all my .sql chunks, but no other;
> - eval all the elisp chunks with query, but no other."
>
> Something we could write quite easily along the lines:
>
> #+PROPERTY:   tangle no
> #+PROPERTY:   eval never
> #+PROPERTY[SQL]:  tangle yes
> #+PROPERTY[EMACS-LISP]:   eval query
>
> (the syntax used here is just a draft sample!)
>

I do not think we can customize the PROPERTY syntax as is exists outside
of Babel.  The goal here was to piggy-back on top of rather than co-opt
regular Org-mode syntax.

Best -- Eric

>
> What do you think about this feature? If you feel it can be something
> interesting to have, this is surely to incorporate in the current syntax
> debate. If not... never mind.
>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Rainer M Krug]

On Tue, Oct 25, 2011 at 12:31 PM, Sebastien Vauban <
wxhgmqzgw...@spammotel.com> wrote:

> Hi Rainer,
>
> Rainer M Krug wrote:
> >> While thinking about all of this, and working in real-life documents, I
> >> just
> >> came back to a suggestion which I made some time ago. It goes about this
> >> enhancement:
> >>
> >>Would it be possible to specify "buffer-wide language specific"
> header
> >>arguments?
> >>
> >> That is, be able to say:
> >>
> >>"In this document, I want to:
> >>- tangle all my .sql chunks, but no other;
> >>- eval all the elisp chunks with query, but no other."
> >>
> >> Something we could write quite easily along the lines:
> >>
> >>#+PROPERTY:   tangle no
> >>#+PROPERTY:   eval never
> >>#+PROPERTY[SQL]:  tangle yes
> >>#+PROPERTY[EMACS-LISP]:   eval query
> >>
> >>(the syntax used here is just a draft sample!)
> >>
> >> What do you think about this feature? If you feel it can be something
> >> interesting to have, this is surely to incorporate in the current syntax
> >> debate. If not... never mind.
> >
> > I am not Eric, but I think that would be a good idea.
>
> Thanks for your comments.
>
> > Bu there needs to be a way of specifying more then one property, either
> > by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: .
> > Thinking about it, it should be possible without the +:
> >
> > #+PROPERTY[R]: tangle no
> > #+PROPERTY[R]: export both
>
> Yes, no need for a "+" here, as the lines do target different properties
> (in
> this case, "tangle" and "export").
>
> > The more I see it, the more I like it - also the []
>
> In fact, the lines without any language specification would be, at least
> semantically, equivalent to something like this:
>
>  #+PROPERTY[*]:tangle no
>  #+PROPERTY[*]:eval never
>

So

#+PROPERTY followed by square brackets, means properties for source blocks
of a given language, and [*] is the default and can be omitted.

Two ideas: [R,sh], i.e. specifying a list of languages in the brackets could
be useful, as well as wildcards like [dit*]? The latter less usefull, but
for consistency?

Additionally: it would be nice, if one could define a set of properties, and
then recall them for certain blocks.

e.g:

#+PROPERTY[R:set1]: tangle no
#+PROPERTY[R:set1]: eval never

#+PROPERTY[R:set2]: tangle yes
#+PROPERTY[R:set2]: export both

#+src_begin R :set set1
  cat(1)
#+end

would have the first set of properties (tangle no and eval never), where

#+src_begin R :set set2
  cat(1)
#+end

would have the second set of properties (tangle no and eval never)

Might be a good addition?

Cheers,


Rainer


> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Sebastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
>> While thinking about all of this, and working in real-life documents, I
>> just
>> came back to a suggestion which I made some time ago. It goes about this
>> enhancement:
>>
>>Would it be possible to specify "buffer-wide language specific" header
>>arguments?
>>
>> That is, be able to say:
>>
>>"In this document, I want to:
>>- tangle all my .sql chunks, but no other;
>>- eval all the elisp chunks with query, but no other."
>>
>> Something we could write quite easily along the lines:
>>
>>#+PROPERTY:   tangle no
>>#+PROPERTY:   eval never
>>#+PROPERTY[SQL]:  tangle yes
>>#+PROPERTY[EMACS-LISP]:   eval query
>>
>>(the syntax used here is just a draft sample!)
>>
>> What do you think about this feature? If you feel it can be something
>> interesting to have, this is surely to incorporate in the current syntax
>> debate. If not... never mind.
>
> I am not Eric, but I think that would be a good idea.

Thanks for your comments.

> Bu there needs to be a way of specifying more then one property, either
> by #+PROPERTY+: or by any other way -I acually luike the #+PROPERTY+: .
> Thinking about it, it should be possible without the +:
>
> #+PROPERTY[R]: tangle no
> #+PROPERTY[R]: export both

Yes, no need for a "+" here, as the lines do target different properties (in
this case, "tangle" and "export").

> The more I see it, the more I like it - also the []

In fact, the lines without any language specification would be, at least
semantically, equivalent to something like this:

  #+PROPERTY[*]:tangle no
  #+PROPERTY[*]:eval never

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Rainer M Krug]

On Tue, Oct 25, 2011 at 11:35 AM, Sebastien Vauban <
wxhgmqzgw...@spammotel.com> wrote:

> Hi Eric,
>
> Eric Schulte wrote:
> >> #+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)
> >>
> >> which would look horrible in one line and a nightmare to edit.
> >
> > 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 rather than simply
> >replacing the value.  Perhaps this could be done with a variable like
> >org-accumulating-properties which could hold a list of those
> >properties which should accumulate values rather than overwriting
> >them.
> >
> > 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: 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),
> >
> >FWIW I would like to have a similar extender for #+TBLFM: lines.
> >Actually this choice may be my preferred solution.
> >
> > What do you think?
>
> I think that makes sense.
>
> While thinking about all of this, and working in real-life documents, I
> just
> came back to a suggestion which I made some time ago. It goes about this
> enhancement:
>
>Would it be possible to specify "buffer-wide language specific" header
>arguments?
>
> That is, be able to say:
>
>"In this document, I want to:
>- tangle all my .sql chunks, but no other;
>- eval all the elisp chunks with query, but no other."
>
> Something we could write quite easily along the lines:
>
>#+PROPERTY:   tangle no
>#+PROPERTY:   eval never
>#+PROPERTY[SQL]:  tangle yes
>#+PROPERTY[EMACS-LISP]:   eval query
>
>(the syntax used here is just a draft sample!)
>
> What do you think about this feature? If you feel it can be something
> interesting to have, this is surely to incorporate in the current syntax
> debate. If not... never mind.
>

I am not Eric, but I think that would be a good idea. Bu there needs to be a
way of specifying more then one property, either by #+PROPERTY+: or by any
other way -I acually luike the #+PROPERTY+: .
Thinking about it, it should be possible without the +:

#+PROPERTY[R]: tangle no
#+PROPERTY[R]: export both

The more I see it, the more I like it - also the []

Cheers,

Rainer


> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> #+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)
>>
>> which would look horrible in one line and a nightmare to edit.
>
> 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 rather than simply
>replacing the value.  Perhaps this could be done with a variable like
>org-accumulating-properties which could hold a list of those
>properties which should accumulate values rather than overwriting
>them.
>
> 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: 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),
>
>FWIW I would like to have a similar extender for #+TBLFM: lines.
>Actually this choice may be my preferred solution.
>
> What do you think?

I think that makes sense.

While thinking about all of this, and working in real-life documents, I just
came back to a suggestion which I made some time ago. It goes about this
enhancement:

Would it be possible to specify "buffer-wide language specific" header
arguments?

That is, be able to say:

"In this document, I want to:
- tangle all my .sql chunks, but no other;
- eval all the elisp chunks with query, but no other."

Something we could write quite easily along the lines:

#+PROPERTY:   tangle no
#+PROPERTY:   eval never
#+PROPERTY[SQL]:  tangle yes
#+PROPERTY[EMACS-LISP]:   eval query

(the syntax used here is just a draft sample!)

What do you think about this feature? If you feel it can be something
interesting to have, this is surely to incorporate in the current syntax
debate. If not... never mind.

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Darlan Cavalcante Moreira]

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/

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

[Nicolas Goaziou]

Hello,

Christian Moe  writes:

> But you're right, property inheritance is not on by default and
> I forgot to mention that this time around. (I think I did mention it
> in the previous long message where I presented the idea.)

AFAIK, Babel has always searched its properties with inheritance on,
independently on user configuration. Thus, it doesn't matter much in
that case.

Regard,

-- 
Nicolas Goaziou

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

[Christian Moe]

On 10/24/11 2:11 PM, Sebastien Vauban wrote:
(...)


But I just have a comment on your second advantage, something that can render
your example inefficient: inheritance is not on by default, and you need to
enable if for *specific properties*.


You can set `org-use-property-inheritance' to t, to make all 
properties inheritable, or you can set it to a list to enable specific 
properties. I suppose you meant that the former would be a bad idea. 
(And it could be, depending on your working habits, file size, outline 
nesting depth and the speed of your machine.)


But you're right, property inheritance is not on by default and I 
forgot to mention that this time around. (I think I did mention it in 
the previous long message where I presented the idea.)



Make it on by default would be a very bad idea -- just think at examples of
the mails sent through Org-mime: what about setting a Cc or To somewhere and
inheriting that in all the file/subtree/etc. May be scary or inefficient
performance-wise?

Anyway, setting inheritance of properties to on, means you should declare the
behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you
say that "var: x, y, z" does that too (then you've two things in one shot --
why not?).


Yes, if my suggestion becomes reality, this could be a useful refinement.

Yours,
Christian

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

[Sebastien Vauban]

Hi all,

Christian Moe wrote:
>> This all sounds very interesting, but I have problems understanding
>> the advantages - possibly because I only had one coffee this morning.
>
> I think some of the advantages should be clear.
>
> 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.)

I think discussing all of this is beneficial and can lead to very interesting
solutions.

But I just have a comment on your second advantage, something that can render
your example inefficient: inheritance is not on by default, and you need to
enable if for *specific properties*.

Make it on by default would be a very bad idea -- just think at examples of
the mails sent through Org-mime: what about setting a Cc or To somewhere and
inheriting that in all the file/subtree/etc. May be scary or inefficient
performance-wise?

Anyway, setting inheritance of properties to on, means you should declare the
behavior for vars x, y and z, ie declaring it 3 times... Except, maybe, if you
say that "var: x, y, z" does that too (then you've two things in one shot --
why not?).

Best regards,
  Seb

-- 
Sebastien Vauban

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, an

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

[Rainer M Krug]

On Sat, Oct 22, 2011 at 9:07 PM, Christian Moe wrote:

> 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.



This all sounds very interesting, but I have problems understanding the
advantages - possibly because I only had one coffee this morning. In
addition see further down:

SNIP


> 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"
>
>
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? One could allow this syntax in the case that the variable has been
defined before, by using the var syntax:

so

#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM,
DISP_PACKAGE
#+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"

should be OK, as SVNVERSION is already defined, but

#+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"
#+PROPERTY: var MAINVERSION=0, SVNVERSION, SVNSTATE, SVNSTATENUM,
DISP_PACKAGE

not, as the variables are only defined later.


But this would not make

#+PROPERTY+:

redundant, but rather enhance it.

Cheers,

Rainer

Cheers,

Rainer



SNIP


> Yours,
> Christian
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Rainer M Krug]

On Sat, Oct 22, 2011 at 5:52 PM, Eric Schulte wrote:

> >
> > Just to add to it: at the moment I have e.g:
> >
> > #+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"
> >
> > which would look horrible in one line and a nightmare to edit.
> >
> > Any suggestions how this cold be changed?
> >
>
> Hmm, I don't see any easy solution for the above.  I'm sorry to have
> removed this functionality.
>
> 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 rather than simply
>   replacing the value.  Perhaps this could be done with a variable like
>   org-accumulating-properties which could hold a list of those
>   properties which should accumulate values rather than overwriting
>   them.
>

Should work, but will add an additional level of complexity which I think is
avoidable.


>
> 2. Adding a "#+PROPERTY:" line authoring helper similar to the table
>   formula helper making it more natural to edit such long property
>   lines.
>

I think this might be to complicated


>
> 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)),
>   #+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"
>
>   FWIW I would like to have a similar extender for #+TBLFM: lines.
>   Actually this choice may be my preferred solution.
>

I like that suggestion - This would add an option, if inheritance for
subtrees is incorporated for #+PROPERTY to unset all variables - something I
was looking for some time ago.

So I really like that solution: logical, clear, does not break anything, and
easy to read - I would say go for it.

>
> What do you think?
>
> >
> > In addition: I would like to have a warning if #+BABEL is present in the
> org
> > file, so that one remembers that it has to be changed.
> >
>
> #+begin_src emacs-lisp
>  (add-hook 'org-mode-hook
>(lambda ()
>  (save-excursion
>(goto-char (point-min))
>(when (re-search-forward (org-make-options-regexp
> '("BABEL")))
>  (message "This file contains a \"#+BABEL:\" line.")
> #+end_src
>

Could this be included in the next few versions of org, as I can imnagine
that especially infrequent org-babel users will be confused. Also: in a
year, when I open an old org-file and it des not work, this would warn me
about the necessary modifications.


Cheers,

Rainer


>
> Cheers -- Eric
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Rainer M Krug]

On Sat, Oct 22, 2011 at 9:58 AM, Christian Moe wrote:

> On 10/21/11 8:40 PM, Rainer M Krug wrote:
>
>>
>>
>> Just to add to it: at the moment I have e.g:
>>
>> #+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"
>>
>> which would look horrible in one line and a nightmare to edit.
>>
>> Any suggestions how this cold be changed?
>>
>
> Wow. I guess I was wrong to imagine your problem was solved.
>
> If your code blocks share the same language, and it supports sessions, I'd
> bite the bullet and transform them into #+HEADERS lines for the first src
> block, then reuse them through a session. Does that make sense?
>
> If your variables are going to be used by different src blocks in different
> languages, I don't have any elegant solution.
>

Yep - different languages: R and sh



>
> Yours,
> Christian
>
>
>
>
>
>
>
>
>
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Christian Moe]

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:

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

[Eric Schulte]

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/

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

[Eric Schulte]

>
> Just to add to it: at the moment I have e.g:
>
> #+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"
>
> which would look horrible in one line and a nightmare to edit.
>
> Any suggestions how this cold be changed?
>

Hmm, I don't see any easy solution for the above.  I'm sorry to have
removed this functionality.

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 rather than simply
   replacing the value.  Perhaps this could be done with a variable like
   org-accumulating-properties which could hold a list of those
   properties which should accumulate values rather than overwriting
   them.

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

   FWIW I would like to have a similar extender for #+TBLFM: lines.
   Actually this choice may be my preferred solution.

What do you think?

>
> In addition: I would like to have a warning if #+BABEL is present in the org
> file, so that one remembers that it has to be changed.
>

#+begin_src emacs-lisp
  (add-hook 'org-mode-hook
(lambda ()
  (save-excursion
(goto-char (point-min))
(when (re-search-forward (org-make-options-regexp '("BABEL")))
  (message "This file contains a \"#+BABEL:\" line.")
#+end_src

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

> Will
>
> #+PROPERTY: var foo=1
> #+PROPERTY: var bar=2
>
> also work, or result in one variable not signed?
>

Try it out :)

This is a question about property behavior not specific to code blocks.
I believe that the second line will override the first, which is why it
was necessary to be able to specify multiple variables in a single
#+PROPERTY: instance.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

>
> Just to clarify my understanding: on a #+PROPERTY line, you *have* to
> say
>
> #+PROPERTY: var a=1, b=2
>
> but in the code block itself, you can say *either*
>
> #+begin_src emacs-lisp :var a=1, b=2
> ...
>
>
> *or*
>
> #+begin_src emacs-lisp :var a=1 :var b=2
> ...
>

correct

>
> Experimentally, both of these currently work: do you have any plans to
> outlaw the last form?
>

no

>
> Also, how does the comma-separated list of variable assignments interact
> with a language where comma has syntactic significance? I was primarily
> thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
> construct. AFAICT, that never worked in babel[fn:1], so it may not
> matter much, but it may be a good idea to come up with a quoting
> mechanism so things like that can be added in the future if necessary.
>

The syntax of the language is not used in the header argument form, only
code-block constructs are used here, which largely amounts to data and
code block references, indexing into variables, and emacs-lisp forms.
There are cases where the above do contain ", " but they are parsed
correctly, e.g.,

#+headers: :var data=foo(bar=1, baz=2), fuz=5

and

#+headers: :var data=table[0,0]

will both be parsed correctly.

>
> Thanks,
> Nick
>
> Footnotes:
>
> [fn:1] I checked in 7.7 to avoid the recent churn with the following
> code block
>
>
> #+begin_src python :var a='(1,2)'
> len(a)
> #+end_src
>
> and I get 
>
> ,
> |   File "", line 3
> | a=[1, [\,, 2]]
> |  ^
> | SyntaxError: unexpected character after line continuation character
> `
>
> in the org babel error output buffer.

you can use elisp in assignment forms, but not syntax from the language
of the code block, so the above could be re-written as

#+begin_src python :var a='(1 2)
  len(a)
#+end_src

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Christian Moe]

On 10/21/11 8:40 PM, Rainer M Krug wrote:



Just to add to it: at the moment I have e.g:

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

which would look horrible in one line and a nightmare to edit.

Any suggestions how this cold be changed?


Wow. I guess I was wrong to imagine your problem was solved.

If your code blocks share the same language, and it supports sessions, 
I'd bite the bullet and transform them into #+HEADERS lines for the 
first src block, then reuse them through a session. Does that make sense?


If your variables are going to be used by different src blocks in 
different languages, I don't have any elegant solution.


Yours,
Christian

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

[Sebastien Vauban]

Hi Darlan,

Darlan Cavalcante Moreira wrote:
> 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.

#+PROPERTY:  var foo="level0"

* Overview

Global vars and local-to-this-subtree vars seem correctly handled.

Effectively, vars set in higher level trees are not passed correctly to the
code block.

* Test code
  :PROPERTIES:
  :var:  bar="level1"
  :END:

** Using the different vars
   :PROPERTIES:
   :var:  baz="level2"
   :END:

#+srcname: test
#+begin_src sh :var foo="valueforthiscodeblock"
echo $foo
echo $bar
echo $baz
#+end_src

#+results: test
| valueforthiscodeblock |
|   |
| level2|

As you can see, the "bar" variable is unknown to the code block.

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Darlan Cavalcante Moreira]

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.

That is, in the example below the level-2 sub-trees would not have the foo
variable passed to babel.
--8<---cut here---start->8---
* 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
--8<---cut here---end--->8---

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
--8<---cut here---start->8---
* 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
--8<---cut here---end--->8---

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.

--
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
> 
> 

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

[Christian Moe]

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

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

[Rainer M Krug]

On Fri, Oct 21, 2011 at 8:35 PM, Rainer M Krug  wrote:

>
>
> On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte wrote:
>
>> Christian Moe  writes:
>>
>> > Hi again,
>> >
>> > I can quickly think of two advantages of the late lamented (if only by
>> > me) #+BABEL header over using properties.
>> >
>> > 1. Allowing you to specify multiple buffer-wide options on the same
>> > line (keeping things short), in the same colon :syntax as used in a
>> > src block header (keeping things consistent and easy to copy back and
>> > forth). None of this makes a substantive difference.
>> >
>>
>> Understood, the new method will require multiple lines.  Everything is a
>> trade-off...
>>
>> >
>> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
>> > could make a substantive difference in some applications. The
>> > following will work:
>> >
>> >#+BABEL: :var euro=1.3791 :var salestax=.15
>> >
>> > The following will not, since it tries to set the same property:
>> >
>> >#+PROPERTY: var euro=1.3791
>> >#+PROPERTY: var salestax=.15
>> >
>> > If BABEL is dropped for PROPERTY, it would be good for the :var:
>> > property to support multiple arguments (comma-separated would be good
>> > for consistency with passing arguments through the SRCNAME). E.g.:
>> >
>> >#+PROPERTY: var euro=1.3791, salestax=.15
>> >
>> > I think I'd like this better in any case.
>> >
>>
>> 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
>>
>>
> Will
>
> #+PROPERTY: var foo=1
> #+PROPERTY: var bar=2
>
> also work, or result in one variable not signed?
>
> Rainer
>

Just to add to it: at the moment I have e.g:

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

which would look horrible in one line and a nightmare to edit.

Any suggestions how this cold be changed?

In addition: I would like to have a warning if #+BABEL is present in the org
file, so that one remembers that it has to be changed.

Cheers,

Rainer


>
>
>> 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/
>>
>>
>
>
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
>
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
>
> Tel :   +33 - (0)9 53 10 27 44
> Cell:   +33 - (0)6 85 62 59 98
> Fax (F):   +33 - (0)9 58 10 27 44
>
> Fax (D):+49 - (0)3 21 21 25 22 44
>
> email:  rai...@krugs.de
>
> Skype:  RMkrug
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Rainer M Krug]

On Fri, Oct 21, 2011 at 7:37 PM, Eric Schulte wrote:

> Christian Moe  writes:
>
> > Hi again,
> >
> > I can quickly think of two advantages of the late lamented (if only by
> > me) #+BABEL header over using properties.
> >
> > 1. Allowing you to specify multiple buffer-wide options on the same
> > line (keeping things short), in the same colon :syntax as used in a
> > src block header (keeping things consistent and easy to copy back and
> > forth). None of this makes a substantive difference.
> >
>
> Understood, the new method will require multiple lines.  Everything is a
> trade-off...
>
> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The
> > following will work:
> >
> >#+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >#+PROPERTY: var euro=1.3791
> >#+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var:
> > property to support multiple arguments (comma-separated would be good
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >#+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
>
> 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
>
>
Will

#+PROPERTY: var foo=1
#+PROPERTY: var bar=2

also work, or result in one variable not signed?

Rainer



> 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/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Nick Dokos]

Eric Schulte  wrote:

> >
> > 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> > could make a substantive difference in some applications. The 
> > following will work:
> >
> >#+BABEL: :var euro=1.3791 :var salestax=.15
> >
> > The following will not, since it tries to set the same property:
> >
> >#+PROPERTY: var euro=1.3791
> >#+PROPERTY: var salestax=.15
> >
> > If BABEL is dropped for PROPERTY, it would be good for the :var: 
> > property to support multiple arguments (comma-separated would be good 
> > for consistency with passing arguments through the SRCNAME). E.g.:
> >
> >#+PROPERTY: var euro=1.3791, salestax=.15
> >
> > I think I'd like this better in any case.
> >
> 
> 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.
> 

Just to clarify my understanding: on a #+PROPERTY line, you *have* to
say

#+PROPERTY: var a=1, b=2

but in the code block itself, you can say *either*

#+begin_src emacs-lisp :var a=1, b=2
...


*or*

#+begin_src emacs-lisp :var a=1 :var b=2
...

Experimentally, both of these currently work: do you have any plans to
outlaw the last form?

Also, how does the comma-separated list of variable assignments interact
with a language where comma has syntactic significance? I was primarily
thinking of python where e.g. a=[1,2,3] or a=(1,2) is a legal
construct. AFAICT, that never worked in babel[fn:1], so it may not
matter much, but it may be a good idea to come up with a quoting
mechanism so things like that can be added in the future if necessary.

Thanks,
Nick

Footnotes:

[fn:1] I checked in 7.7 to avoid the recent churn with the following
code block


#+begin_src python :var a='(1,2)'
len(a)
#+end_src

and I get 

,
|   File "", line 3
| a=[1, [\,, 2]]
|  ^
| SyntaxError: unexpected character after line continuation character
`

in the org babel error output buffer.

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

[Eric Schulte]

Christian Moe  writes:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by 
> me) #+BABEL header over using properties.
>
> 1. Allowing you to specify multiple buffer-wide options on the same 
> line (keeping things short), in the same colon :syntax as used in a 
> src block header (keeping things consistent and easy to copy back and 
> forth). None of this makes a substantive difference.
>

Understood, the new method will require multiple lines.  Everything is a
trade-off...

>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The 
> following will work:
>
>#+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>#+PROPERTY: var euro=1.3791
>#+PROPERTY: var salestax=.15
>
> If BABEL is dropped for PROPERTY, it would be good for the :var: 
> property to support multiple arguments (comma-separated would be good 
> for consistency with passing arguments through the SRCNAME). E.g.:
>
>#+PROPERTY: var euro=1.3791, salestax=.15
>
> I think I'd like this better in any case.
>

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/

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

[Rainer M Krug]

On Fri, Oct 21, 2011 at 1:17 PM, Christian Moe wrote:

> On 10/21/11 12:59 PM, Rainer M Krug wrote:
>
>  So, using your above mentioned example, after the first PROPERTY line,
>> euro=1.3795 and SALESTAX not set, while after the second one
>> salestax=.15, and euro is unset? That would be quite bad.
>>
>
> That's what I'd expected, but actually, euro is set and salestax is not.
> Apparently subsequent PROPERTY lines are ignored if they try to set an
> already existing property.
>

That's bad - really bad. Because then I have to substantially change my
files.


>
>  To clarify: before, we could use #+BABEL and #PROPERTY to do similar
>> things. Now the whole #+BABEL has been removed, and only the
>> functionality from #+PROPERTY is left - correct?
>>
>
> That's my understanding. And #+PROPERTY offers equivalent functionality in
> almost every way, but not, as far as I can understand, in this corner case.
>

Then I would suggest to leave #+BABEL until these cases are also implemented
in #+PROPERTY - but I suppose, they are there for a purpose.

Cheers,

Rainer


>
> Christian
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Christian Moe]

On 10/21/11 12:59 PM, Rainer M Krug wrote:


So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one
salestax=.15, and euro is unset? That would be quite bad.


That's what I'd expected, but actually, euro is set and salestax is 
not. Apparently subsequent PROPERTY lines are ignored if they try to 
set an already existing property.



To clarify: before, we could use #+BABEL and #PROPERTY to do similar
things. Now the whole #+BABEL has been removed, and only the
functionality from #+PROPERTY is left - correct?


That's my understanding. And #+PROPERTY offers equivalent 
functionality in almost every way, but not, as far as I can 
understand, in this corner case.


Christian

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

[Rainer M Krug]

On Fri, Oct 21, 2011 at 12:47 PM, Christian Moe wrote:

> On 10/21/11 11:12 AM, Rainer M Krug wrote:
>
>>
>>
>> On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe > **> wrote:
>>
> (...)
>
> 2. Allowing you to pass multiple buffer-wide arguments with :var.
>>This could make a substantive difference in some applications. The
>>following will work:
>>
>>  #+BABEL: :var euro=1.3791 :var salestax=.15
>>
>>The following will not, since it tries to set the same property:
>>
>>  #+PROPERTY: var euro=1.3791
>>  #+PROPERTY: var salestax=.15
>>
>>
>> I think it is a very important point, that the construct with :var
>> still works - but as Eric only mentioned the *naming*, I assume that
>> in the actual usage nothing changes.
>>
>>
> Hi, Rainer,
>
> My point was that there is at least one (minor) case where properties are
> not functionally equivalent to the BABEL line: You cannot pass arguments for
> more than one variable buffer-wide, because you can't have multiple var
> properties at the same time, and at present, one var property only sets one
> variable.
>

So, using your above mentioned example, after the first PROPERTY line,
euro=1.3795 and SALESTAX not set, while after the second one salestax=.15,
and euro is unset? That would be quite bad.


>
> The behavior of properties has not changed. What has changed is the removal
> of the BABEL header, whose colon (:var) syntax did allow you to set multiple
> variables buffer-wide should you wish to.
>

To clarify: before, we could use #+BABEL and #PROPERTY to do similar things.
Now the whole #+BABEL has been removed, and only the functionality from
#+PROPERTY is left - correct?

Rainer



>
> Yours,
> Christian
>
>
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Christian Moe]

On 10/21/11 11:12 AM, Rainer M Krug wrote:



On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe mailto:m...@christianmoe.com>> wrote:

(...)

2. Allowing you to pass multiple buffer-wide arguments with :var.
This could make a substantive difference in some applications. The
following will work:

  #+BABEL: :var euro=1.3791 :var salestax=.15

The following will not, since it tries to set the same property:

  #+PROPERTY: var euro=1.3791
  #+PROPERTY: var salestax=.15


I think it is a very important point, that the construct with :var
still works - but as Eric only mentioned the *naming*, I assume that
in the actual usage nothing changes.



Hi, Rainer,

My point was that there is at least one (minor) case where properties 
are not functionally equivalent to the BABEL line: You cannot pass 
arguments for more than one variable buffer-wide, because you can't 
have multiple var properties at the same time, and at present, one var 
property only sets one variable.


The behavior of properties has not changed. What has changed is the 
removal of the BABEL header, whose colon (:var) syntax did allow you 
to set multiple variables buffer-wide should you wish to.


Yours,
Christian

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

[Rainer M Krug]

On Fri, Oct 21, 2011 at 10:14 AM, Christian Moe wrote:

> Hi again,
>
> I can quickly think of two advantages of the late lamented (if only by me)
> #+BABEL header over using properties.
>

I also think that keeping the #+BABEL would be a good idea, as it keeps the
options for babel separate (as are the functions - org-babel... ). It is
true that babel is getting more and more interwined with org (which is a
good think), but especially in my case, I use org more or less exclusively
for literate programming (babel) and some org features (archiving, note
capture...) in this context, it would be really nice to be able to keep the
options for babel easily identifyable.

I defined a new drawer (:BABEL:) and put my options / arguments / properties
for babel in there. So my question would be: would i be possible to leave
#+BABEL as an equivalent for #+PROPERTY ? Yes, it could be misused, but also
used to make these options easily identifyable.

My setup at the moment:

#+DRAWERS: HIDDEN PROPERTIES STATE CONFIG BABEL OUTPUT LATEX

:BABEL:
#+BABEL: :session *R*
#+BABEL: :results output
#+BABEL: :exports code
#+BABEL: :comments yes
#+BABEL: :tangle Analysis_sensitivity.R
#+BABEL: :var
RESULTSDIR="/media/Results/clusterResults/nsa/LHCube/nsa.91.up-to-date/results/"
#+BABEL: :var
ANALYSISDIR="/home/rkrug/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/LHCube/nsa.91.up-to-date/analysis/"
:END:



> 1. Allowing you to specify multiple buffer-wide options on the same line
> (keeping things short), in the same colon :syntax as used in a src block
> header (keeping things consistent and easy to copy back and forth). None of
> this makes a substantive difference.
>
> 2. Allowing you to pass multiple buffer-wide arguments with :var. This
> could make a substantive difference in some applications. The following will
> work:
>
>  #+BABEL: :var euro=1.3791 :var salestax=.15
>
> The following will not, since it tries to set the same property:
>
>  #+PROPERTY: var euro=1.3791
>  #+PROPERTY: var salestax=.15
>

I think it is a very important point, that the construct with :var still
works - but as Eric only mentioned the *naming*, I assume that in the actual
usage nothing changes.

OK - the colon at the beginning - but I clud live with that change, although
it makes it clear what the actual argument is which is set.


> If BABEL is dropped for PROPERTY, it would be good for the :var: property
> to support multiple arguments (comma-separated would be good for consistency
> with passing arguments through the SRCNAME). E.g.:
>
>  #+PROPERTY: var euro=1.3791, salestax=.15
>

I think that would be a good idea, but I think that was already discussed
some time ago and rejected?


> I think I'd like this better in any case.
>

No - rather in separate lines... but different strokes for different
folks...

Cheers,

Rainer


> Yours,
> Christian
>
>
>
> On 10/21/11 9:28 AM, Sebastien Vauban wrote:
>
>> Multiple lines may be used to specify multiple properties. e.g.,
>>>
>>> #+PROPERTY: results silent
>>> #+PROPERTY: cache yes
>>>
>>
>> *But* I did not know it was limited to _one property per line_.
>>
>> Knowing that:
>>
>> - there is no confusion at all -- we simply (have to) know that the first
>> word
>>   is the "name" without colon, and the rest are "values"
>>
>> - my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.
>>
>> To sum up, I'm perfectly happy with the new choice.
>>
>> Best regards,
>>   Seb
>>
>>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

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

[Christian Moe]

Hi again,

I can quickly think of two advantages of the late lamented (if only by 
me) #+BABEL header over using properties.


1. Allowing you to specify multiple buffer-wide options on the same 
line (keeping things short), in the same colon :syntax as used in a 
src block header (keeping things consistent and easy to copy back and 
forth). None of this makes a substantive difference.


2. Allowing you to pass multiple buffer-wide arguments with :var. This 
could make a substantive difference in some applications. The 
following will work:


  #+BABEL: :var euro=1.3791 :var salestax=.15

The following will not, since it tries to set the same property:

  #+PROPERTY: var euro=1.3791
  #+PROPERTY: var salestax=.15

If BABEL is dropped for PROPERTY, it would be good for the :var: 
property to support multiple arguments (comma-separated would be good 
for consistency with passing arguments through the SRCNAME). E.g.:


  #+PROPERTY: var euro=1.3791, salestax=.15

I think I'd like this better in any case.

Yours,
Christian


On 10/21/11 9:28 AM, Sebastien Vauban wrote:

Multiple lines may be used to specify multiple properties. e.g.,

#+PROPERTY: results silent
#+PROPERTY: cache yes


*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first word
   is the "name" without colon, and the rest are "values"

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
   Seb

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

[Sebastien Vauban]

Hi Eric and Nick,

Eric Schulte wrote:
> Nick Dokos  writes:
>> Eric Schulte  wrote:
>>
>>> > Other than "colon confusion" (having to specify ``:results silent'' on
>>> > the src block header line and ``results silent'' in the #+PROPERTY line
>>> > to get the same behavior), this looks better. Not sure what (if
>>> > anything) can or should be done about the colons.
>>> >
>>> 
>>> I don't know of a good solution for colons.  If we decided to add colons
>>> then the subtree property blocks would become akward, with entries like
>>> 
>>> ** foo
>>>:PROPERTIES:
>>>::results: silent
>>>:END:
>>> 
>>> I would say we could look for each value both with and without colons,
>>> but property searches of this nature are slow and doubling the speed
>>> impact simply for allow colon flexibility doesn't seem to be a good
>>> tradeoff.  I think this will just have to be something that users will
>>> need to learn.
>>
>> [fn:1] ...but I take some perverse pleasure from the fact that both
>> Suvayu and Seb asked the question :-)
>
> I noticed that too, and it no doubt means that this same question will
> occur to future users.

I knew there was no beginning colon in the #+PROPERTY line (and that does not
bother me).

>> For example, how do we translate, in the new syntax,
>>
>> #+BABEL::results output code append
>>
>> (where `:results' is the "name", and `output', `code' and `append' are
>> "values")?
>
> The above would become
>
> #+PROPERTY: results output code append
>
> Since only one property may be specified per property line there is no
> need for colons.  This mirrors exactly the way the properties are saved
> under subtrees in :PROPERTY: blocks.
>
> Multiple lines may be used to specify multiple properties. e.g.,
>
> #+PROPERTY: results silent
> #+PROPERTY: cache yes

*But* I did not know it was limited to _one property per line_.

Knowing that:

- there is no confusion at all -- we simply (have to) know that the first word
  is the "name" without colon, and the rest are "values"

- my argument in favor of #+PROPERTIES (over #+PROPERTY) simply falls.

To sum up, I'm perfectly happy with the new choice.

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Suvayu Ali]

On Thu, 20 Oct 2011 15:52:42 -0600
Eric Schulte  wrote:

> suvayu ali  writes:
> 
> > Hi Eric,
> >
> > On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte
> >  wrote:
> >> 2. The existing #+PROPERTY: line may now be used to specify values
> >> for header arguments, e.g.,
> >>
> >>   #+PROPERTY: results silent
> >>
> >>   would silence all results in the current buffer.
> >>
> >
> > Is the 'results' without a preceding colon or is that a typo?
> 
> As with properties specified in :PROPERTIES: blocks under headlines,
> the colon is not needed, the above is correct.
> 

Thanks a lot Eric. I have never used :PROPERTIES: for Babel, hence I
didn't know!

> Best -- Eric
> 

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

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

[Eric Schulte]

Nick Dokos  writes:

> Eric Schulte  wrote:
>
>> > Other than "colon confusion" (having to specify ``:results silent'' on
>> > the src block header line and ``results silent'' in the #+PROPERTY line
>> > to get the same behavior), this looks better. Not sure what (if
>> > anything) can or should be done about the colons.
>> >
>> 
>> I don't know of a good solution for colons.  If we decided to add colons
>> then the subtree property blocks would become akward, with entries like
>> 
>> ** foo
>>:PROPERTIES:
>>::results: silent
>>:END:
>> 
>> I would say we could look for each value both with and without colons,
>> but property searches of this nature are slow and doubling the speed
>> impact simply for allow colon flexibility doesn't seem to be a good
>> tradeoff.  I think this will just have to be something that users will
>> need to learn.
>> 
>
> I agree[fn:1]: the point is to simplify the code, not complicate it
> *and* slow down everything at the same time.  Maybe the header args
> section of the manual can use the "colon as delimiter" method to explain
> the equivalent forms and that will suffice.
>

I agree, the header argument syntax portion of the documentation could
be made more clear, and I did like you explanation to Seb's email.
Perhaps you could submit a documentation patch? :)

>
> Nick
>
> Footnotes:
>
> [fn:1] ...but I take some perverse pleasure from the fact that both
> Suvayu and Seb asked the question :-)

I noticed that too, and it no doubt means that this same question will
occur to future users.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Eric Schulte  wrote:

> > Other than "colon confusion" (having to specify ``:results silent'' on
> > the src block header line and ``results silent'' in the #+PROPERTY line
> > to get the same behavior), this looks better. Not sure what (if
> > anything) can or should be done about the colons.
> >
> 
> I don't know of a good solution for colons.  If we decided to add colons
> then the subtree property blocks would become akward, with entries like
> 
> ** foo
>:PROPERTIES:
>::results: silent
>:END:
> 
> I would say we could look for each value both with and without colons,
> but property searches of this nature are slow and doubling the speed
> impact simply for allow colon flexibility doesn't seem to be a good
> tradeoff.  I think this will just have to be something that users will
> need to learn.
> 

I agree[fn:1]: the point is to simplify the code, not complicate it
*and* slow down everything at the same time.  Maybe the header args
section of the manual can use the "colon as delimiter" method to explain
the equivalent forms and that will suffice.

Nick

Footnotes:

[fn:1] ...but I take some perverse pleasure from the fact that both
Suvayu and Seb asked the question :-)

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

[Eric Schulte]

Nick Dokos  writes:

> Eric Schulte  wrote:
>
>> ...  I've just pushed up what I
>> consider to be a clean implementation.  Put briefly the new behavior is
>> that "properties may be used to specify header arguments".  More
>> completely...
>> 
>> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>> 
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>header arguments, e.g.,
>> 
>>#+PROPERTY: results silent
>> 
>>would silence all results in the current buffer.
>> 
>> I think this should be simple, easy to remember, and it certainly
>> cleaned up the code base.  Please let me know what you think of this new
>> setup.
>> 
>
> Other than "colon confusion" (having to specify ``:results silent'' on
> the src block header line and ``results silent'' in the #+PROPERTY line
> to get the same behavior), this looks better. Not sure what (if
> anything) can or should be done about the colons.
>

I don't know of a good solution for colons.  If we decided to add colons
then the subtree property blocks would become akward, with entries like

** foo
   :PROPERTIES:
   ::results: silent
   :END:

I would say we could look for each value both with and without colons,
but property searches of this nature are slow and doubling the speed
impact simply for allow colon flexibility doesn't seem to be a good
tradeoff.  I think this will just have to be something that users will
need to learn.

Cheers -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Sebastien Vauban  wrote:


> I just have one question, as I'm puzzled by the lack of `:' in front of the
> "properties": how do we distinguish the argument "value" from the argument
> "name"?
> 
> For example, how do we translate, in the new syntax,
> 
> #+BABEL::results output code append
> 
> (where `:results' is the "name", and `output', `code' and `append' are
> "values")?
> 

#+PROPERTY: results output code append

See the aforementioned sec. 7.1 of the manual. Equivalently,

* foo
  :PROPERTIES:
  :results: output code append
  :END:

That's a consequence of the property syntax. On the code block
header line however, you have to have some purely syntactic
marker to distinguish properties from their values, hence

#+begin_src foo :results output code append :exports both
...

The trick is to think of the colon as a delimited (like a comma)
not as a part of the property name.

Nick

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

[Eric Schulte]

"Sebastien Vauban"  writes:

> Hi Eric,
>
> Eric Schulte wrote:
>> Nick Dokos  writes:
>>> Eric Schulte  wrote:
 Nick Dokos  writes:
 > Eric Schulte  wrote:
 >
 >> I have just pushed up a change to the Org-mode git repository which
 >> removes support for #+BABEL lines.  Please use the more general
 >> #+PROPERTIES lines instead.
 >
 > Coming late to the dance - sorry. I think that's very confusing.
 > "Property" is an overloaded term in org: we now have the :PROPERTIES:
 > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
 > plural forms are already pretty bad).
 
 Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>>>
>>> I think so: see section 7.1 for a use of the former. AFAICT, the latter
>>> only applies to code block header arguments.
>>
>> Oh!
>>
>> Thank you for making this clear, I had assumed that #+PROPERTIES: lines
>> were an integral part of Org-mode which code block header arguments were
>> simply making use of.  Having read the section of the info manual you
>> point out above I see that I was mistaken.  I've just pushed up what I
>> consider to be a clean implementation.  Put briefly the new behavior is
>> that "properties may be used to specify header arguments".  More
>> completely...
>>
>> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>>
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>header arguments, e.g.,
>>
>>#+PROPERTY: results silent
>>
>>would silence all results in the current buffer.
>>
>> I think this should be simple, easy to remember, and it certainly
>> cleaned up the code base.  Please let me know what you think of this new
>> setup.
>
> I just have one question, as I'm puzzled by the lack of `:' in front of the
> "properties": how do we distinguish the argument "value" from the argument
> "name"?
>
> For example, how do we translate, in the new syntax,
>
> #+BABEL::results output code append
>
> (where `:results' is the "name", and `output', `code' and `append' are
> "values")?
>

The above would become

#+PROPERTY: results output code append

Since only one property may be specified per property line there is no
need for colons.  This mirrors exactly the way the properties are saved
under subtrees in :PROPERTY: blocks.

Multiple lines may be used to specify multiple properties. e.g.,

#+PROPERTY: results silent
#+PROPERTY: cache yes

Best -- Eric

>
> Best regards,
>   Seb

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Eric Schulte]

suvayu ali  writes:

> Hi Eric,
>
> On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte  wrote:
>> 2. The existing #+PROPERTY: line may now be used to specify values for
>>   header arguments, e.g.,
>>
>>   #+PROPERTY: results silent
>>
>>   would silence all results in the current buffer.
>>
>
> Is the 'results' without a preceding colon or is that a typo?

As with properties specified in :PROPERTIES: blocks under headlines, the
colon is not needed, the above is correct.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Eric Schulte  wrote:

> ...  I've just pushed up what I
> consider to be a clean implementation.  Put briefly the new behavior is
> that "properties may be used to specify header arguments".  More
> completely...
> 
> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
> 
> 2. The existing #+PROPERTY: line may now be used to specify values for
>header arguments, e.g.,
> 
>#+PROPERTY: results silent
> 
>would silence all results in the current buffer.
> 
> I think this should be simple, easy to remember, and it certainly
> cleaned up the code base.  Please let me know what you think of this new
> setup.
> 

Other than "colon confusion" (having to specify ``:results silent'' on
the src block header line and ``results silent'' in the #+PROPERTY line
to get the same behavior), this looks better. Not sure what (if
anything) can or should be done about the colons.

Thanks,
Nick

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

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> Nick Dokos  writes:
>> Eric Schulte  wrote:
>>> Nick Dokos  writes:
>>> > Eric Schulte  wrote:
>>> >
>>> >> I have just pushed up a change to the Org-mode git repository which
>>> >> removes support for #+BABEL lines.  Please use the more general
>>> >> #+PROPERTIES lines instead.
>>> >
>>> > Coming late to the dance - sorry. I think that's very confusing.
>>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>>> > plural forms are already pretty bad).
>>> 
>>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>>
>> I think so: see section 7.1 for a use of the former. AFAICT, the latter
>> only applies to code block header arguments.
>
> Oh!
>
> Thank you for making this clear, I had assumed that #+PROPERTIES: lines
> were an integral part of Org-mode which code block header arguments were
> simply making use of.  Having read the section of the info manual you
> point out above I see that I was mistaken.  I've just pushed up what I
> consider to be a clean implementation.  Put briefly the new behavior is
> that "properties may be used to specify header arguments".  More
> completely...
>
> 1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.
>
> 2. The existing #+PROPERTY: line may now be used to specify values for
>header arguments, e.g.,
>
>#+PROPERTY: results silent
>
>would silence all results in the current buffer.
>
> I think this should be simple, easy to remember, and it certainly
> cleaned up the code base.  Please let me know what you think of this new
> setup.

I just have one question, as I'm puzzled by the lack of `:' in front of the
"properties": how do we distinguish the argument "value" from the argument
"name"?

For example, how do we translate, in the new syntax,

#+BABEL::results output code append

(where `:results' is the "name", and `output', `code' and `append' are
"values")?

Best regards,
  Seb

-- 
Sebastien Vauban

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

[suvayu ali]

Hi Eric,

On Thu, Oct 20, 2011 at 11:34 PM, Eric Schulte  wrote:
> 2. The existing #+PROPERTY: line may now be used to specify values for
>   header arguments, e.g.,
>
>   #+PROPERTY: results silent
>
>   would silence all results in the current buffer.
>

Is the 'results' without a preceding colon or is that a typo?

-- 
Suvayu

Open source is the future. It sets us free.

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

[Eric Schulte]

Nick Dokos  writes:

> Eric Schulte  wrote:
>
>> Nick Dokos  writes:
>> 
>> > Eric Schulte  wrote:
>> >
>> >> I have just pushed up a change to the Org-mode git repository which
>> >> removes support for #+BABEL lines.  Please use the more general
>> >> #+PROPERTIES lines instead.
>> >> 
>> >
>> > Coming late to the dance - sorry. I think that's very confusing.
>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>> > plural forms are already pretty bad).
>> 
>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>
> I think so: see section 7.1 for a use of the former. AFAICT, the latter
> only applies to code block header arguments.
>

Oh!

Thank you for making this clear, I had assumed that #+PROPERTIES: lines
were an integral part of Org-mode which code block header arguments were
simply making use of.  Having read the section of the info manual you
point out above I see that I was mistaken.  I've just pushed up what I
consider to be a clean implementation.  Put briefly the new behavior is
that "properties may be used to specify header arguments".  More
completely...

1. The #+PROPERTIES: (and #+BABEL:) directives no longer exist.

2. The existing #+PROPERTY: line may now be used to specify values for
   header arguments, e.g.,

   #+PROPERTY: results silent

   would silence all results in the current buffer.

I think this should be simple, easy to remember, and it certainly
cleaned up the code base.  Please let me know what you think of this new
setup.

Thanks -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Christian Moe  wrote:

> Whoa -- before this gets more confusing:
> 
> Eric, did you push up a (new, or at least so far undocumented in the
> manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien
> seem to understand you?
> 
> Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY
> line or :PROPERTIES: drawer, as provided in the manual?
> 

Here's the commit log (I think it reflects the code changes faithfully):

,
| commit 04a978fde525a442f9de14d1a67783edd5c9cb78
| Author: Eric Schulte 
| Date:   Thu Oct 20 13:31:20 2011 -0600
| 
| removing #+BABEL: lines in favor of general #+PROPERTIES: lines
| 
| * lisp/ob.el (org-babel-params-from-buffer): Removing #+BABEL: lines
|   in favor of general #+PROPERTIES: lines.
| 
| * doc/org.texi (Buffer-wide header arguments): Removing documentation
|   of the defunct #+BABEL: structure.
`

So #+BABEL was traded for #+PROPERTIES.

Nick


> Yours,
> Christian
> 
> (lamenting the demise of the #+BABEL header I'd just recently started
> to use)
> 
> 
> 
> On 10/20/11 10:12 PM, Eric Schulte wrote:
> > Nick Dokos  writes:
> >
> >> Eric Schulte  wrote:
> >>
> >>> I have just pushed up a change to the Org-mode git repository which
> >>> removes support for #+BABEL lines.  Please use the more general
> >>> #+PROPERTIES lines instead.
> >>>
> >>
> >> Coming late to the dance - sorry. I think that's very confusing.
> >> "Property" is an overloaded term in org: we now have the :PROPERTIES:
> >> drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> >> plural forms are already pretty bad).
> >
> > Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
> >
> >> Also, there is the general concept of properties (the stuff that the
> >> property API applies to).
> >>
> >> Unless there is an underlying unity of which I'm unaware, I'd strongly
> >> suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> >> an easy-template for easy insertion).
> >>
> >
> > Code blocks already piggy-back off of subtree properties pulling their
> > header arguments out of the properties specified on the subtree level.
> > Given that header arguments and properties are already thus interleaved
> > I believe that properties should be used on the file-wide level as well,
> > rather than introducing another synonymous keyword which adds no new
> > functionality.
> >
> > Does that make sense?
> >
> > Best -- Eric
> >
> 
> 

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

[Christian Moe]

Whoa -- before this gets more confusing:

Eric, did you push up a (new, or at least so far undocumented in the 
manual) syntax involving a #+PROPERTIES line, as Nick and Sebastien 
seem to understand you?


Or was #+PROPERTIES just a typo, and you mean using the #+PROPERTY 
line or :PROPERTIES: drawer, as provided in the manual?


Yours,
Christian

(lamenting the demise of the #+BABEL header I'd just recently started 
to use)




On 10/20/11 10:12 PM, Eric Schulte wrote:

Nick Dokos  writes:


Eric Schulte  wrote:


I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines.  Please use the more general
#+PROPERTIES lines instead.



Coming late to the dance - sorry. I think that's very confusing.
"Property" is an overloaded term in org: we now have the :PROPERTIES:
drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
plural forms are already pretty bad).


Do the #+PROPERTY and #+PROPERTIES lines have different semantics?


Also, there is the general concept of properties (the stuff that the
property API applies to).

Unless there is an underlying unity of which I'm unaware, I'd strongly
suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
an easy-template for easy insertion).



Code blocks already piggy-back off of subtree properties pulling their
header arguments out of the properties specified on the subtree level.
Given that header arguments and properties are already thus interleaved
I believe that properties should be used on the file-wide level as well,
rather than introducing another synonymous keyword which adds no new
functionality.

Does that make sense?

Best -- Eric

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

[Sebastien Vauban]

Hi Nick and Eric,

Nick Dokos wrote:
> Eric Schulte  wrote:
>> Nick Dokos  writes:
>> > Eric Schulte  wrote:
>> >
>> >> I have just pushed up a change to the Org-mode git repository which
>> >> removes support for #+BABEL lines.  Please use the more general
>> >> #+PROPERTIES lines instead.
>> >
>> > Coming late to the dance - sorry. I think that's very confusing.
>> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
>> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
>> > plural forms are already pretty bad).

If you'd have asked me, I would have chosen #+BABEL instead of #+PROPERTIES,
as it made it clear "who" owned those directives, to whom they were targeted.

>> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?
>
> I think so: see section 7.1 for a use of the former. AFAICT, the latter
> only applies to code block header arguments.
>
>> > Also, there is the general concept of properties (the stuff that the
>> > property API applies to).
>> >
>> > Unless there is an underlying unity of which I'm unaware, I'd strongly
>> > suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
>> > an easy-template for easy insertion). 
>> 
>> Code blocks already piggy-back off of subtree properties pulling their
>> header arguments out of the properties specified on the subtree level.
>> Given that header arguments and properties are already thus interleaved
>> I believe that properties should be used on the file-wide level as well,
>> rather than introducing another synonymous keyword which adds no new
>> functionality.
>> 
>> Does that make sense?

However, I've been convinced by Eric's arguments. The fact you already can mix
BABEL properties in subtree PROPERTIES...

> Yes, but the #+PROPERTIES line has nothing to do with org properties. It
> *only* affects code blocks, no?

But, I guess you're right, Nick: not the other way around.

So, I don't know anymore what to think...

I do well agree that "properties" has not a clear-cut meaning anymore; this is
a very general word.

Now, if I had to choose between #+PROPERTY and #+PROPERTIES, I would favor the
last one, as it is some place where you can stuff many properties -- and to
reflect what's already use for the export options: there you put the "options"
under the OPTIONS "meta-keyword". In the plural form.

Just my 2 cents. Whatever your choice, I'll follow it. And I always prefer to
reduce the number of synonyms, and have just one official form[1].

Best regards,
  Seb

Footnotes:

[1] I have the same "annoying" feelings with #+SOURCE, #+SRCNAME, #+FUNCTION,
#+CALL, #+LOB, and SBE, some of which are interchangeable; some not. I'd prefer
deprecating an old form when a better one is found.

-- 
Sebastien Vauban

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

[Nick Dokos]

Eric Schulte  wrote:

> Nick Dokos  writes:
> 
> > Eric Schulte  wrote:
> >
> >> I have just pushed up a change to the Org-mode git repository which
> >> removes support for #+BABEL lines.  Please use the more general
> >> #+PROPERTIES lines instead.
> >> 
> >
> > Coming late to the dance - sorry. I think that's very confusing.
> > "Property" is an overloaded term in org: we now have the :PROPERTIES:
> > drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> > plural forms are already pretty bad).
> 
> Do the #+PROPERTY and #+PROPERTIES lines have different semantics?

I think so: see section 7.1 for a use of the former. AFAICT, the latter
only applies to code block header arguments.

> 
> > Also, there is the general concept of properties (the stuff that the
> > property API applies to).
> >
> > Unless there is an underlying unity of which I'm unaware, I'd strongly
> > suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> > an easy-template for easy insertion). 
> >
> 
> Code blocks already piggy-back off of subtree properties pulling their
> header arguments out of the properties specified on the subtree level.
> Given that header arguments and properties are already thus interleaved
> I believe that properties should be used on the file-wide level as well,
> rather than introducing another synonymous keyword which adds no new
> functionality.
> 
> Does that make sense?
> 

Yes, but the #+PROPERTIES line has nothing to do with org properties. It
*only* affects code blocks, no?

Nick

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

[Eric Schulte]

Nick Dokos  writes:

> Eric Schulte  wrote:
>
>> I have just pushed up a change to the Org-mode git repository which
>> removes support for #+BABEL lines.  Please use the more general
>> #+PROPERTIES lines instead.
>> 
>
> Coming late to the dance - sorry. I think that's very confusing.
> "Property" is an overloaded term in org: we now have the :PROPERTIES:
> drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
> plural forms are already pretty bad).

Do the #+PROPERTY and #+PROPERTIES lines have different semantics?

> Also, there is the general concept of properties (the stuff that the
> property API applies to).
>
> Unless there is an underlying unity of which I'm unaware, I'd strongly
> suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
> an easy-template for easy insertion). 
>

Code blocks already piggy-back off of subtree properties pulling their
header arguments out of the properties specified on the subtree level.
Given that header arguments and properties are already thus interleaved
I believe that properties should be used on the file-wide level as well,
rather than introducing another synonymous keyword which adds no new
functionality.

Does that make sense?

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

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

[Nick Dokos]

Eric Schulte  wrote:

> I have just pushed up a change to the Org-mode git repository which
> removes support for #+BABEL lines.  Please use the more general
> #+PROPERTIES lines instead.
> 

Coming late to the dance - sorry. I think that's very confusing.
"Property" is an overloaded term in org: we now have the :PROPERTIES:
drawer, the #+PROPERTY line and the #+PROPERTIES line (singular and
plural forms are already pretty bad).  Also, there is the general
concept of properties (the stuff that the property API applies to).

Unless there is an underlying unity of which I'm unaware, I'd strongly
suggest another term - perhaps CODE_BLOCK_HEADER_ARGUMENTS (plus
an easy-template for easy insertion). 

Nick

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

[Eric Schulte]

Hi,

I have just pushed up a change to the Org-mode git repository which
removes support for #+BABEL lines.  Please use the more general
#+PROPERTIES lines instead.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/