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 18:51:54 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_HE1PR02MB303347649ADAF4DEF535CD86DABF0HE1PR02MB3033eurp_" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:45274) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4UxF-00039N-NP for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 14:52:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4UxD-0001he-Tr for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 14:52:01 -0400 Received: from mail-eopbgr80099.outbound.protection.outlook.com ([40.107.8.99]:64996 helo=EUR04-VI1-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 1i4UxD-0001cc-GB for emacs-orgmode@gnu.org; Sun, 01 Sep 2019 14:51:59 -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" --_000_HE1PR02MB303347649ADAF4DEF535CD86DABF0HE1PR02MB3033eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > 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 --_000_HE1PR02MB303347649ADAF4DEF535CD86DABF0HE1PR02MB3033eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> From:   &nb= sp;         Adam Porter<= /span>

 

> > #+begin_src org

> >   :PROPERTI= ES:

> >   :DIR: ~/<= o:p>

> >   :ID: 730e= 0151-8e34-4dd9-b978-187c3c81e6b4

> >   :CATEGORY= : Test

> >   :END:

> >

> >   Section 1= before first headline.

> >

> >   ,* TODO H= eadline 1

> >   Section 1= in first headline.

> >

> >   ,** TODO = Sub-headline 1          &= nbsp;           &nbs= p;     :Testtag:

> >   :PROPERTI= ES:

> >   :DIR:&nbs= p;     _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 dr= awer.  I think it's because I'm accustomed to

> thinking of property drawe= rs as not affecting the entire document, and

> expecting "#+KEYW= ORD:" for in-buffer settings.

 

You can think of property drawe= rs 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 "#+PR= OPERTY:" 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 advanta= ge of being able to collapse them to hide

> clutter.  However, as= the manual explains, almost the same benefit can

> be achieved by putting the= m in an outline node at the bottom of the

> file, or in another file a= ltogether:

>

>     In= -buffer settings may appear anywhere in the file, either directly

>     or= indirectly through a file included using `#+SETUPFILE: filename'<= /o:p>

>     sy= ntax.

>

> I usually put a "Conf= ig" 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 els= e than setting properties in my opinion.

I've addressed configurations i= n my first mail (calling them "settings",

but "options" or &quo= t;config" can be seen as synonyms if you like).

Keywords today is a source of c= onfusion. 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 f= airly rigorous investigation of the

multiple uses of keywords today= . Simplifying how we use keywords will

aid both users and plug-in deve= lopers, I'm sure. But that, too, is

another topic! Not something th= at is a part of the patch I'm bringing

forward here anyways.

 

> > [1] Sidenote: We alre= ady define projects today when we declare that

> > multiple files togeth= er are seen as our "agendas" for example. Or when

> > we configure publishi= ng. But we lack a common framework for what a

> > "project" i= s in our code.

>

> As you said, that's anothe= r issue--however, if I may, I'll point out

> that that's your concept o= f what "project" means, and not all users

> think of a "project&q= uot; 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 con= text 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 overlo= aded 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 thoug= h. We can start a separate thread for

that if you like!

 

Humbly

Gustav

--_000_HE1PR02MB303347649ADAF4DEF535CD86DABF0HE1PR02MB3033eurp_--