From: Adam Spiers <orgmode@adamspiers.org>
To: emacs-orgmode@gnu.org
Subject: Re: property searches for #+CATEGORY
Date: Wed, 7 Nov 2007 17:23:02 +0000 [thread overview]
Message-ID: <20071107172302.GR13544@atlantic.linksys.moosehall> (raw)
In-Reply-To: <878x5am0wl.fsf@bzg.ath.cx>
On Wed, Nov 07, 2007 at 05:16:26PM +0000, Bastien wrote:
> Adam Spiers <orgmode@adamspiers.org> 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 ;-)
next prev parent reply other threads:[~2007-11-07 17:23 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-07 11:17 property searches for #+CATEGORY Adam Spiers
2007-11-07 12:49 ` Bastien
2007-11-07 12:15 ` Adam Spiers
2007-11-07 13:23 ` Tim O'Callaghan
2007-11-07 13:34 ` Adam Spiers
2007-11-07 13:59 ` Tim O'Callaghan
2007-11-07 14:28 ` Adam Spiers
2007-11-07 14:52 ` Tim O'Callaghan
2007-11-07 16:35 ` Adam Spiers
2007-11-07 16:15 ` Carsten Dominik
2007-11-07 18:07 ` Adam Spiers
2007-11-08 4:55 ` Bastien
2007-11-08 8:54 ` Carsten Dominik
2007-11-07 14:49 ` Bastien
2007-11-07 14:32 ` Adam Spiers
2007-11-07 14:15 ` Bastien
2007-11-07 13:52 ` Adam Spiers
2007-11-07 17:16 ` Bastien
2007-11-07 17:23 ` Adam Spiers [this message]
2007-11-08 4:42 ` Bastien
2007-11-07 16:20 ` Carsten Dominik
2007-11-08 0:04 ` Adam Spiers
-- strict thread matches above, loose matches on Subject: below --
2008-12-07 23:35 Mario E. Munich
2008-12-08 16:40 ` Carsten Dominik
2008-12-09 0:33 ` Mario E. Munich
2008-12-09 1:41 ` Matthew Lundin
2008-12-09 6:51 ` Mario E. Munich
2008-12-07 23:39 Mario E. Munich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071107172302.GR13544@atlantic.linksys.moosehall \
--to=orgmode@adamspiers.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).