From: Adam Porter <adam@alphapapa.net>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] Org document concept + document property drawers
Date: Sun, 01 Sep 2019 11:11:22 -0500 [thread overview]
Message-ID: <87lfv8j8t1.fsf@alphapapa.net> (raw)
In-Reply-To: HE1PR02MB303355E7CFA73A78B7171D30DABF0@HE1PR02MB3033.eurprd02.prod.outlook.com
Gustav Wikström <gustav@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.
> [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.
next prev parent reply other threads:[~2019-09-01 16:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-31 18:49 [RFC] Org document concept + document property drawers Gustav Wikström
2019-09-01 5:20 ` Adam Porter
2019-09-01 10:38 ` Nicolas Goaziou
2019-09-01 14:41 ` Gustav Wikström
2019-09-06 20:09 ` Nicolas Goaziou
2019-09-29 9:39 ` Gustav Wikström
2019-09-01 15:25 ` Gustav Wikström
2019-09-01 16:11 ` Adam Porter [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-01 16:08 Gustav Wikström
2019-09-01 16:26 ` Adam Porter
2019-09-01 18:51 Gustav Wikström
2019-09-01 19:12 Gustav Wikström
2019-09-01 19:17 Gustav Wikström
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=87lfv8j8t1.fsf@alphapapa.net \
--to=adam@alphapapa.net \
--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).