property searches for #+CATEGORY

property searches for #+CATEGORY

[Adam Spiers]

I have several personal .org files, and several work-related ones too.
In each personal file, I have a line:

  #+CATEGORY: personal
  
and in each work-related file, I have a line:

  #+CATEGORY: work

I would like to be able to bind agenda custom commands to do tag
searches which are narrowed to one of these categories, e.g. "show me
all personal priority #A tasks".  Such a search needs to span *all*
agenda files, therefore the standard per-buffer narrowing provided by
the '<' binding in the *Agenda Commands* buffer is insufficient.

Would it make sense to include CATEGORY as a special property?  After
all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
etc.) are already available via the property interface, and this way,
I could easily achieve what I need with tag searches such as

  CATEGORY="personal"+PRIORITY="A"

Thanks!

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 12:49:44PM +0000, Bastien wrote:
> Adam Spiers <orgmode@adamspiers.org> writes:
> 
> > Would it make sense to include CATEGORY as a special property?  
> 
> Certainly.  And it is already there:
> 
> ,----[ (info "(org)Categories") ]
> | If you would like to have a special CATEGORY for a single entry or a
> | (sub)tree, give the entry a `:CATEGORY:' property with the location as
> | the value (*note Properties and columns::).
> `----

I was aware of this, but I don't want to have to set this property in
every entry or even at the top of every subtree.  I want to be able to
use #+CATEGORY, and have it achieve the same effect w.r.t. properties.

Re: property searches for #+CATEGORY

[Bastien]

Adam Spiers <orgmode@adamspiers.org> writes:

> Would it make sense to include CATEGORY as a special property?  

Certainly.  And it is already there:

,----[ (info "(org)Categories") ]
| If you would like to have a special CATEGORY for a single entry or a
| (sub)tree, give the entry a `:CATEGORY:' property with the location as
| the value (*note Properties and columns::).
`----

:)

-- 
Bastien

Re: property searches for #+CATEGORY

[Tim O'Callaghan]

On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> I have several personal .org files, and several work-related ones too.
> In each personal file, I have a line:
>
>   #+CATEGORY: personal
>
> and in each work-related file, I have a line:
>
>   #+CATEGORY: work
>
> I would like to be able to bind agenda custom commands to do tag
> searches which are narrowed to one of these categories, e.g. "show me
> all personal priority #A tasks".  Such a search needs to span *all*
> agenda files, therefore the standard per-buffer narrowing provided by
> the '<' binding in the *Agenda Commands* buffer is insufficient.
>
> Would it make sense to include CATEGORY as a special property?  After
> all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
> etc.) are already available via the property interface, and this way,
> I could easily achieve what I need with tag searches such as
>
>   CATEGORY="personal"+PRIORITY="A"
>
> Thanks!
>

It would seem to me that this is exactly what tags does.
You could move everything down a level and use tag inheritance:
* personal stuff :personal:
* work stuff :work:

Tim.

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote:
> On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> > I have several personal .org files, and several work-related ones too.
> > In each personal file, I have a line:
> >
> >   #+CATEGORY: personal
> >
> > and in each work-related file, I have a line:
> >
> >   #+CATEGORY: work
> >
> > I would like to be able to bind agenda custom commands to do tag
> > searches which are narrowed to one of these categories, e.g. "show me
> > all personal priority #A tasks".  Such a search needs to span *all*
> > agenda files, therefore the standard per-buffer narrowing provided by
> > the '<' binding in the *Agenda Commands* buffer is insufficient.
> >
> > Would it make sense to include CATEGORY as a special property?  After
> > all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
> > etc.) are already available via the property interface, and this way,
> > I could easily achieve what I need with tag searches such as
> >
> >   CATEGORY="personal"+PRIORITY="A"
> >
> > Thanks!
> 
> It would seem to me that this is exactly what tags does.
> You could move everything down a level and use tag inheritance:
> * personal stuff :personal:
> * work stuff :work:

I could, but this would mean that each file would have a single
top-level entry, and the entire contents would be indented an extra
level, which I fear is a rather unattractive solution!

Re: property searches for #+CATEGORY

[Adam Spiers]

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.

Re: property searches for #+CATEGORY

[Tim O'Callaghan]

On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote:
> > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> > > I have several personal .org files, and several work-related ones too.
> > > In each personal file, I have a line:
> > >
> > >   #+CATEGORY: personal
> > >
> > > and in each work-related file, I have a line:
> > >
> > >   #+CATEGORY: work
> > >
> > > I would like to be able to bind agenda custom commands to do tag
> > > searches which are narrowed to one of these categories, e.g. "show me
> > > all personal priority #A tasks".  Such a search needs to span *all*
> > > agenda files, therefore the standard per-buffer narrowing provided by
> > > the '<' binding in the *Agenda Commands* buffer is insufficient.
> > >
> > > Would it make sense to include CATEGORY as a special property?  After
> > > all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
> > > etc.) are already available via the property interface, and this way,
> > > I could easily achieve what I need with tag searches such as
> > >
> > >   CATEGORY="personal"+PRIORITY="A"
> > >
> > > Thanks!
> >
> > It would seem to me that this is exactly what tags does.
> > You could move everything down a level and use tag inheritance:
> > * personal stuff :personal:
> > * work stuff :work:
>
> I could, but this would mean that each file would have a single
> top-level entry, and the entire contents would be indented an extra
> level, which I fear is a rather unattractive solution!
>

It's the technique i've been using, and yes, it is unattractive.

When i thought of tags, it was not explicitly for GTD context
specifier, it was also for adding searchable metadata to a todo node.
I'm finding out that it gets diluted somewhat.

It guess its a matter of taxonomy. Roughly i would see this as:

1. State - TODO - DO/CANCEL/DONE
2. Context - tags - :@home:@phone:
3. Date/Time - <2007-10-10>
4. Meta Context - Category - personal, work etc,
5. Meta State - Properties drawer - :EMAIL:emacs-orgmode@gnu.org
6. Meta DateTime - state/time logging -

How about adding the context to the tag table with a prefix character, say #?

Tim.

Re: property searches for #+CATEGORY

[Bastien]

Adam Spiers <orgmode@adamspiers.org> writes:

> I have several personal .org files, and several work-related ones too.
> In each personal file, I have a line:
>
>   #+CATEGORY: personal
>   
> and in each work-related file, I have a line:
>
>   #+CATEGORY: work
>
> I would like to be able to bind agenda custom commands to do tag
> searches which are narrowed to one of these categories, e.g. "show me
> all personal priority #A tasks".  Such a search needs to span *all*
> agenda files, therefore the standard per-buffer narrowing provided by
> the '<' binding in the *Agenda Commands* buffer is insufficient.
>
> Would it make sense to include CATEGORY as a special property?  After
> all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
> etc.) are already available via the property interface, and this way,
> I could easily achieve what I need with tag searches such as
>
>   CATEGORY="personal"+PRIORITY="A"

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.

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...)

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.  
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.

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!

-- 
Bastien

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 02:59:35PM +0100, Tim O'Callaghan wrote:
> On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> > On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote:
> > > It would seem to me that this is exactly what tags does.
> > > You could move everything down a level and use tag inheritance:
> > > * personal stuff :personal:
> > > * work stuff :work:
> >
> > I could, but this would mean that each file would have a single
> > top-level entry, and the entire contents would be indented an extra
> > level, which I fear is a rather unattractive solution!
> 
> It's the technique i've been using, and yes, it is unattractive.
> 
> When i thought of tags, it was not explicitly for GTD context
> specifier, it was also for adding searchable metadata to a todo node.

Same here.  I used tags for a lot more than GTD contexts, e.g. also
for a rough ETC and to group them by areas of responsibility.
(N.B. Sometimes a task can be motivated by multiple areas of
responsibility, so subheadings aren't good enough.)

> How about adding the context to the tag table with a prefix character, say #?

I don't follow you, sorry.  Perhaps I should state explicitly that my
need to distinguish between 'work' and 'personal' categories has
nothing to do with my use of GTD contexts.  I can (and do very often)
work from home, and I also occasionally(!) do personal tasks from the
office.

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 02:49:28PM +0000, Bastien wrote:
> Adam Spiers <orgmode@adamspiers.org> writes:
> 
> >> It would seem to me that this is exactly what tags does.
> >> You could move everything down a level and use tag inheritance:
> >> * personal stuff :personal:
> >> * work stuff :work:
> >
> > I could, but this would mean that each file would have a single
> > top-level entry, and the entire contents would be indented an extra
> > level, which I fear is a rather unattractive solution!
> 
> ..which is exactly why your request about using a per-file #+CATEGORY
> when searching across files is more about *grouping files* than about
> grouping tasks.  Am I wrong?

You're right.  It's a 2-tier grouping mechanism really, e.g.

   (1) group work-related tasks into ~/work/TODO.org and appointments
       into ~/work/diary.org, then 

   (2) group all work-related files together so that tag/keyword
       searches etc. can be performed on them all in one go.

Re: property searches for #+CATEGORY

[Bastien]

Adam Spiers <orgmode@adamspiers.org> writes:

>> It would seem to me that this is exactly what tags does.
>> You could move everything down a level and use tag inheritance:
>> * personal stuff :personal:
>> * work stuff :work:
>
> I could, but this would mean that each file would have a single
> top-level entry, and the entire contents would be indented an extra
> level, which I fear is a rather unattractive solution!

..which is exactly why your request about using a per-file #+CATEGORY
when searching across files is more about *grouping files* than about
grouping tasks.  Am I wrong?

-- 
Bastien

Re: property searches for #+CATEGORY

[Tim O'Callaghan]

On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> On Wed, Nov 07, 2007 at 02:59:35PM +0100, Tim O'Callaghan wrote:
> > On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
> > > On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote:
> > > > It would seem to me that this is exactly what tags does.
> > > > You could move everything down a level and use tag inheritance:
> > > > * personal stuff :personal:
> > > > * work stuff :work:
> > >
> > > I could, but this would mean that each file would have a single
> > > top-level entry, and the entire contents would be indented an extra
> > > level, which I fear is a rather unattractive solution!
> >
> > It's the technique i've been using, and yes, it is unattractive.
> >
> > When i thought of tags, it was not explicitly for GTD context
> > specifier, it was also for adding searchable metadata to a todo node.
>
> Same here.  I used tags for a lot more than GTD contexts, e.g. also
> for a rough ETC and to group them by areas of responsibility.
> (N.B. Sometimes a task can be motivated by multiple areas of
> responsibility, so subheadings aren't good enough.)
>
> > How about adding the context to the tag table with a prefix character, say #?
>
> I don't follow you, sorry.  Perhaps I should state explicitly that my
> need to distinguish between 'work' and 'personal' categories has
> nothing to do with my use of GTD contexts.  I can (and do very often)
> work from home, and I also occasionally(!) do personal tasks from the
> office.
>

My point with the taxonomy is that Categories especially 'personal'
and 'work' can be thought of as Meta Contexts (i wanted to say
Meta-TAGS, but that might get confusing). So contexts that are
arbitrary but are used to group many actual physical contexts (TAGS)
of todo nodes.

The '#' was the thought that if you treat Categories as a type of tag,
then you could add them to the tag search mechanism. To avoid
collision, such as work - the physical context and work, the category,
prefix them with a meta-character such as # which cannot normally be
in a tag name.

So a categorised tag-todo search might be:
"#work+work+email/TODO"

Tim.

Re: property searches for #+CATEGORY

[Carsten Dominik]

Thanks for an interesting discussion about the merits of properties
versus tags etc.  Very illuminating.

However, I do think that Adam's initial request to make the
category available as a special property for queries in not
unreasonble.  Or does anyone disagree?

I am not sure, though, if the #+CATEGORY category should be
available with `org-entry-get', because it would then be very
hard for the property API to make a difference between a value
that is intimately associated with the current entry, and a
value that might be derived by some other mechanism.  So here I
differ somewhat from Adam's feeling that category is just like
TODO or a tag.  It is different.

But for the search interface, to allow CATEGORY="work", I think
that would be a safe thing to do.  Will be in 5.14, unless I hear
good arguments against this.

- Carsten

On  7Nov2007, at 2:59 PM, Tim O'Callaghan wrote:

> On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
>> On Wed, Nov 07, 2007 at 02:23:12PM +0100, Tim O'Callaghan wrote:
>>> On 07/11/2007, Adam Spiers <orgmode@adamspiers.org> wrote:
>>>> I have several personal .org files, and several work-related  
>>>> ones too.
>>>> In each personal file, I have a line:
>>>>
>>>>   #+CATEGORY: personal
>>>>
>>>> and in each work-related file, I have a line:
>>>>
>>>>   #+CATEGORY: work
>>>>
>>>> I would like to be able to bind agenda custom commands to do tag
>>>> searches which are narrowed to one of these categories, e.g.  
>>>> "show me
>>>> all personal priority #A tasks".  Such a search needs to span *all*
>>>> agenda files, therefore the standard per-buffer narrowing  
>>>> provided by
>>>> the '<' binding in the *Agenda Commands* buffer is insufficient.
>>>>
>>>> Would it make sense to include CATEGORY as a special property?   
>>>> After
>>>> all, pretty much all other per-task meta-data ("TODO", "PRIORITY"
>>>> etc.) are already available via the property interface, and this  
>>>> way,
>>>> I could easily achieve what I need with tag searches such as
>>>>
>>>>   CATEGORY="personal"+PRIORITY="A"
>>>>
>>>> Thanks!
>>>
>>> It would seem to me that this is exactly what tags does.
>>> You could move everything down a level and use tag inheritance:
>>> * personal stuff :personal:
>>> * work stuff :work:
>>
>> I could, but this would mean that each file would have a single
>> top-level entry, and the entire contents would be indented an extra
>> level, which I fear is a rather unattractive solution!
>>
>
> It's the technique i've been using, and yes, it is unattractive.
>
> When i thought of tags, it was not explicitly for GTD context
> specifier, it was also for adding searchable metadata to a todo node.
> I'm finding out that it gets diluted somewhat.
>
> It guess its a matter of taxonomy. Roughly i would see this as:
>
> 1. State - TODO - DO/CANCEL/DONE
> 2. Context - tags - :@home:@phone:
> 3. Date/Time - <2007-10-10>
> 4. Meta Context - Category - personal, work etc,
> 5. Meta State - Properties drawer - :EMAIL:emacs-orgmode@gnu.org
> 6. Meta DateTime - state/time logging -
>
> How about adding the context to the tag table with a prefix  
> character, say #?
>
> Tim.
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: property searches for #+CATEGORY

[Carsten Dominik]

On  7Nov2007, at 3:15 PM, 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.
>
> Then I think the right solution would be to have groups of agenda  
> files.
> Something like:
>
>   #+AGENDA_GROUP: personal

The idea to have groups of agenda files has come up before.
It is hard to implement because agenda creating commands
are *global* commands, so the group should not be a property
of the location from where you call the agenda.

You can, of course, already make custom commands that are
restricted to a specific group of files, by setting
`org-agenda-files' as one of the options for a custom command
in org-agenda-custom-comands....

- Carsten

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 03:52:55PM +0100, Tim O'Callaghan wrote:
> My point with the taxonomy is that Categories especially 'personal'
> and 'work' can be thought of as Meta Contexts (i wanted to say
> Meta-TAGS, but that might get confusing). So contexts that are
> arbitrary but are used to group many actual physical contexts (TAGS)
> of todo nodes.

I see.

> The '#' was the thought that if you treat Categories as a type of tag,
> then you could add them to the tag search mechanism. To avoid
> collision, such as work - the physical context and work, the category,
> prefix them with a meta-character such as # which cannot normally be
> in a tag name.
> 
> So a categorised tag-todo search might be:
> "#work+work+email/TODO"

Sure, that would be good enough for me if it were implemented - I'm
not fussy whether what I need was provided via new syntax such as the
above, or existing syntax such as

  CATEGORY="work"+email/TODO 

Re: property searches for #+CATEGORY

[Bastien]

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.  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.

Your request  was to be able to perform a search using #+CATEGORY as a
way to search through multiple files.  

I can see to ways of doing this:

1. implicitely add the #+CATEGORY value of a file to each entry in this
   file, and search through files having the same #+CATEGORY;

2. clearly separate the group of files from the group of tasks, and
   perform a group-restricted search.

I think (1) is problematic: what if a file has a top #+CATEGORY and
several :CATEGORY: properties?  What about precedence and inheritance?
How to build the search string if we want to search through several
:CATEGORY: properties in a single #+CATEGORY ?

> 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...

>> 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.  And besides these search considerations, I
really believe that having several groups of agenda-files would help.

> I already have too many problems keeping a good work/life balance! ;-)

Com'on, our daily brain-sport is to feed this list! :)

-- 
Bastien

Re: property searches for #+CATEGORY

[Adam Spiers]

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 ;-)

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 05:15:55PM +0100, Carsten Dominik wrote:
> Thanks for an interesting discussion about the merits of properties
> versus tags etc.  Very illuminating.
> 
> However, I do think that Adam's initial request to make the
> category available as a special property for queries in not
> unreasonble.  Or does anyone disagree?
> 
> I am not sure, though, if the #+CATEGORY category should be
> available with `org-entry-get', because it would then be very
> hard for the property API to make a difference between a value
> that is intimately associated with the current entry, and a
> value that might be derived by some other mechanism.

Understood.

> So here I differ somewhat from Adam's feeling that category is just
> like TODO or a tag.  It is different.

Actually I agree with that :-)  I just meant to point out some of the
similarities in what they enable you to do.

> But for the search interface, to allow CATEGORY="work", I think
> that would be a safe thing to do.  Will be in 5.14, unless I hear
> good arguments against this.

Fantastic!  Thanks a lot.

Re: property searches for #+CATEGORY

[Adam Spiers]

On Wed, Nov 07, 2007 at 05:20:32PM +0100, Carsten Dominik wrote:
> The idea to have groups of agenda files has come up before.
> It is hard to implement because agenda creating commands
> are *global* commands, so the group should not be a property
> of the location from where you call the agenda.
> 
> You can, of course, already make custom commands that are
> restricted to a specific group of files, by setting
> `org-agenda-files' as one of the options for a custom command
> in org-agenda-custom-comands....

Ah!  Now that's a nice trick - I hadn't realised you could override
variables like that.  And given that option values are lisp
expressions, one could easily define a group of agenda files via
(defvar my-org-personal-agenda-files) and then use that variable in
one or more custom agenda commands.  Wouldn't that be good enough
for most people who want a file-grouping mechanism?

(I should make it clear that I still believe it's worth making the
tweak we agreed on to support CATEGORY="..." searches which catch
#+CATEGORY values.)

Re: property searches for #+CATEGORY

[Bastien]

Hi Adam,

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

Re: property searches for #+CATEGORY

[Bastien]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> However, I do think that Adam's initial request to make the
> category available as a special property for queries in not
> unreasonble.  Or does anyone disagree?

I'm convinced it's not unreasonable :)

> I am not sure, though, if the #+CATEGORY category should be
> available with `org-entry-get', because it would then be very
> hard for the property API to make a difference between a value
> that is intimately associated with the current entry, and a
> value that might be derived by some other mechanism.  So here I
> differ somewhat from Adam's feeling that category is just like
> TODO or a tag.  It is different.

Then a search like CATEGORY="cat" would also return entries which
CATEGORY property is not "cat"... ok, maybe this doesn't hurt that 
much for search purposes.  But I expect someone will come in three 
month complaining that `org-entry-get' didn't return the category, 
even though he set it up through #+CATEGORY.

Anyway, not *that* important, as Adam said earlier... let's try.

-- 
Bastien

Re: property searches for #+CATEGORY

[Carsten Dominik]

On  8Nov2007, at 5:55 AM, Bastien wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> However, I do think that Adam's initial request to make the
>> category available as a special property for queries in not
>> unreasonble.  Or does anyone disagree?
>
> I'm convinced it's not unreasonable :)
>
>> I am not sure, though, if the #+CATEGORY category should be
>> available with `org-entry-get', because it would then be very
>> hard for the property API to make a difference between a value
>> that is intimately associated with the current entry, and a
>> value that might be derived by some other mechanism.  So here I
>> differ somewhat from Adam's feeling that category is just like
>> TODO or a tag.  It is different.
>
> Then a search like CATEGORY="cat" would also return entries which
> CATEGORY property is not "cat"... ok, maybe this doesn't hurt that
> much for search purposes.  But I expect someone will come in three
> month complaining that `org-entry-get' didn't return the category,
> even though he set it up through #+CATEGORY.

OK, here is what we will do.  We will make `org-entry-get' return
a value from #+CATEGORY if the INHERIT flag is set in the call
to `org-entry-get'.  In this case the value is inherited not from
a higher level entry, but for the "file environment", and even
top-level outline entries can ihnerit it.
We actually already have this mechanism:

    #+PROPERTY: Name Value

So we could then see

    #+CATEGORY: work

as a short-hand for

    #+PROPERTY: CATEGORY work

... which makes all of this suddenly look as if it was designed
like this from the beginning.  I like it.

Thanks again to everyone who contributed to this discussion.

- Carsten

Re: property searches for #+CATEGORY

[Mario E. Munich]

Dear all,

I am sorry to bother you with a silly question, but I have read all the
postings on the orgmode list on how to separate files for work and
personal using the CATEGORY stuff. I have implemented the method, but I
cannot get org-agenda-custom-commands to search properly in each
category. Any pointers/help would be highly appreciated.

Best regards,

-Mario

-- 
Mario E. Munich, PhD
VP of Engineering 
Principal Scientist
Evolution Robotics
Ph: (626) 993-3317
Fax: (626) 993-3301
mario@evolution.com
http://www.evolution.com

Re: property searches for #+CATEGORY

[Mario E. Munich]

Dear all,

I am sorry to bother you with a silly question, but I have read all the
postings on the orgmode list on how to separate files for work and
personal using the CATEGORY stuff. I have implemented the method, but I
cannot get org-agenda-custom-commands to search properly in each
category. Any pointers/help would be highly appreciated (or other method
in case that it would be more appropriated)

Best regards,

-Mario

Re: property searches for #+CATEGORY

[Carsten Dominik]

Hi Mario,

the fact that you "have read all the postings" almost contradicts
your other statement that you "have implemented *the* method".
I guess you need to tell us more about your detailed setup
to get a useful reply.

- Carsten

On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote:

> Dear all,
>
> I am sorry to bother you with a silly question, but I have read all  
> the
> postings on the orgmode list on how to separate files for work and
> personal using the CATEGORY stuff. I have implemented the method,  
> but I
> cannot get org-agenda-custom-commands to search properly in each
> category. Any pointers/help would be highly appreciated.
>
> Best regards,
>
> -Mario
>
> -- 
> Mario E. Munich, PhD
> VP of Engineering
> Principal Scientist
> Evolution Robotics
> Ph: (626) 993-3317
> Fax: (626) 993-3301
> mario@evolution.com
> http://www.evolution.com
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: property searches for #+CATEGORY

[Mario E. Munich]

Dear Carsten,

I am really sorry for not having been clear... let me explain myself a
little bit and hopefully you would be able to point me in the right
direction.

First of all, I would like to mention that I am a planner-el convert
given the flexibility that org-mode provides. I have converted all my
planner files into org-mode files and I am moving forward using org-mode.

My particular use-case scenario (that seemed to be the same scenario
that Adam mentioned in this thread) is that I would like to have two set
of org files stored in separated directories: one set for the office
(work) and another set for home (personal). I am able to run agenda
commands in both sets of files using org-agenda-files and I am able to
see all the TODO items using the basic C-a a commands. However, I would
like to search for TODO items that correspond only to my work or only to
my home (basically, have two emacs buffers, one with work TODO lists and
another with personal TODO lists to avoid cluttering).

From this thread of emails of about a year ago, I thought that the
solution to my use-case was to add a #+CATEGORY indicator on the files.
I have added the following lines:

#+CATEGORY: work my-work-project

or

#+CATEGORY: personal my-personal-project

accordingly in the work and the personal files.
So, I am now at the point in which I would like to customize the
org-agenda-custom-commands to search for CATEGORY work or personal TODO
items. I have looked in the mailing list and in the org-mode
documentation and I have not been able to find a good example on how to
do this (I should add that my lisp skills are not that great and
therefore that might be the root cause of the problem).

I have several questions:

1) Given my use-case, is this the right approach? Should I be using
something else like FILETAGS?

I think that this use-case might be rather common for people working in
industry in which you would like to have a separation between work and
personal files due to IP and ownership issues. Things might be even
worse if you use SVN at work and GIT at home (my case). So, I would
think that it would be useful to have a simple skeleton setup in the
documentation. In planner, I used to have a way of switching between
pointing at work or personal files, but this setup was less than ideal.

2) If using CATEGORY is the right thing to do, how should I write the
search function?

Thanks a lot for your help and support... And not that you need any more
praise for org-mode, but, man, it is really, really good!!!!

Thanks again,

-Mario

Carsten Dominik wrote:
> Hi Mario,
>
> the fact that you "have read all the postings" almost contradicts
> your other statement that you "have implemented *the* method".
> I guess you need to tell us more about your detailed setup
> to get a useful reply.
>
> - Carsten
>
> On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote:
>
>> Dear all,
>>
>> I am sorry to bother you with a silly question, but I have read all the
>> postings on the orgmode list on how to separate files for work and
>> personal using the CATEGORY stuff. I have implemented the method, but I
>> cannot get org-agenda-custom-commands to search properly in each
>> category. Any pointers/help would be highly appreciated.
>>
>> Best regards,
>>
>> -Mario
>>
>> -- 
>> Mario E. Munich, PhD
>> VP of Engineering
>> Principal Scientist
>> Evolution Robotics
>> Ph: (626) 993-3317
>> Fax: (626) 993-3301
>> mario@evolution.com
>> http://www.evolution.com
>>
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

Re: property searches for #+CATEGORY

[Matthew Lundin]

Hi Mario,

I find the easiest way to filter for personal and professional tasks
is to use a filetag at the top of each file, e.g.,

#+FILETAGS: prof

I use filetags because the agenda has a wonderful shortcut for
filtering by tags. When I call the agenda, I simply hit "/" and then
the shortcut for either my "prof" or "per" tag to filter the items.
It's lightning quick and does the job painlessly (i.e., without any
custom agenda searches). I have org-use-tag-inheritance set to t, but
if you want fine-grained control of what tags are inherited, Org 6.14
has some nice new options.

Of course, if you'd prefer to use categories instead of filetags, they
also work just fine for custom agenda searches. For example,

(setq org-agenda-custom-commands
      '(("w" tags-todo "CATEGORY=\"work\"")
        ("h" tags-todo "CATEGORY=\"home\"")))
        
Finally, you can always search by category using C-c a m or C-c a M
and then typing the following:

CATEGORY="work"

In short, there are lot of nice ways to achieve the functionality
you're looking for. 

I hope this helps.

Best,

Matt
       
"Mario E. Munich" <mariomu@ieee.org> writes:

> Dear Carsten,
>
> I am really sorry for not having been clear... let me explain myself a
> little bit and hopefully you would be able to point me in the right
> direction.
>
> First of all, I would like to mention that I am a planner-el convert
> given the flexibility that org-mode provides. I have converted all my
> planner files into org-mode files and I am moving forward using org-mode.
>
> My particular use-case scenario (that seemed to be the same scenario
> that Adam mentioned in this thread) is that I would like to have two set
> of org files stored in separated directories: one set for the office
> (work) and another set for home (personal). I am able to run agenda
> commands in both sets of files using org-agenda-files and I am able to
> see all the TODO items using the basic C-a a commands. However, I would
> like to search for TODO items that correspond only to my work or only to
> my home (basically, have two emacs buffers, one with work TODO lists and
> another with personal TODO lists to avoid cluttering).
>
> From this thread of emails of about a year ago, I thought that the
> solution to my use-case was to add a #+CATEGORY indicator on the files.
> I have added the following lines:
>
> #+CATEGORY: work my-work-project
>
> or
>
> #+CATEGORY: personal my-personal-project
>
> accordingly in the work and the personal files.
> So, I am now at the point in which I would like to customize the
> org-agenda-custom-commands to search for CATEGORY work or personal TODO
> items. I have looked in the mailing list and in the org-mode
> documentation and I have not been able to find a good example on how to
> do this (I should add that my lisp skills are not that great and
> therefore that might be the root cause of the problem).
>
> I have several questions:
>
> 1) Given my use-case, is this the right approach? Should I be using
> something else like FILETAGS?
>
> I think that this use-case might be rather common for people working in
> industry in which you would like to have a separation between work and
> personal files due to IP and ownership issues. Things might be even
> worse if you use SVN at work and GIT at home (my case). So, I would
> think that it would be useful to have a simple skeleton setup in the
> documentation. In planner, I used to have a way of switching between
> pointing at work or personal files, but this setup was less than ideal.
>
> 2) If using CATEGORY is the right thing to do, how should I write the
> search function?
>
> Thanks a lot for your help and support... And not that you need any more
> praise for org-mode, but, man, it is really, really good!!!!
>
> Thanks again,
>
> -Mario
>
> Carsten Dominik wrote:
>> Hi Mario,
>>
>> the fact that you "have read all the postings" almost contradicts
>> your other statement that you "have implemented *the* method".
>> I guess you need to tell us more about your detailed setup
>> to get a useful reply.
>>
>> - Carsten
>>
>> On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote:
>>
>>> Dear all,
>>>
>>> I am sorry to bother you with a silly question, but I have read all the
>>> postings on the orgmode list on how to separate files for work and
>>> personal using the CATEGORY stuff. I have implemented the method, but I
>>> cannot get org-agenda-custom-commands to search properly in each
>>> category. Any pointers/help would be highly appreciated.
>>>
>>> Best regards,
>>>
>>> -Mario
>>>
>>> -- 
>>> Mario E. Munich, PhD
>>> VP of Engineering
>>> Principal Scientist
>>> Evolution Robotics
>>> Ph: (626) 993-3317
>>> Fax: (626) 993-3301
>>> mario@evolution.com
>>> http://www.evolution.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Emacs-orgmode mailing list
>>> Remember: use `Reply All' to send replies to the list.
>>> Emacs-orgmode@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: property searches for #+CATEGORY

[Mario E. Munich]

Dear Matt,

thanks a lot for the tips... I have settled down on using FILETAGS and
then using C-c a M to get the TODO lists for either personal or work.

Thanks a lot for all the help!

Best regards,

-Mario

Matthew Lundin wrote:
> Hi Mario,
>
> I find the easiest way to filter for personal and professional tasks
> is to use a filetag at the top of each file, e.g.,
>
> #+FILETAGS: prof
>
> I use filetags because the agenda has a wonderful shortcut for
> filtering by tags. When I call the agenda, I simply hit "/" and then
> the shortcut for either my "prof" or "per" tag to filter the items.
> It's lightning quick and does the job painlessly (i.e., without any
> custom agenda searches). I have org-use-tag-inheritance set to t, but
> if you want fine-grained control of what tags are inherited, Org 6.14
> has some nice new options.
>
> Of course, if you'd prefer to use categories instead of filetags, they
> also work just fine for custom agenda searches. For example,
>
> (setq org-agenda-custom-commands
>       '(("w" tags-todo "CATEGORY=\"work\"")
>         ("h" tags-todo "CATEGORY=\"home\"")))
>         
> Finally, you can always search by category using C-c a m or C-c a M
> and then typing the following:
>
> CATEGORY="work"
>
> In short, there are lot of nice ways to achieve the functionality
> you're looking for. 
>
> I hope this helps.
>
> Best,
>
> Matt
>        
> "Mario E. Munich" <mariomu@ieee.org> writes:
>
>   
>> Dear Carsten,
>>
>> I am really sorry for not having been clear... let me explain myself a
>> little bit and hopefully you would be able to point me in the right
>> direction.
>>
>> First of all, I would like to mention that I am a planner-el convert
>> given the flexibility that org-mode provides. I have converted all my
>> planner files into org-mode files and I am moving forward using org-mode.
>>
>> My particular use-case scenario (that seemed to be the same scenario
>> that Adam mentioned in this thread) is that I would like to have two set
>> of org files stored in separated directories: one set for the office
>> (work) and another set for home (personal). I am able to run agenda
>> commands in both sets of files using org-agenda-files and I am able to
>> see all the TODO items using the basic C-a a commands. However, I would
>> like to search for TODO items that correspond only to my work or only to
>> my home (basically, have two emacs buffers, one with work TODO lists and
>> another with personal TODO lists to avoid cluttering).
>>
>> From this thread of emails of about a year ago, I thought that the
>> solution to my use-case was to add a #+CATEGORY indicator on the files.
>> I have added the following lines:
>>
>> #+CATEGORY: work my-work-project
>>
>> or
>>
>> #+CATEGORY: personal my-personal-project
>>
>> accordingly in the work and the personal files.
>> So, I am now at the point in which I would like to customize the
>> org-agenda-custom-commands to search for CATEGORY work or personal TODO
>> items. I have looked in the mailing list and in the org-mode
>> documentation and I have not been able to find a good example on how to
>> do this (I should add that my lisp skills are not that great and
>> therefore that might be the root cause of the problem).
>>
>> I have several questions:
>>
>> 1) Given my use-case, is this the right approach? Should I be using
>> something else like FILETAGS?
>>
>> I think that this use-case might be rather common for people working in
>> industry in which you would like to have a separation between work and
>> personal files due to IP and ownership issues. Things might be even
>> worse if you use SVN at work and GIT at home (my case). So, I would
>> think that it would be useful to have a simple skeleton setup in the
>> documentation. In planner, I used to have a way of switching between
>> pointing at work or personal files, but this setup was less than ideal.
>>
>> 2) If using CATEGORY is the right thing to do, how should I write the
>> search function?
>>
>> Thanks a lot for your help and support... And not that you need any more
>> praise for org-mode, but, man, it is really, really good!!!!
>>
>> Thanks again,
>>
>> -Mario
>>
>> Carsten Dominik wrote:
>>     
>>> Hi Mario,
>>>
>>> the fact that you "have read all the postings" almost contradicts
>>> your other statement that you "have implemented *the* method".
>>> I guess you need to tell us more about your detailed setup
>>> to get a useful reply.
>>>
>>> - Carsten
>>>
>>> On Dec 8, 2008, at 12:35 AM, Mario E. Munich wrote:
>>>
>>>       
>>>> Dear all,
>>>>
>>>> I am sorry to bother you with a silly question, but I have read all the
>>>> postings on the orgmode list on how to separate files for work and
>>>> personal using the CATEGORY stuff. I have implemented the method, but I
>>>> cannot get org-agenda-custom-commands to search properly in each
>>>> category. Any pointers/help would be highly appreciated.
>>>>
>>>> Best regards,
>>>>
>>>> -Mario
>>>>
>>>> -- 
>>>> Mario E. Munich, PhD
>>>> VP of Engineering
>>>> Principal Scientist
>>>> Evolution Robotics
>>>> Ph: (626) 993-3317
>>>> Fax: (626) 993-3301
>>>> mario@evolution.com
>>>> http://www.evolution.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Emacs-orgmode mailing list
>>>> Remember: use `Reply All' to send replies to the list.
>>>> Emacs-orgmode@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>>>         
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>>