(Resending this mail due to formatting-issues. Sorry!) > From: Adam Porter > Subject: Re: [O] [RFC] Org document concept + document property drawers > Date: Sun, 01 Sep 2019 11:11:22 -0500 > > > #+begin_src org > > :PROPERTIES: > > :DIR: ~/ > > :ID: 730e0151-8e34-4dd9-b978-187c3c81e6b4 > > :CATEGORY: Test > > :END: > > > > Section 1 before first headline. > > > > ,* TODO Headline 1 > > Section 1 in first headline. > > > > ,** TODO Sub-headline 1 :Testtag: > > :PROPERTIES: > > :DIR: _2018/1809 Spark/ > > :CATEGORY: Test-cat > > :END: > > #+end_src > > If I may be honest, I don't feel very enthusiastic about this > document-level property drawer. I think it's because I'm accustomed to > thinking of property drawers as not affecting the entire document, and > expecting "#+KEYWORD:" for in-buffer settings.
You can think of property drawers in exactly the same way as before. There is nothing magical about this drawer. Just think of a document as a level-0 node. Things won't be inherited into level-1 and above nodes unless explicitly set so by your configuration. In exactly the same way as was previously done. To be clear - this property drawer is not a substitute for all kinds of keywords - this drawer only aims at substituting the "#+PROPERTY:" keyword. The end goal is alignment of functionality, to make it more obvious both in code and for the user what a property is and how it's defined. > I do recognize the advantage of being able to collapse them to hide > clutter. However, as the manual explains, almost the same benefit can > be achieved by putting them in an outline node at the bottom of the > file, or in another file altogether: > > In-buffer settings may appear anywhere in the file, either directly > or indirectly through a file included using `#+SETUPFILE: filename' > syntax. > > I usually put a "Config" or "Footer" node at the bottom of the file, > marked "COMMENT" and ":noexport:", containing such settings that I don't > want cluttering the top of the file. Configurations is something else than setting properties in my opinion. I've addressed configurations in my first mail (calling them "settings", but "options" or "config" can be seen as synonyms if you like). Keywords today is a source of confusion. They are the multi-purpose swiss army knife for everything that didn't fit elsewhere. I'd like to change that too - I've done a fairly rigorous investigation of the multiple uses of keywords today. Simplifying how we use keywords will aid both users and plug-in developers, I'm sure. But that, too, is another topic! Not something that is a part of the patch I'm bringing forward here anyways. > >  Sidenote: We already define projects today when we declare that > > multiple files together are seen as our "agendas" for example. Or when > > we configure publishing. But we lack a common framework for what a > > "project" is in our code. > > As you said, that's another issue--however, if I may, I'll point out > that that's your concept of what "project" means, and not all users > think of a "project" in those terms. For example, it's not at all what > it means in "GTD" terms, which many Org users think in. Yes, project can be a dangerous word. A word of many meanings. I'm not very attached to it in this context but think it fits well even though it is overloaded. I'm a GTD'er myself and have learnt to separate the meaning of the word (any overloaded word really) depending on context. "Collection" might be another fitting word for what I have in mind. I'm not sure this thread is the place to share my thoughts about Org mode projects/collections though. We can start a separate thread for that if you like! Humbly Gustav