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

[Bastien]

Hi Nicolas,

Nicolas Goaziou <address@hidden> writes:

> For the sake of consistency, I would suggest to drop the export back-end
> relative keywords. "#+html:" and "#+latex:" are indeed disturbing
> exceptions to the rule. They are also not so convenient (a net gain of
> 2 lines).

Why not.  But let's not break backward compatibility just for the 
sake of consistency.

>> 2) "Cumulative properties"?
>>
>>    Here is a suggestion: use a syntaxe like
>>  
>>    #+var: foo 1
>
> There is also "#+bind:", whose purpose is close enough.

Indeed.  Eric, would it be possible to use 

#+bind foo 1 

instead of 

#+property var foo=1

?

>> 3) Wrapping/folding long #+xxx lines?
>>
>>    This is an independant request -- see Robert McIntyre's recent
>>    question on the list.  The problem is that fill-paragraph on
>>    long #+xxx lines breaks the line into comment lines, which is 
>>    wrong.  Filling like this:
>>
>>    #+TBLFM: @address@hidden@2$1::@address@hidden@2$2::...::...
>>           : @address@hidden@2$2::...
>>           : @address@hidden@2$2::...
>
> #+tblfm: ...
> #+tblfm: ...
> #+tblfm: ...

Not very elegant, but perhaps more efficient/consistent.

>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>>    keywords.  This would make the current
>>    org-internals-oriented/content-oriented difference between #+xxx
>>    and #+begin_xxx obsolete
>
> I suggest to avoid such a thing. Here are a few, more or less valid,
> reasons:
>
>   - That distinction is useful for the user (clear separation between
>     contents and Org control).
>   - It would penalize usage of special blocks.
>   - The need is localized to very few keywords: it isn't worth the added
>     complexity.
>   - It would be ugly: no more nice stacking of keywords, but a mix of
>     blocks and keywords, and blocks on top of blocks... Org syntax may
>     not be the prettiest ever, it doesn't deserve that.
>   - It would be a real pain to parse.

Well, I agree with most of the reasons.  Glad you stated them clearly.

>>    but this would spare us the cost of new syntax.
>
> On the contrary, creating a block for each keyword would mean a lot of
> new syntax.
>
> We currently have 8 types of blocks (not counting dynamic blocks, whose
> syntax is a bit different), all requiring to be parsed differently:
>
>   1. Center blocks,
>   2. Comment blocks,
>   3. Example blocks,
>   4. Export blocks,
>   5. Quote blocks,
>   6. Special blocks,
>   7. Src blocks,
>   8. Verse blocks.

I'm not sure what do you mean by "requiring to be parsed differently".
Can you explain it?  I understand they should be treated differently by
the exporters, but I don't understand why they would need to be parsed
differently.

My idea was to avoid parsing both #+html and #+begin_html.  And that 
#+begin_xxx syntax is already available for folding, which is a feature 
we might want for #+text and keywords like that.

I would suggest this rule: #+begin_ is always for _content_
while #+keyword is always for internals that are removed when 
exporting.  #+text, #+html, #+LaTeX are a few exception I can
think of.

Best,

-- 
 Bastien