From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines Date: Mon, 24 Oct 2011 12:10:25 +0200 Message-ID: References: <87pqhrih3s.fsf@gmail.com> <30891.1319141196@alphaville.dokosmarshall.org> <87fwinifqu.fsf@gmail.com> <32184.1319143892@alphaville.dokosmarshall.org> <87zkgvgxe7.fsf@gmail.com> <1405.1319147324@alphaville.dokosmarshall.org> <87zkgvfhra.fsf@gmail.com> <2127.1319148505@alphaville.dokosmarshall.org> <87vcrjfgt1.fsf@gmail.com> <80sjmmvm60.fsf@somewhere.org> <4EA129DB.4070006@christianmoe.com> <8762ji5jr6.fsf@gmail.com> <87fwil10o2.fsf@gmail.com> <4EA31457.3090800@christianmoe.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016e6551d5cb4380104b008a106 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:50312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIHUD-00061H-PG for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 06:10:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RIHUA-0007IQ-Tw for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 06:10:29 -0400 Received: from mail-qy0-f176.google.com ([209.85.216.176]:44902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RIHUA-0007IG-P4 for emacs-orgmode@gnu.org; Mon, 24 Oct 2011 06:10:26 -0400 Received: by qyk30 with SMTP id 30so5588074qyk.0 for ; Mon, 24 Oct 2011 03:10:26 -0700 (PDT) In-Reply-To: <4EA31457.3090800@christianmoe.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: mail@christianmoe.com Cc: Sebastien Vauban , emacs-orgmode@gnu.org --0016e6551d5cb4380104b008a106 Content-Type: text/plain; charset=ISO-8859-1 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: Rainer@krugs.de Skype: RMkrug --0016e6551d5cb4380104b008a106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 22, 2011 at 9:07 PM, Christi= an Moe <mail@= christianmoe.com> 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=3D0,
> #+PROPERTY+: SVNVERSION=3D(vc-working-revision (buffer-file-nam= e)),
(...)

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-Babe= l was being stabilized.)

In short, let Babel assign to any declared variables of a src block the val= ues 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=3D1, bar, baz=3D3' 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 specif= ied at any level of the outline.

- If no further changes were made (such as the property accumulation Eric s= uggested), it would still be possible to /declare/ variables only at /one/ = level of the outline besides in the code block and calls, since declaration= s 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 understa= nding the advantages - possibly because I only had one coffee this morning.= In addition see further down:

SNIP
=A0
On 10/22/11 5:52 PM, Eric Schulte wrote:

#+BABEL: :var MAINVERSION=3D0
#+BABEL: :var SVNVERSION=3D(vc-working-revision (buffer-file-name))<= br> #+BABEL: :var SVNSTATE=3D( symbol-name (vc-state (or (buffer-file-name) org= -current-export-file)))
#+BABEL: :var SVNSTATENUM=3D(if (eq (vc-state (or (buffer-file-name) org-cu= rrent-export-file)) 'up-to-date) 0 13)
#+BABEL: :var DISP_PACKAGE=3D"seedDisp_0.4-13.tar.gz"


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

#+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
#+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-cur= rent-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-curren= t-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=3D10

what would th= is be? it should have been

#+PROPERTY: var x=3D10

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=3D0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PACKAGE
#+PROPERTY: SVNVERSION (vc-working-revision (buffer-file-name))
#+PROPERTY: SVNSTATE ( symbol-name (vc-state (or (buffer-file-name) org-cur= rent-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-curren= t-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-cur= rent-export-file)))
#+PROPERTY: SVNSTATENUM (if (eq (vc-state (or (buffer-file-name) org-curren= t-export-file)) 'up-to-date) 0 13)
#+PROPERTY: DISP_PACKAGE "seedDisp_0.4-13.tar.gz"
#+PROPERTY: var MAINVERSION=3D0, SVNVERSION, SVNSTATE, SVNSTATENUM, DISP_PA= CKAGE

not, as the variables are only defined later.


But this would= not make

#+PROPERTY+:

redundant, but rather enhance it.
=
Cheers,

Rainer

Cheers,

Rainer



SNIP
=A0
Yours,
Christian



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

Centre of Excellence for Invasion Biology
Stellenbos= ch University
South Africa

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

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

email: =A0 =A0 = =A0Rainer@krugs.de=

Skype: =A0 =A0 =A0RMkrug

--0016e6551d5cb4380104b008a106--