From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Gustav_Wikstr=F6m?= Subject: Re: [RFC] Org document concept + document property drawers Date: Sun, 1 Sep 2019 19:17:50 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48528) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4VMO-0002ff-As for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:18:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4VMM-00057t-6N for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:18:00 -0400 Received: from mail-eopbgr70128.outbound.protection.outlook.com ([40.107.7.128]:63965 helo=EUR04-HE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i4VMI-00055c-Q2 for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 15:17:56 -0400 Content-Language: en-US List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "adam@alphapapa.net" Cc: "emacs-orgmode@gnu.org" (Resending this mail due to formatting-issues. Sorry!) > From: Adam Porter > Subject: Re: [O] [RFC] Org document concept + document property drawers > Date: Sun, 01 Sep 2019 11:11:22 -0500 > > > #+begin_src org > >=A0=A0 :PROPERTIES: > >=A0=A0 :DIR: ~/ > >=A0=A0 :ID: 730e0151-8e34-4dd9-b978-187c3c81e6b4 > >=A0=A0 :CATEGORY: Test > >=A0=A0 :END: > > > >=A0=A0 Section 1 before first headline. > > > >=A0=A0 ,* TODO Headline 1 > >=A0=A0 Section 1 in first headline. > > > >=A0=A0 ,** TODO Sub-headline 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 :Testtag: > >=A0=A0 :PROPERTIES: > >=A0=A0 :DIR:=A0=A0=A0=A0=A0 _2018/1809 Spark/ > >=A0=A0 :CATEGORY: Test-cat > >=A0=A0 :END: > > #+end_src >=20 > If I may be honest, I don't feel very enthusiastic about this > document-level property drawer.=A0 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.=A0 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: >=20 >=A0=A0=A0=A0 In-buffer settings may appear anywhere in the file, either di= rectly >=A0=A0=A0=A0 or indirectly through a file included using `#+SETUPFILE: fil= ename' >=A0=A0=A0=A0 syntax. >=20 > 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.=20 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. >=20 > 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.=A0 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=20 that if you like! Humbly Gustav