Hello, Eric Schulte <schulte.e...@gmail.com> writes:
> Nicolas Goaziou <n.goaz...@gmail.com> 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
