From: Adam Spiers <orgmode@adamspiers.org>
To: emacs-orgmode@gnu.org
Subject: Re: property searches for #+CATEGORY
Date: Wed, 7 Nov 2007 13:52:35 +0000 [thread overview]
Message-ID: <20071107135235.GM13544@atlantic.linksys.moosehall> (raw)
In-Reply-To: <871wb2p2f9.fsf@bzg.ath.cx>
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.
next prev parent reply other threads:[~2007-11-07 13:52 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 [this message]
2007-11-07 17:16 ` Bastien
2007-11-07 17:23 ` Adam Spiers
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=20071107135235.GM13544@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).