From: "Gustav Wikström" <gustav@whil.se>
To: "adam@alphapapa.net" <adam@alphapapa.net>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Org document concept + document property drawers
Date: Sun, 1 Sep 2019 18:51:54 +0000 [thread overview]
Message-ID: <HE1PR02MB303347649ADAF4DEF535CD86DABF0@HE1PR02MB3033.eurprd02.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]
> 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
[-- Attachment #2: Type: text/html, Size: 11240 bytes --]
next reply other threads:[~2019-09-01 18:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-01 18:51 Gustav Wikström [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-01 19:17 [RFC] Org document concept + document property drawers Gustav Wikström
2019-09-01 19:12 Gustav Wikström
2019-09-01 16:08 Gustav Wikström
2019-09-01 16:26 ` Adam Porter
2019-08-31 18:49 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
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=HE1PR02MB303347649ADAF4DEF535CD86DABF0@HE1PR02MB3033.eurprd02.prod.outlook.com \
--to=gustav@whil.se \
--cc=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).