emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Bastien <bzg@altern.org>
Cc: Org Mode List <emacs-orgmode@gnu.org>, mail@christianmoe.com
Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks"
Date: Wed, 02 Nov 2011 18:39:26 +0100	[thread overview]
Message-ID: <87obwuh19t.fsf@gmail.com> (raw)
In-Reply-To: <87hb2mo7ek.fsf@altern.org> (Bastien's message of "Wed, 02 Nov 2011 16:35:22 +0100")

Hello,

Bastien <bzg@altern.org> 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: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>           : @3$2=@1$2+@2$2::...
>           : @3$2=@1$2+@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	other threads:[~2011-11-02 17:40 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-31 19:06 About commit named "Allow multi-line properties to be specified in property blocks" Nicolas Goaziou
2011-10-31 20:05 ` Eric Schulte
2011-10-31 20:49   ` Nicolas Goaziou
2011-10-31 21:30     ` Eric Schulte
2011-11-01  8:24       ` Nicolas Goaziou
2011-11-01  8:36         ` Nicolas Goaziou
2011-11-01 14:36           ` Eric Schulte
2011-11-01 15:39             ` Nicolas Goaziou
2011-11-01 16:58               ` Eric Schulte
2011-11-01 17:48                 ` Christian Moe
2011-11-01 19:02                   ` Eric Schulte
2011-11-01 19:45                     ` Christian Moe
2011-11-01 20:22                       ` Eric Schulte
2011-10-31 21:33     ` Christian Moe
2011-10-31 21:22   ` Christian Moe
2011-10-31 21:36     ` Eric Schulte
2011-11-01  7:33       ` Christian Moe
2011-11-02 15:35     ` Bastien
2011-11-02 17:39       ` Nicolas Goaziou [this message]
2011-11-03  1:26         ` Bastien
2011-11-03  8:08           ` Christian Moe
2011-11-03 15:10             ` Nick Dokos
2011-11-03 18:32           ` Eric Schulte
2011-11-03 20:01             ` Nicolas Goaziou
2011-11-03 20:18               ` Eric Schulte
2011-11-03 20:23             ` Eric Schulte
2011-11-04  8:02               ` Rainer M Krug
2011-11-04 17:48                 ` Darlan Cavalcante Moreira
2011-11-04 19:25                   ` Eric Schulte
2011-11-07 22:09                     ` Eric Schulte
2011-11-08  8:42                       ` Rainer M Krug
2011-11-08  9:31                       ` Sebastien Vauban
2011-11-08  9:41                         ` Rainer M Krug
2011-11-08  9:58                           ` Sebastien Vauban
2011-11-08 10:06                             ` Rainer M Krug
2011-11-08 14:42                               ` Darlan Cavalcante Moreira
2011-11-08 15:06                                 ` Sebastien Vauban
2011-11-08 16:03                               ` Eric Schulte
2011-11-08 22:53                                 ` Eric Schulte
2011-11-09  8:25                                   ` Rainer M Krug
2011-11-09 16:12                                     ` Eric Schulte
2011-11-09 17:18                                       ` Rainer M Krug
2011-11-09 22:31                                       ` Sebastien Vauban
2011-11-15 12:33                                         ` Rainer M Krug
2011-11-15 16:00                                           ` Eric Schulte
2011-11-15 16:37                                             ` Torsten Wagner
2011-11-15 16:56                                               ` Eric Schulte
2011-11-15 17:13                                                 ` Thomas S. Dye
2011-11-15 18:22                                                   ` Eric Schulte
2011-11-15 17:24                                             ` Rainer M Krug
2011-11-08  9:41                 ` Sebastien Vauban
2011-11-08  9:44                   ` Rainer M Krug
2011-11-08 16:01                     ` Eric Schulte
2011-11-02 21:05 ` Samuel Wales
2011-11-02 21:21   ` Samuel Wales
2011-11-03  1:42   ` Bastien
2011-11-03  8:19     ` Christian Moe
2011-11-03 18:34     ` Eric Schulte
2011-11-03 18:59       ` Eric Schulte
2011-11-09 17:40       ` Samuel Wales

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87obwuh19t.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=bzg@altern.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=mail@christianmoe.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).