From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: property searches for #+CATEGORY Date: Wed, 7 Nov 2007 17:15:55 +0100 Message-ID: References: <20071107111730.GH13544@atlantic.linksys.moosehall> <3d6808890711070523u50bd8bbp963960978171e132@mail.gmail.com> <20071107133404.GL13544@atlantic.linksys.moosehall> <3d6808890711070559x3b24ed3djc4276fdc09d074a9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iposq-0003EQ-5P for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:40:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iposn-0003Bb-6w for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:40:06 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iposn-0003BR-2R for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:40:05 -0500 Received: from hu-out-0506.google.com ([72.14.214.226]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iposn-00049d-08 for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:40:05 -0500 Received: by hu-out-0506.google.com with SMTP id 23so1159902huc for ; Wed, 07 Nov 2007 09:40:02 -0800 (PST) In-Reply-To: <3d6808890711070559x3b24ed3djc4276fdc09d074a9@mail.gmail.com> 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: Tim O'Callaghan Cc: org-mode mailing list Thanks for an interesting discussion about the merits of properties versus tags etc. Very illuminating. 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 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. But for the search interface, to allow CATEGORY="work", I think that would be a safe thing to do. Will be in 5.14, unless I hear good arguments against this. - Carsten On 7Nov2007, at 2:59 PM, Tim O'Callaghan wrote: > On 07/11/2007, Adam Spiers wrote: >> On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote: >>> On 07/11/2007, Adam Spiers wrote: >>>> I have several personal .org files, and several work-related >>>> ones too. >>>> In each personal file, I have a line: >>>> >>>> #+CATEGORY: personal >>>> >>>> and in each work-related file, I have a line: >>>> >>>> #+CATEGORY: work >>>> >>>> I would like to be able to bind agenda custom commands to do tag >>>> searches which are narrowed to one of these categories, e.g. >>>> "show me >>>> all personal priority #A tasks". Such a search needs to span *all* >>>> agenda files, therefore the standard per-buffer narrowing >>>> provided by >>>> the '<' binding in the *Agenda Commands* buffer is insufficient. >>>> >>>> Would it make sense to include CATEGORY as a special property? >>>> After >>>> all, pretty much all other per-task meta-data ("TODO", "PRIORITY" >>>> etc.) are already available via the property interface, and this >>>> way, >>>> I could easily achieve what I need with tag searches such as >>>> >>>> CATEGORY="personal"+PRIORITY="A" >>>> >>>> Thanks! >>> >>> It would seem to me that this is exactly what tags does. >>> You could move everything down a level and use tag inheritance: >>> * personal stuff :personal: >>> * work stuff :work: >> >> I could, but this would mean that each file would have a single >> top-level entry, and the entire contents would be indented an extra >> level, which I fear is a rather unattractive solution! >> > > It's the technique i've been using, and yes, it is unattractive. > > When i thought of tags, it was not explicitly for GTD context > specifier, it was also for adding searchable metadata to a todo node. > I'm finding out that it gets diluted somewhat. > > It guess its a matter of taxonomy. Roughly i would see this as: > > 1. State - TODO - DO/CANCEL/DONE > 2. Context - tags - :@home:@phone: > 3. Date/Time - <2007-10-10> > 4. Meta Context - Category - personal, work etc, > 5. Meta State - Properties drawer - :EMAIL:emacs-orgmode@gnu.org > 6. Meta DateTime - state/time logging - > > How about adding the context to the tag table with a prefix > character, say #? > > Tim. > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode