From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: property searches for #+CATEGORY Date: Wed, 07 Nov 2007 17:16:26 +0000 Message-ID: <878x5am0wl.fsf@bzg.ath.cx> References: <20071107111730.GH13544@atlantic.linksys.moosehall> <871wb2p2f9.fsf@bzg.ath.cx> <20071107135235.GM13544@atlantic.linksys.moosehall> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ipna1-0002E8-2W for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 11:16:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpnZz-0002AI-GB for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 11:16:36 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpnZz-00029m-5i for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 11:16:35 -0500 Received: from ik-out-1112.google.com ([66.249.90.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IpnZy-0006Fe-Q1 for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 11:16:35 -0500 Received: by ik-out-1112.google.com with SMTP id c29so1473912ika for ; Wed, 07 Nov 2007 08:16:33 -0800 (PST) In-Reply-To: <20071107135235.GM13544@atlantic.linksys.moosehall> (Adam Spiers's message of "Wed, 7 Nov 2007 13:52:35 +0000") 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: emacs-orgmode@gnu.org Adam Spiers writes: >> This would let you restrict any agenda search to a group of agenda >> files. I don't want to digg too far in this direction, but I think >> there are a few other things for which such groups might be useful >> (e.g. publish agenda files per group...) > > Well, the documentation says > > The category is a broad label assigned to each agenda item. By > default, the category is simply derived from the file name, [...] > > so I thought this use case was pretty much exactly what it was > intended for. Lets say that #+CATEGORY is more oriented toward files grouping, and :CATEGORY: is more oriented toward tasks grouping. In fact, when using several #+CATEGORY in the same file (as it is *not* recommended to do), you are virtually splitting your file into several files, each of them corresponding to a category. Your request was to be able to perform a search using #+CATEGORY as a way to search through multiple files. I can see to ways of doing this: 1. implicitely add the #+CATEGORY value of a file to each entry in this file, and search through files having the same #+CATEGORY; 2. clearly separate the group of files from the group of tasks, and perform a group-restricted search. I think (1) is problematic: what if a file has a top #+CATEGORY and several :CATEGORY: properties? What about precedence and inheritance? How to build the search string if we want to search through several :CATEGORY: properties in a single #+CATEGORY ? > No, I don't think it's #+CATEGORY per se which is only there for > backward compatibility - it's using it multiple times within a single > file. The fact that only *one* instance of #+CATEGORY is allowed in a file calls itself for the divorce between #+CATEGORY (possibly renamed as #+GROUP) and the :CATEGORY: property... >> It's not that easy for users to understand how to user categories, >> and staying with two ways of setting them might be confusing IMO. > > Surely this is an argument against introducing yet another grouping > mechanism! We already have tags, properties, and categories. But a category is just a property, even if the search interface raises this property above others. And besides these search considerations, I really believe that having several groups of agenda-files would help. > I already have too many problems keeping a good work/life balance! ;-) Com'on, our daily brain-sport is to feed this list! :) -- Bastien