From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks" Date: Tue, 01 Nov 2011 09:24:04 +0100 Message-ID: <87y5w0ckt7.fsf@gmail.com> References: <87vcr5c76e.fsf@gmail.com> <87vcr5j5a5.fsf@gmail.com> <8762j4evjl.fsf@gmail.com> <87k47kkfwp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:39073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RL9f1-0007vQ-Ic for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 04:25:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RL9ew-0006lG-L3 for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 04:25:31 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:65407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RL9ew-0006kr-GU for emacs-orgmode@gnu.org; Tue, 01 Nov 2011 04:25:26 -0400 Received: by wyg24 with SMTP id 24so1878932wyg.0 for ; Tue, 01 Nov 2011 01:25:25 -0700 (PDT) In-Reply-To: <87k47kkfwp.fsf@gmail.com> (Eric Schulte's message of "Mon, 31 Oct 2011 15:30:30 -0600") 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: Org Mode List Hello, Eric Schulte writes: > Nicolas Goaziou writes: > >> Well, what about: >> >> #+property: :var foo=1 >> #+property: :var bar=2 >> #+property: :var baz=3 >> #+property: :var qux=4 > Unfortunately this won't work, the final value of the "var" property > will be "qux=4" rather than "foo=1, bar=2, baz=3, qux=4". I know that it won't work, as "#+begin_property" didn't work before you introduced it. The idea is to make that work instead (with or without the colons in front of "var"). > I would say that the block is defining an keyword, but yes, I suppose > we've never had a multi-line keyword definition structure. I differentiate keywords and blocks from their usage. As such, blocks are not defining a keyword. They're not even in the same league. > Along these lines I would also like to allow TBLFM lines to be broken > over multiple lines, as I often find myself right-scrolling in a buffer > to find equations in large spreadsheets. I wonder if there would be a > general solution to allow *all* #keyword+ lines to have a block > equivalent. The solution I implemented in my document on Org syntax is to create two keyword's families: cumulative and dual. Belonging to the first one means a keyword accumulates its values on multiple calls instead of replacing them. That's how I parse "#+headers:" or "#+attr_latex" lines, for example. The second one allows the keyword to have a secondary, optional, value, in square brackets. This is useful for keywords like "#+results:", which can include an hash value like "#+results[hash-string]: keyword-value". Typically, what is required here is to add "#+property:" to the cumulative family. Thus, #+property: var foo=1 #+property: var bar=2 is exactly the same as #+property: var foo=1 var bar=2. Also, make sure var assignations accumulate too. > I don't know how #+text: works, but with #+header: the order of the > blocks is not important, i.e., > > #+headers: :var a=1 > #+headers: :cache a=2 > > is equal to > > #+headers: :cache a=2 > #+headers: :var a=1 > > but the same is not true for > > #+PROPERTY: var foo=1, > #+PROPERTY+: bar=2 > > and > > #+PROPERTY+: bar=2 > #+PROPERTY: var foo=1, Because, again, "#+property+:" isn't a great idea. Here, "#+headers:" accumulates its values. Make the same for "#+property:" and we're all set. >> It is desirable to have a logic behind syntax, and to always refer to >> it. Thus, is is desirable to separate syntax used for contents from >> syntax used for Org control. It's very different from "things on >> a single line vs things on multiple lines". > Sure, but to play devils (or my own) advocate, I would say that > simplicity is important and "blocks for multi-line content" is a simpler > rule than "blocks for formatting of multi-line content, and for naming > multi-line data", the second being the case with code and example > blocks. What? Blocks do not name anything. In the case of code and example blocks, you specify Org how to format/understand the contents, like any other block. You use "#+name:" to name them. Again, the rule is simple: blocks are directly related to contents, keywords aren't. Corollary is: no block with only options and no contents. > My goal here is to find the most natural solution which conforms to > Org-modes design as well as possible, I just don't know what that > would be... We share the same goal. Regards, -- Nicolas Goaziou