From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: property searches for #+CATEGORY Date: Wed, 7 Nov 2007 13:52:35 +0000 Message-ID: <20071107135235.GM13544@atlantic.linksys.moosehall> References: <20071107111730.GH13544@atlantic.linksys.moosehall> <871wb2p2f9.fsf@bzg.ath.cx> Reply-To: Adam Spiers 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 1IplKi-0001o7-FG for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 08:52:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IplKh-0001mv-Qf for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 08:52:40 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IplKh-0001mk-Ld for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 08:52:39 -0500 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IplKh-00070k-7M for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 08:52:39 -0500 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id lA7DqcWR025144 for ; Wed, 7 Nov 2007 07:52:38 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id lA7Dqb2G025139 for emacs-orgmode@gnu.org; Wed, 7 Nov 2007 13:52:37 GMT Content-Disposition: inline In-Reply-To: <871wb2p2f9.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: emacs-orgmode@gnu.org On Wed, Nov 07, 2007 at 02:15:22PM +0000, Bastien wrote: > I understand now. > > I think it would be clearer to distinguish between categorizing files > and categorizing tasks. In a sense, using #+CATEGORY across several > files (as you do) is more a way to group these files under the same > ombrella (conveniently called "category"), rather than to group all > tasks below each #+CATEGORY in the same category. > > Let me say it with other words: if several files share the same > #+CATEGORY, then this bit of information won't be of any help to > distinguish between these files' tasks, it will only help separating > files with #+CATEGORY: A from files with #+CATEGORY: B. That's exactly right. > Then I think the right solution would be to have groups of agenda files. > Something like: > > #+AGENDA_GROUP: personal > > 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. > My other concern is that the functionality you're requesting would > resurrect #+CATEGORY, while this functionality was mostly maintained > for backward compatibility -- at least I understood it like that. 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 docs say: (1) If there are several such lines in a file, each specifies the category for the text below it. The first category also applies to any text before the first CATEGORY line. This method is only kept for backward compatibility. The preferred method for setting multiple categories in a buffer is using a 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. > PS: Personally, the problem you encounter is exactly the one that > led me to use a single (really) big Org file. But this is entirely > personal, of course! I already have too many problems keeping a good work/life balance! ;-) But also I replicate my TODO files between machines, some owned by me and some by my company, and like to keep replication of company data separate from personal.