Re: property searches for #+CATEGORY

[Adam Spiers <orgmode@adamspiers.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.