From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: About commit named "Allow multi-line properties to be specified in property blocks" Date: Wed, 02 Nov 2011 18:39:26 +0100 Message-ID: <87obwuh19t.fsf@gmail.com> References: <87vcr5c76e.fsf@gmail.com> <87vcr5j5a5.fsf@gmail.com> <4EAF118C.8050806@christianmoe.com> <87hb2mo7ek.fsf@altern.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:32847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLeo0-00009B-DG for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 13:40:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLeny-0000WH-8E for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 13:40:52 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:54147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLeny-0000W1-13 for emacs-orgmode@gnu.org; Wed, 02 Nov 2011 13:40:50 -0400 Received: by wwe3 with SMTP id 3so489735wwe.30 for ; Wed, 02 Nov 2011 10:40:49 -0700 (PDT) In-Reply-To: <87hb2mo7ek.fsf@altern.org> (Bastien's message of "Wed, 02 Nov 2011 16:35:22 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: Org Mode List , mail@christianmoe.com Hello, Bastien 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