From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: [RFC] Document level property drawer Date: Thu, 03 Oct 2019 13:31:15 -0500 Message-ID: <87imp5bs0c.fsf@alphapapa.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:42868) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iG5sx-000630-6x for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:31:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iG5st-0002eb-Ff for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:31:31 -0400 Received: from 195-159-176-226.customer.powertech.no ([195.159.176.226]:38216 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iG5st-0002eH-8X for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 14:31:27 -0400 Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1iG5sq-000E1E-N0 for emacs-orgmode@gnu.org; Thu, 03 Oct 2019 20:31:24 +0200 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" To: emacs-orgmode@gnu.org Hi Gustav, Gustav Wikström writes: > I'd argue that precedence already works that way. One has to take > inheritance into account. With inheritance turned on, tell me which > value for Property1 is used for the nodes in the following example: > > #+begin_src org > ,* Node 1 > ,* Node 2 > :PROPERTIES: > :Property1: Value1 > :END: > > ,#+PROPERTY: Property1 Value2 > #+end_src > > As you'll see line number already isn't the deciding factor. > > With two ways to define properties it makes sense to first think of > which syntax to promote as "more important" and then to think of > precedence rules for duplicates within each syntax. > > Having the same syntax for node level 0 as for regular nodes makes the > property functionality easy to understand and congruent. Something I > think is worth promoting by saying that property blocks on file-level > has precedence over the keyword syntax. I think this example illustrates the issue better. This is how Org currently works: #+BEGIN_SRC org # Category here is "Alpha" ,* Node 1 # Category here is "Alpha" ,* Node 2 :PROPERTIES: :CATEGORY: Beta :END: # Category here is "Beta" ,#+CATEGORY: Alpha #+END_SRC IIUC, your proposal would work like this: #+BEGIN_SRC org :PROPERTIES: :CATEGORY: Gamma :END: # Category here is "Gamma" ,* Node 1 # Category here is "Gamma" ,* Node 2 :PROPERTIES: :CATEGORY: Beta :END: # Category here is "Beta" ,#+CATEGORY: Alpha #+END_SRC So the #+CATEGORY: line has no effect because of the first-line property drawer. In Org, some keywords are special, like #+CATEGORY. For many years, such keywords have had file-wide effects regardless of their placement in the file. IIUC, your proposal would change that, and that would still be a major, breaking change. > If you think of the document as an outline, something Org mode is all > about, it makes sense to also think of things before the first > headline as "node level 0". And with that way of conceptually thinking > of the document it makes perfect sense to have a property drawer fixed > at the top - in the same way as it is required for all other node > levels. What you're proposing is actually a fundamental change to the way Org documents are interpreted. Org documents are not currently an outline, just a series of elements which may include an outline. Text and elements before a first heading are not part of a node, they're just text and elements in the document. If Org were a new project, I think your proposal might be very suitable. But at this point, it would be a significant, breaking change, even without the org-element parser changes. Consider as well that the Org format has recently been seeing wider use, with more implementations becoming available in several languages and on several platforms. Fundamental changes like this would affect more than just the official Org software, and the costs of breaking software in the wider Org community should be carefully considered.