From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks" Date: Tue, 15 Nov 2011 09:00:15 -0700 Message-ID: <87zkfxml4g.fsf@gmail.com> References: <87vcr5c76e.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: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:48447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQLQy-0006tl-ES for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 11:00:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQLQu-0007ki-BF for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 11:00:28 -0500 Received: from mail-pz0-f47.google.com ([209.85.210.47]:38235) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQLQu-0007kZ-4s for emacs-orgmode@gnu.org; Tue, 15 Nov 2011 11:00:24 -0500 Received: by pzk1 with SMTP id 1so14228632pzk.6 for ; Tue, 15 Nov 2011 08:00:23 -0800 (PST) In-Reply-To: (Rainer M. Krug's message of "Tue, 15 Nov 2011 13:33:13 +0100") 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: Rainer M Krug Cc: emacs-orgmode@gnu.org Rainer M Krug writes: > Is that patch on git yet? i.e. if can I switch back to HEAD and change my > files accordingly? > Hi Rainer, I've must merged all of the pending code block changes into the master branch of the Org-mode git repository. So now would be a good time to re-sync with the master branch. Best -- Eric > > 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 >> >> >> -- Eric Schulte http://cs.unm.edu/~eschulte/