emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Nicolas Goaziou
Subject: Re: [O] About commit named "Allow multi-line properties to be specified in property blocks"
Date: Wed, 02 Nov 2011 18:39:26 +0100

Hello,

Bastien <address@hidden> writes:

> 1) Consistent syntax for #+xxx and #+begin_xxx?
>
>    Nicolas point is valid -- #+begin_xxx syntax is about content and
>    formatting, not about Org's internal.  #+xxx is mostly about Org's
>    internals (#+author, #+date, #+property, etc) and sometimes about
>    content, as a convenient way of inserting one-line content block
>    (#+html, #+LaTeX, etc)

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).

>
> 2) "Cumulative properties"?
>
>    Here is a suggestion: use a syntaxe like
>  
>    #+var: foo 1

There is also "#+bind:", whose purpose is close enough.

> 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: ...

may be more intrusive, but also more consistent with "#+text:" and
"#+headers:" keywords.

>    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.

>    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.

While others may sparingly be added in the future, I don't think
introducing scores of them at the same time would help clarifying Org's
syntax.


Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]