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