From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks" Date: Tue, 15 Nov 2011 13:33:13 +0100 Message-ID: References: <87vcr5c76e.fsf@gmail.com> <87vcr5j5a5.fsf@gmail.com> <4EAF118C.8050806@christianmoe.com> <87hb2mo7ek.fsf@altern.org> <87obwuh19t.fsf@gmail.com> <87hb2mdmi9.fsf@gnu.org> <87obwtgip9.fsf@gmail.com> <87sjm5ez0f.fsf@gmail.com> <4eb42564.059dec0a.5ffc.7ff5@mx.google.com> <877h3felm2.fsf@gmail.com> <87ty6ffuu6.fsf@gmail.com> <80d3d3neof.fsf@somewhere.org> <80aa87lyu9.fsf@somewhere.org> <87sjlyeh41.fsf@gmail.com> <87ehxigra3.fsf@gmail.com> <8762itff6u.fsf@gmail.com> <80vcqthqrz.fsf@somewhere.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001636426e11ddf20304b1c530a6 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:42160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQICV-0003dd-2z for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 07:33:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQICR-0005wx-7G for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 07:33:19 -0500 Received: from mail-gx0-f169.google.com ([209.85.161.169]:41536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQICR-0005wj-3c for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 07:33:15 -0500 Received: by ggnq1 with SMTP id q1so4413286ggn.0 for ; Tue, 15 Nov 2011 04:33:13 -0800 (PST) In-Reply-To: <80vcqthqrz.fsf@somewhere.org> 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: Eric Schulte Cc: emacs-orgmode@gnu.org --001636426e11ddf20304b1c530a6 Content-Type: text/plain; charset=ISO-8859-1 Is that patch on git yet? i.e. if can I switch back to HEAD and change my files accordingly? Cheers, Rainer On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban < wxhgmqzgwmuf@spammotel.com> wrote: > Hi Eric, > > Eric Schulte wrote: > > Rainer M Krug writes: > > > >> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte >wrote: > >> > >>> > Perhaps inserting an assumed space separator would be more intuitive? > >>> > If we were to go that way it may be possible to allow variable > >>> > specifications such as > >>> > > >>> > #+PROPERTY: var foo=1 bar=2 > >>> > > >>> > in which case properties could be easily specified on multiple lines > >>> > using a default space separator. > >>> > > >>> > If this seems like a good way to go I can try to update my previous > >>> > patch. > >>> > >>> I've updated the patch, the newest version is attached. It results in > >>> the following behavior. > >> > >> Looks good to me - that leaves just the question, what would hppen when > >> doing the following: > >> > >> #+property: var foo=1 > >> #+property: var+ 2 > > > > The above is equivalent to, > > > > #+header: :var foo=1 2 > > > > which due to interaction with some logic put in place to allow the > > specification of un-named variables in call lines results in the > > following. > > > > #+property: var foo=1 > > #+property: var+ 2 > > #+begin_src emacs-lisp > > foo > > #+end_src > > > > #+results: > > : 2 > > > > #+begin_src emacs-lisp :var bar=1 2 > > bar > > #+end_src > > > > #+results: > > : 2 > > > > Although generally I would say that both > > > > #+header: :var foo=1 2 > > > > and > > > > #+property: var foo=1 > > #+property: var+ 2 > > > > are mal-formed variable assignments. > > I was amazed, yesterday, when you told about `foo' becoming `12' (with `1' > on > the assignment line and `2' on the continuation), but I'm glad you consider > this as rather ill-formed. > > >> and > >> > >> #+property: var foo="Hello " > >> #+property: var+ "world" > > > > This is exactly analogous to > > > > #+header: :var foo="hello" "world" > > > > which raises the expected error > > ``variable ""world"" must be assigned a default value'' > > > > the following alternative however works as expected > > > > #+property: var foo="Hello > > #+property: var+ world" > > #+begin_src emacs-lisp > > foo > > #+end_src > > > > #+results: > > : Hello world > > That said, all of these seem excellent trade-off between the different > alternatives that have been discussed and analyzed, and they respect > important > aspects: simplicity (intuitive on reading) and powerfulness. > > Just perfect! > > 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: Rainer@krugs.de Skype: RMkrug --001636426e11ddf20304b1c530a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is that patch on git yet? i.e. if can I switch back to HEAD and change my f= iles accordingly?

Cheers,

Rainer


On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban <wxhgmqzgwmuf@spammotel= .com> wrote:
Hi Eric,

Eric Schulte wrote:
> Rainer M Krug <r.m.krug@gmail= .com> writes:
>
>> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>>
>>> > Perhaps inserting an assumed space separator would be mor= e intuitive?
>>> > If we were to go that way it may be possible to allow var= iable
>>> > specifications such as
>>> >
>>> > #+PROPERTY: var foo=3D1 bar=3D2
>>> >
>>> > in which case properties could be easily specified on mul= tiple lines
>>> > using a default space separator.
>>> >
>>> > If this seems like a good way to go I can try to update m= y previous
>>> > patch.
>>>
>>> I've updated the patch, the newest version is attached. = =A0It results in
>>> the following behavior.
>>
>> Looks good to me - that leaves just the question, what would hppen= when
>> doing the following:
>>
>> #+property: var =A0foo=3D1
>> #+property: var+ 2
>
> The above is equivalent to,
>
> #+header: :var foo=3D1 2
>
> which due to interaction with some logic put in place to allow the
> specification of un-named variables in call lines results in the
> following.
>
> #+property: var =A0foo=3D1
> #+property: var+ 2
> #+begin_src emacs-lisp
> =A0 foo
> #+end_src
>
> #+results:
> : 2
>
> #+begin_src emacs-lisp :var bar=3D1 2
> =A0 bar
> #+end_src
>
> #+results:
> : 2
>
> Although generally I would say that both
>
> #+header: :var foo=3D1 2
>
> and
>
> #+property: var =A0foo=3D1
> #+property: var+ 2
>
> are mal-formed variable assignments.

I was amazed, yesterday, when you told about `foo' becoming= `12' (with `1' on
the assignment line and `2' on the continuation), but I'm glad you = consider
this as rather ill-formed.

>> and
>>
>> #+property: var =A0foo=3D"Hello "
>> #+property: var+ "world"
>
> This is exactly analogous to
>
> #+header: :var foo=3D"hello" "world"
>
> which raises the expected error
> =A0 ``variable ""world"" must be assigned a defaul= t value''
>
> the following alternative however works as expected
>
> #+property: var =A0foo=3D"Hello
> #+property: var+ world"
> #+begin_src emacs-lisp
> =A0 foo
> #+end_src
>
> #+results:
> : Hello world

That said, all of these seem excellent trade-off between the differen= t
alternatives that have been discussed and analyzed, and they respect import= ant
aspects: simplicity (intuitive on reading) and powerfulness.

Just perfect!

Best regards,
=A0Seb

--
Sebastien Vauban





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

Centre of Excellence for Invasion Biology
Stell= enbosch 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

--001636426e11ddf20304b1c530a6--