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

[Adam Porter]

Gustav Wikström <address@hidden> writes:

> Nicolas requested a more thorough introduction to the patch so here it
> comes.

Thank you, this is helpful.

> The first patch deals with formalities. It introduces one new greater
> element called "document". Parsers and everything around it are
> modified to work with this new concept. No new functionality is
> introduced. I'd call this patch an "enabler" since it allows us to
> (hopefully) reason better about intended behaviors and such moving
> forward, but doesn't really do anything.

I guess you mean that no new user-facing functionality is introduced,
because it does introduce new functionality into the code, and as you
say, it modifies "parsers and everything around it."

> The second patch introduces property-drawers on document level. No
> existing code will stop working, i.e. property keywords and all other
> keywords will behave just as today.

In my previous message in this thread, I asked about third-party
packages and how your code may impact them.  Would you please address
that question specifically?  Have you investigated this concern at all?


I'm especially concerned about the results of org-element parsing
functions changing, e.g. being nested inside an extra level of something
like (document ...) would likely break a lot of code.  As well, code
that expects to find "in-buffer settings" in the form of "#+KEYWORD:",
having been parsed by org-element, won't work properly if instead it
finds document-level property drawers that are supposed to apply to the
entire buffer.  It's a very significant change that would have rippling
effects on downstream code.

> The first five lines in the following example will work just as
> property drawers inside headings with this patch. All commands and
> functions that work with "regular" property-drawers are updated to
> work also with this document level drawer.
>
> #+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.

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.

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