From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: property searches for #+CATEGORY Date: Thu, 8 Nov 2007 09:54:08 +0100 Message-ID: References: <20071107111730.GH13544@atlantic.linksys.moosehall> <3d6808890711070523u50bd8bbp963960978171e132@mail.gmail.com> <20071107133404.GL13544@atlantic.linksys.moosehall> <3d6808890711070559x3b24ed3djc4276fdc09d074a9@mail.gmail.com> <87ir4dl4kb.fsf@bzg.ath.cx> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iq39V-00072U-12 for emacs-orgmode@gnu.org; Thu, 08 Nov 2007 03:54:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iq39U-000729-3x for emacs-orgmode@gnu.org; Thu, 08 Nov 2007 03:54:16 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iq39T-000726-WC for emacs-orgmode@gnu.org; Thu, 08 Nov 2007 03:54:16 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iq39T-0007QB-09 for emacs-orgmode@gnu.org; Thu, 08 Nov 2007 03:54:15 -0500 Received: by ug-out-1314.google.com with SMTP id a2so323592ugf for ; Thu, 08 Nov 2007 00:54:13 -0800 (PST) In-Reply-To: <87ir4dl4kb.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org On 8Nov2007, at 5:55 AM, Bastien wrote: > Carsten Dominik writes: > >> However, I do think that Adam's initial request to make the >> category available as a special property for queries in not >> unreasonble. Or does anyone disagree? > > I'm convinced it's not unreasonable :) > >> I am not sure, though, if the #+CATEGORY category should be >> available with `org-entry-get', because it would then be very >> hard for the property API to make a difference between a value >> that is intimately associated with the current entry, and a >> value that might be derived by some other mechanism. So here I >> differ somewhat from Adam's feeling that category is just like >> TODO or a tag. It is different. > > Then a search like CATEGORY="cat" would also return entries which > CATEGORY property is not "cat"... ok, maybe this doesn't hurt that > much for search purposes. But I expect someone will come in three > month complaining that `org-entry-get' didn't return the category, > even though he set it up through #+CATEGORY. OK, here is what we will do. We will make `org-entry-get' return a value from #+CATEGORY if the INHERIT flag is set in the call to `org-entry-get'. In this case the value is inherited not from a higher level entry, but for the "file environment", and even top-level outline entries can ihnerit it. We actually already have this mechanism: #+PROPERTY: Name Value So we could then see #+CATEGORY: work as a short-hand for #+PROPERTY: CATEGORY work ... which makes all of this suddenly look as if it was designed like this from the beginning. I like it. Thanks again to everyone who contributed to this discussion. - Carsten