From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: property searches for #+CATEGORY Date: Wed, 7 Nov 2007 17:23:02 +0000 Message-ID: <20071107172302.GR13544@atlantic.linksys.moosehall> References: <20071107111730.GH13544@atlantic.linksys.moosehall> <871wb2p2f9.fsf@bzg.ath.cx> <20071107135235.GM13544@atlantic.linksys.moosehall> <878x5am0wl.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 1IpocQ-0000n0-C3 for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:23:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpocN-0000lf-Ml for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:23:09 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpocN-0000lc-JF for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:23:07 -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 1IpocN-0006Vy-FA for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 12:23:07 -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 lA7HN5OQ021253 for ; Wed, 7 Nov 2007 11:23:05 -0600 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id lA7HN5MO021247 for emacs-orgmode@gnu.org; Wed, 7 Nov 2007 17:23:05 GMT Content-Disposition: inline In-Reply-To: <878x5am0wl.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 05:16:26PM +0000, Bastien wrote: > 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. I wouldn't quite say it like that. #+CATEGORY is still about task/appointment grouping - but categorising all entries in one file in a convenient, single pass. However if you only had two files, and one file had one #+CATEGORY line and the other had a different one, you wouldn't say you were grouping files together, would you? > 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. Yes - or you could describe it the other way around - enabling you to combine multiple categories in the same file. > Your request was to be able to perform a search using #+CATEGORY as a > way to search through multiple files. Again, at risk of being pedantic I would describe my requirement slightly differently. (N.B. I can already search through multiple files.) Let's first bear in mind the relational data model behind this: - There is a many:one relationship between items (TODOs, appointments etc.) and categories, regardless of whether the category comes from #+CATEGORY or a :CATEGORY: property. - There is a many:one relationship between items and files. - Consequently, there is a many:many relationship between files and categories. In other words, categories are a means of grouping items, not files. (Ditto for tags and any other properties, in fact.) So, there are two orthogonal aspects to my requirement: - I want to be able to perform a search for a particular category across all *items* in all of my agenda files. N.B. this search is essentially item-oriented (think "SELECT * FROM item WHERE category=..."), *not* file-oriented (in an SQL world, the many:many relationship between files and categories would make for a more complex query). - I want to be able to conveniently place whole files in a single category (this is already satisfied by #+CATEGORY), and also maybe be able to add further files at a later date which have multiple categories per file (this is already satisfied by :CATEGORY: properties). > I can see to ways of doing this: > > 1. implicitely add the #+CATEGORY value of a file to each entry in this > file, That's what already happens, no? Each entry in my *Org Agenda* buffer is clearly labelled with the category which came from a #+CATEGORY line or :CATEGORY: property. > 2. clearly separate the group of files from the group of tasks, and > perform a group-restricted search. No, as I said above, this isn't about grouping files. > I think (1) is problematic: what if a file has a top #+CATEGORY and > several :CATEGORY: properties? Then the :CATEGORY: value takes precedence - this is already handled correctly in the existing code which builds the *Org Agenda* buffer. > What about precedence and inheritance? This is too - the most deeply-nested :CATEGORY: value takes precedence. In fact, the only thing missing is that the code for doing a property-based tag search doesn't honour #+CATEGORY, only CATEGORY properties. > How to build the search string if we want to search through several > :CATEGORY: properties in a single #+CATEGORY ? I don't think I understand the question. > > 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... What do you mean by a divorce, and why do you think this? #+CATEGORY and :CATEGORY: happily coexist at the moment. > >> 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. I disagree on two fronts :-) (Although this is not hugely important.) Firstly categories present the user with another interface to learn about. I am certainly not complaining, but you cannot discount the extra complexity they introduce, and therefore we should be careful about introducing yet more complexity. Secondly, categories are more than just properties due to #+CATEGORY - and in fact it is precisely this oddity, or exception to the Principle of Least Surprise, which I am trying to address in this thread. > And besides these search considerations, I really believe that > having several groups of agenda-files would help. Quite possibly, though probably not for me :-) Can you suggest a use case or two? > > I already have too many problems keeping a good work/life balance! ;-) > > Com'on, our daily brain-sport is to feed this list! :) Argh, way too much time spent on this list today ;-)