From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: property searches for #+CATEGORY Date: Thu, 08 Nov 2007 04:42:25 +0000 Message-ID: <87ode5l55a.fsf@bzg.ath.cx> References: <20071107111730.GH13544@atlantic.linksys.moosehall> <871wb2p2f9.fsf@bzg.ath.cx> <20071107135235.GM13544@atlantic.linksys.moosehall> <878x5am0wl.fsf@bzg.ath.cx> <20071107172302.GR13544@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 1IpyHp-0007i4-JR for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 22:42:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpyHo-0007gI-Q6 for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 22:42:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpyHo-0007gC-3p for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 22:42:32 -0500 Received: from rn-out-0910.google.com ([64.233.170.187] helo=rn-out-0102.google.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IpyHn-0008AR-V9 for emacs-orgmode@gnu.org; Wed, 07 Nov 2007 22:42:32 -0500 Received: by rn-out-0102.google.com with SMTP id e27so29805rng for ; Wed, 07 Nov 2007 19:42:31 -0800 (PST) In-Reply-To: <20071107172302.GR13544@atlantic.linksys.moosehall> (Adam Spiers's message of "Wed, 7 Nov 2007 17:23:02 +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 Hi Adam, Adam Spiers writes: > Again, at risk of being pedantic I would describe my requirement > slightly differently. (N.B. I can already search through multiple > files.) Thanks for the very clear & interesting explanations. > In fact, the only thing missing is that the code for doing a > property-based tag search doesn't honour #+CATEGORY, only CATEGORY > properties. Right. Now I understand it would be consistent to include #+CATEGORY in the category *search*. I was mainly choking on what Carsten mentionned in his reply about whether org-entry-get should return the category as defined by #+CATEGORY -- I guess this is the only consistency-hole. But since where are speaking about search interface, this is not a problem, that's right. > 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. I didn't want to add complexity, but rather expressivity. My line of reasoning was this one: 1. it is not recommended to use #+CATEGORY twice in a file 2. then the main use of #+CATEGORY will be for grouping *files* 3. if we use #+CATEGORY for grouping files (or tasks across files) and :CATEGORY: for grouping tasks, let's separate these two mechanismes more clearly 4. this would spare us the cost of deciding what value `org-entry-get' should return when asked for the category, in case a file uses both #+CATEGORY and :CATEGORY:... But again, this line depends on how fussy we are about (4) and search considerations ask for flexibility -- not fussiness :) >> 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? It's mainly for publishing: for now I have to put each project in each directory so that `org-publish-project-alist' DTRT. I'd rather publish groups of files, thus being able to quickly decide what file is in what group. > Argh, way too much time spent on this list today ;-) :) -- Bastien