Re: [O] [RFC] Org document concept + document property drawers

[Gustav Wikström]

> From:             Adam Porter

 

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

 

> > [1] 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