emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Marco Wahl <marcowahlsoft@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Document level property drawer
Date: Fri, 04 Oct 2019 12:38:57 +0200	[thread overview]
Message-ID: <84d0fciym6.fsf@gmail.com> (raw)
In-Reply-To: 87imp5bs0c.fsf@alphapapa.net

Adam Porter <adam@alphapapa.net> writes:

> Gustav Wikström <gustav@whil.se> 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.

IIUC Org files not using a file level property drawer would not be
affected from the change at all.  With the proposition the user gets a
further option to define a file wide property.

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

The proposal is an extension leaving all operations and tools intact for
Org files not using the file wide property drawer AFAICS.  If a tool
depends on a file wide property then it needs to be adapted.  Possibly
this could be called "breaking" but I think this should not hold back
the proposal.

One could even think about letting fade out the "#+"-file-wide property
definition syntax or at least think about a good place within a file or
a subtree for those definitions.  (There is at least Sebastian Miele who
wants to keep that syntax as he stated in another thread AFAIR.)

Personally I think it's a good idea to work for an Org mode where an Org
file behaves very much like an Org subtree.


Ciao,
-- 
Marco

  reply	other threads:[~2019-10-04 10:39 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-30 22:09 [RFC] Document level property drawer Gustav Wikström
2019-10-03 18:31 ` Adam Porter
2019-10-04 10:38   ` Marco Wahl [this message]
2019-10-06  1:01     ` Adam Porter
2019-10-07  7:46       ` Marco Wahl
  -- strict thread matches above, loose matches on Subject: below --
2019-10-24 22:29 Gustav Wikström
2019-10-20  2:28 Gustav Wikström
2019-10-22 21:24 ` Marco Wahl
2019-10-23  8:43 ` Marco Wahl
2019-10-23  8:59   ` Gustav Wikström
2019-10-24 21:01   ` Gustav Wikström
2019-10-25 12:58     ` Marco Wahl
2019-10-23 16:08 ` Adam Porter
2019-10-06  6:02 Gustav Wikström
2019-10-06  5:35 Gustav Wikström
2019-10-05 18:20 Gustav Wikström
2019-10-06  0:51 ` Adam Porter
2019-10-02 20:29 Gustav Wikström
2019-09-29 10:27 Gustav Wikström
2019-09-29 19:13 ` Marco Wahl
2019-09-30 16:01 ` Adam Porter
2019-09-30 20:46   ` Marco Wahl
2019-10-01 12:38     ` Sebastian Miele
2020-01-13 21:52       ` Marco Wahl
2020-01-15  8:18         ` Sebastian Miele
2020-02-01 19:59           ` Marco Wahl
2019-10-01 13:55     ` Adam Porter
2019-10-02 10:29       ` Marco Wahl
2019-10-03 18:06         ` Adam Porter
2019-10-04 11:05           ` Marco Wahl
2019-10-06  1:05             ` Adam Porter
2019-10-06  5:10               ` Matt Price
2019-10-15 17:49 ` Gustav Wikström
2019-10-16  0:48   ` Adam Porter
2019-10-16  9:48   ` Marco Wahl

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=84d0fciym6.fsf@gmail.com \
    --to=marcowahlsoft@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).