Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Hello,

Eric Schulte <address@hidden> writes:

> Nicolas Goaziou <address@hidden> 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