Categories

Categories

[Richard G Riley]

Categories are fairly handy for keeping the agenda well organised, but
what are the functionalities for moving tasks between different
categories e.g a task might move from "PROJ1" to "PROJ2" or some
such? Must it be done manually using cut and paste in the org file?

Re: Categories

[Eddward DeVilla]

You could set a :CATEGORY: property for entry.

Edd

On 10/11/07, Richard G Riley <rileyrgdev@googlemail.com> wrote:
>
> Categories are fairly handy for keeping the agenda well organised, but
> what are the functionalities for moving tasks between different
> categories e.g a task might move from "PROJ1" to "PROJ2" or some
> such? Must it be done manually using cut and paste in the org file?
>
>
> _______________________________________________
> 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: Categories

[Richard G Riley]

Hi,


"Eddward DeVilla" <eddward@gmail.com> writes:

> You could set a :CATEGORY: property for entry.
>
> Edd
>

This is different from a tag how?

How do you do that?

At the moment my org file has sections like this:

,----
| * Emacs
| 
| #+CATEGORY: Emacs
| 
| 
| * Register
| 
| #+CATEGORY: Register
`----

And I then have a host of "insert task" options thus:

,----
|  '(org-remember-templates
|    (quote (
| 	   (?t "* TODO %?\n  %u\n %i\n %a\n" "~/org/todo.org" "Tasks")
|            (?n "* %U %?" "~/org/notes.org" "Notes")
|            (?f "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "FaceBook")
|            (?l "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Linux")
|            (?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs")
|            (?R "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Register")
|            (?r "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Remember")
| 	   (?j "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Journal")
| 	   (?L "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Links")
| 	   )
| 	  )
`----

My question is how to assign a task to a category, preferably through a
pick/select from a list of predefined category names.

Category functionality appears to be limited to place holders in the org
file which then anchor sections in the agenda but I'm not 100% sure.

ps Is there an IRC channel for org? The mailing list is busy enough I
wonder if an IRC channel wouldnt be a good idea to help people through
teething pains.

regards

r.



> On 10/11/07, Richard G Riley <rileyrgdev@googlemail.com> wrote:
>>
>> Categories are fairly handy for keeping the agenda well organised, but
>> what are the functionalities for moving tasks between different
>> categories e.g a task might move from "PROJ1" to "PROJ2" or some
>> such? Must it be done manually using cut and paste in the org file?
>>
>>
>> _______________________________________________
>> 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: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>> You could set a :CATEGORY: property for entry.
>>
> How do you do that?

Please check (info "(Org)Property syntax") to know more about
properties. 

> | #+CATEGORY: Emacs

Although this is still supported, you can now use this:

,----
| * A headline here
|   :PROPERTIES:
|   :CATEGORY: Emacs
|   :END:
`----

The CATEGORY property does the same job than the old #+CATEGORY, except
that its scope is well defined, i.e. we don't need to bother anymore on
where #+CATEGORY has to be.

> My question is how to assign a task to a category, preferably through
> a pick/select from a list of predefined category names.

Maybe something like this:

,----
| (setq org-remember-templates
|       '((?c "* %?\n   :PROPERTIES:\n   :CATEGORY: %^{Category}\n   :END:\n\n  %i\n" "~/org/todo.org" "Tasks")))
`----

(Note that white spaces are important.)

Inserting properties (including the CATEGORY property) interactively
from a template looks a bit too much for me.  But not using remember
very often, and only for taking quick notes -- not editing my main 
Org file.

> ps Is there an IRC channel for org? The mailing list is busy enough I
> wonder if an IRC channel wouldnt be a good idea to help people through
> teething pains.

Do you think "being-productive-with-Org" and "lurking-on-Org-channel"
can get along nicely? Ahem.

The good thing with the mailing is that it helps to provide a huge
"dynamic FAQ" to googlers.  IRC logs too often die in the darkness.

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>> The CATEGORY property does the same job than the old #+CATEGORY, except
>> that its scope is well defined, i.e. we don't need to bother anymore on
>> where #+CATEGORY has to be.
>
> Did you before? 

IIRC this was a recurrent issue on this list.

>> ,----
>> | (setq org-remember-templates
>> |       '((?c "* %?\n   :PROPERTIES:\n   :CATEGORY: %^{Category}\n   :END:\n\n  %i\n" "~/org/todo.org" "Tasks")))
>> `----
>
> Almost. There is no completion or "pick" for the available categories. I
> would expect something like a "tab for completion" field similar to set
> tag for a task.

Yes.  We can imagine something like %^c (prompt for a category with
proper completion).  But then why not %^s for the SUMMARY property?  
And %^d for the DESCRIPTION property?  My answer try to avoid going 
into this, since I (still) think handling properties from within a
remember template is a bit too much.  But I might be wrong.

>> Inserting properties (including the CATEGORY property) interactively
>> from a template looks a bit too much for me.  But not using remember
>> very often, and only for taking quick notes -- not editing my main 
>> Org file.
>
> I'm not sure I understand. One of the most important task properties is
> the category I would have though.

You can use property inheritance.  Ask your remember template to put the
entry in the right subtree, and use a category for that entry only. 

Isn't this more simple?

-- 
Bastien

Re: Categories

[Richard G Riley]

Bastien <bzg@altern.org> writes:

> Richard G Riley <rileyrgdev@googlemail.com> writes:
>
>>> The CATEGORY property does the same job than the old #+CATEGORY, except
>>> that its scope is well defined, i.e. we don't need to bother anymore on
>>> where #+CATEGORY has to be.
>>
>> Did you before? 
>
> IIRC this was a recurrent issue on this list.
>
>>> ,----
>>> | (setq org-remember-templates
>>> |       '((?c "* %?\n   :PROPERTIES:\n   :CATEGORY: %^{Category}\n   :END:\n\n  %i\n" "~/org/todo.org" "Tasks")))
>>> `----
>>
>> Almost. There is no completion or "pick" for the available categories. I
>> would expect something like a "tab for completion" field similar to set
>> tag for a task.
>
> Yes.  We can imagine something like %^c (prompt for a category with
> proper completion).  But then why not %^s for the SUMMARY property?  
> And %^d for the DESCRIPTION property?  My answer try to avoid going 
> into this, since I (still) think handling properties from within a
> remember template is a bit too much.  But I might be wrong.
>
>>> Inserting properties (including the CATEGORY property) interactively
>>> from a template looks a bit too much for me.  But not using remember
>>> very often, and only for taking quick notes -- not editing my main 
>>> Org file.
>>
>> I'm not sure I understand. One of the most important task properties is
>> the category I would have though.
>
> You can use property inheritance.  Ask your remember template to put the
> entry in the right subtree, and use a category for that entry only. 

I do. e.g

,----
|  '(org-remember-templates
| 
|            (?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs")
`----

I think we are talking at cross purposes.

A category is the A number one most important property for task
organization I would have thought.

I can already place them in the right org file section using the
template and others like it above.

But there appears to be no way to manipulate them then e.g move to other
category other can cut and paste.

Possibly my total ignorance of "properties" is the issue here as I can
find no examples of their use or how an end user should utilise them. I
am assuming from your words here that "category" is merely a property.

,----
| > You can use property inheritance.  Ask your remember template to put the
| > entry in the right subtree, and use a category for that entry only. 
`----

What do you mean the right subtree? I already, through the template, put
it into the right sub section delimited by the category property. What
do you mean by "use a category for that entry only"? Do you mean only
the sub tree has a category property? In this case that is what I have -
sections of tasks with a category section separating them. e.g

,----
| * FaceBook
| 
| :PROPERTIES:
| :CATEGORY: FaceBook
| :END:
|   
| 
| * Emacs
| 
| :PROPERTIES:
| :CATEGORY: Emacs
| :END:
| 
| ** [2007-10-12 Fri 15:03] How to use categories in org-mode
|   
|   [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#874][Email from Bastien: Re: Orgmode Categories]]
`----

My original question is how to assign the task above to another category
nice and easily and not using cut and paste? Is it possible? ideally I
would, as with tags, have the ability to choose from all existing
categories in use in the current file.

Re: Categories

[Carsten Dominik]

On Oct 12, 2007, at 16:12, Richard G Riley wrote:

> Bastien <bzg@altern.org> writes:
>
>> Richard G Riley <rileyrgdev@googlemail.com> writes:
>>
>>>> The CATEGORY property does the same job than the old #+CATEGORY, 
>>>> except
>>>> that its scope is well defined, i.e. we don't need to bother 
>>>> anymore on
>>>> where #+CATEGORY has to be.
>>>
>>> Did you before?
>>
>> IIRC this was a recurrent issue on this list.
>>
>>>> ,----
>>>> | (setq org-remember-templates
>>>> |       '((?c "* %?\n   :PROPERTIES:\n   :CATEGORY: %^{Category}\n  
>>>>  :END:\n\n  %i\n" "~/org/todo.org" "Tasks")))
>>>> `----
>>>
>>> Almost. There is no completion or "pick" for the available 
>>> categories. I
>>> would expect something like a "tab for completion" field similar to 
>>> set
>>> tag for a task.
>>
>> Yes.  We can imagine something like %^c (prompt for a category with
>> proper completion).  But then why not %^s for the SUMMARY property?
>> And %^d for the DESCRIPTION property?  My answer try to avoid going
>> into this, since I (still) think handling properties from within a
>> remember template is a bit too much.  But I might be wrong.
>>
>>>> Inserting properties (including the CATEGORY property) interactively
>>>> from a template looks a bit too much for me.  But not using remember
>>>> very often, and only for taking quick notes -- not editing my main
>>>> Org file.
>>>
>>> I'm not sure I understand. One of the most important task properties 
>>> is
>>> the category I would have though.
>>
>> You can use property inheritance.  Ask your remember template to put 
>> the
>> entry in the right subtree, and use a category for that entry only.
>
> I do. e.g
>
> ,----
> |  '(org-remember-templates
> |
> |            (?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs")
> `----
>
> I think we are talking at cross purposes.
>
> A category is the A number one most important property for task
> organization I would have thought.
>
> I can already place them in the right org file section using the
> template and others like it above.
>
> But there appears to be no way to manipulate them then e.g move to 
> other
> category other can cut and paste.
>
> Possibly my total ignorance of "properties" is the issue here as I can
> find no examples of their use or how an end user should utilise them. I
> am assuming from your words here that "category" is merely a property.
>
> ,----
> | > You can use property inheritance.  Ask your remember template to 
> put the
> | > entry in the right subtree, and use a category for that entry only.
> `----
>
> What do you mean the right subtree? I already, through the template, 
> put
> it into the right sub section delimited by the category property. What
> do you mean by "use a category for that entry only"? Do you mean only
> the sub tree has a category property? In this case that is what I have 
> -
> sections of tasks with a category section separating them. e.g
>
> ,----
> | * FaceBook
> |
> | :PROPERTIES:
> | :CATEGORY: FaceBook
> | :END:
> |
> |
> | * Emacs
> |
> | :PROPERTIES:
> | :CATEGORY: Emacs
> | :END:
> |
> | ** [2007-10-12 Fri 15:03] How to use categories in org-mode
> |
> |   [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#874][Email from 
> Bastien: Re: Orgmode Categories]]
> `----
>
> My original question is how to assign the task above to another 
> category
> nice and easily and not using cut and paste? Is it possible? ideally I
> would, as with tags, have the ability to choose from all existing
> categories in use in the current file.

You can add a category property to the entry, and that will overrule the
category that might be inherited from above.  With the latest org-mode 
5.12,
press `C-c C-x p'.  This will prompt you for a property name, enter 
CATEGORY
(using completion).  The it will ask you for the category itself and you
can enter it, again using completion against existing categories (given 
as
properties *anywhere* in the file.  So this will not see the #+CATEGORY 
lines,
only the

   :PROPERTIES:
   :CATEGORY: work
   :END:

definitions.

You can also insert a line

#+PROPERTY: CATEGORY_ALL work home phone whendrunk

to define a complete list of categories.

Note that setting the property wil change the category of the item,
but it will *not* move it to a different place in the file.  If I
understand correctly, this is what you want.

- Carsten

Re: Categories

[Richard G Riley]

Carsten Dominik <dominik@science.uva.nl> writes:

> You can add a category property to the entry, and that will overrule the
> category that might be inherited from above.  With the latest org-mode
> 5.12,
> press `C-c C-x p'.  This will prompt you for a property name, enter
> CATEGORY
> (using completion).  The it will ask you for the category itself and
> you

Completion doesnt work for me. Possibly this is a result of using
icicles? You just TAB to completion?

> can enter it, again using completion against existing categories
> (given as
> properties *anywhere* in the file.  So this will not see the
> #+CATEGORY lines,
> only the
>
>   :PROPERTIES:
>   :CATEGORY: work
>   :END:
>
> definitions.
>
> You can also insert a line
>
> #+PROPERTY: CATEGORY_ALL work home phone whendrunk
>
> to define a complete list of categories.
>
> Note that setting the property wil change the category of the item,
> but it will *not* move it to a different place in the file.  If I
> understand correctly, this is what you want.

Yes. The concept of not having to worry about where things are in the
org file doesn't really work for me. I like things having a certain
category in that category section - otherwise there seems little point
in having lines like

,----
| * Emacs
| 
| :PROPERTIES:
| :CATEGORY: Emacs
| :END:
`----

This might seem like an incredibly naive question, but with the concept
of "general properties", where do TAGs fit in now?  Is a tag a special
kind of property? I am having difficulty seeing the best way to utilise
the tools and would appreciate some wise words of guidance here.


>
> - Carsten

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> Completion doesnt work for me. Possibly this is a result of using
> icicles? You just TAB to completion?

Can you please provide more details:

What version of Org-mode?  
What did you do?  
What did you expect?
What did you get instead?

> This might seem like an incredibly naive question, but with the
> concept of "general properties", where do TAGs fit in now?

TAGs are special properties.  They are special regarding the way you
access them (C-c C-c), the way you display them (flushright) and the 
way Org can process them (with specific search/sort queries.)

But in other respect, they are just "properties" of an entry.

Hope this might help you find the best use for tags.

> I am having difficulty seeing the best way to utilise the tools and
> would appreciate some wise words of guidance here.

For me a todo line gets associated with :

| a project           | CATEGORY     |
| a process state     | TODO keyword |
| an action-type      | tags         |
| a context of action | tags         |

My setting for tags is this:

#+TAGS:      { Read(r) Write(w) Code(c) }
#+TAGS:      Mail(m) Print(p)
#+TAGS:      { @HOME(H) @LAB(L) }
#+TAGS:      { @Online(O) @Offline(F) }

The first two lines are action-types.  

The two last lines are contexts.  The conventions I use are these: 1)
the keys for action-types are lower-case, the keys for contexts are
upper-case. 2) contexts comes with a leading "@" 3) the tags for
*physical* contexts are all capitalized, while those for notional
contexts are just first-letter capitalized.

The tags that I'm more likely to use are Read, Write or Code.  

A subset of my agenda views: 

(setq org-agenda-custom-commands
      '(("r" tags-todo "Read/NEXT" nil)
	("w" tags-todo "Write/NEXT" nil)
	("R" tags-todo "Read/NEXT|TODO" nil)
	("W" tags-todo "Write/NEXT|INPROGRESS" nil)))

Then I regularily check for something to read with "r" (meaning
something to read next) or "R" (including other TODO); or I check for
things that I have to write with "w" (the things I have to write next)
or "W" (including work in progress, which is likely to take more than 
on day.)

For the "Mail" an "Print" tags,  i use the normal C-c a m key, since I
don't use them that often.  

At the beginning I worried too much about having a consistent set of
tags.  For the example above, there is some overlap between Mail Write
and Code.  But you don't need to worry about that.  Just use the tags,
and progressively you will be able to get rid of useless one.

HTH,

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>>> There is no "properties_alL" which determine which properties you can
>>> add.
>>
>> Not relevant here, because there is no reason why the user would like to
>> limit the set of available properties.
>
> Must disagree. Completion doesn't *limit* the choices. It only
> provides existing properties as a choice. You are still free to create
> a new one.

My first point here is that completion over existing properties in the
buffer is enough, no need for a meta-meta-property like PROPERTIES_ALL.

My other point is: when doing `C-c C-x p' to select/edit the value of a
property, it's useful to limit the set of available values -- only when
this set is defined in the corresponding PROPERTY_ALL.

_ALL means "no other value is allowed".  Then if you want the completion
to offer other values when there is such a *_ALL property, you will have
to add this other values to the property first.

(I guess the confusion comes from the fact that we started speaking
about completion for the CATEGORY property.  The CATEGORY property is
historically bound to the entire buffer, so you might expect completion
to be performed on all the values that you have in this buffer.  But if
someone is pervert enough to have a CATEGORY_ALL in a subtree, then the
completion should not offer values that are *not* in this limited set.
CATEGORY is now a property like any other, and it should behave like 
any other... how sad it might be.)

> I understand that. I was referring to the condition where there is no
> "ALL" value. Then it should be (and another email suggests that is how
> Carsten implemented it) a pick from all existing properties 

Agreed.  And this is the current behavior :)

Best,

NB: maybe you'd be interested in the suggestion I make here about having
a "_MULTI" suffix: 

  http://www.cognition.ens.fr/~guerry/org-features-suggestions.html#sec-3

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

>> (setq org-agenda-custom-commands
>>       '(("r" tags-todo "Read/NEXT" nil)
>> 	   ("w" tags-todo "Write/NEXT" nil)
>> 	   ("R" tags-todo "Read/NEXT|TODO" nil)
>> 	   ("W" tags-todo "Write/NEXT|INPROGRESS" nil)))
>
> Where do you press "r" or "R"? I have the code above and nothing happens
> in my agenda. Hopefully I am just being rather dim.

Check that the value of `org-agenda-custom-commands' is actually the one
above.  Then run the command `org-agenda' --- you should see this at the
bottom left of the window:

r   Tags (TODO)  :  Read/NEXT
w   Tags (TODO)  :  Write/NEXT
R   Tags (TODO)  :  Read/NEXT|TODO
W   Tags (TODO)  :  Write/NEXT|INPROGRESS

> "C-c a m" then "Read" shows tasks with a tag of "Read". But pressing
> "r" or "R" does nothing.

If the "r" key (and its associated command) is not listed in the choice
you have when calling org-agenda, then it's normal that it does nothing.

Double-check for the value org `org-agenda-custom-commands' before doing
C-c a

NB: http://orgmode.org/org.html#Agenda-views might also help somehow

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> Yes. I see them. I am confused with this Read/NEXT value. Is this the
> tag or is Read the tag? What should the line look like in my org file
> e.g I have:

Please *read* this:

  http://orgmode.org/org.html#Tag-searches

Read is the tag, NEXT is a todo keyword.

Tags search with "Read/NEXT" search for "Read" tag, restricting results
to items that have a NEXT todo keyword.

> ,----
> | ** TODO master tags/categories					    :Read:VOCAB:
> `----

This one is good.

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> Aha ok. Note that like a lot of things its easy when you know how. 

Well, my post started with this:

,----
| My setting for tags is this:
| 
| #+TAGS:      { Read(r) Write(w) Code(c) }
| #+TAGS:      Mail(m) Print(p)
| #+TAGS:      { @HOME(H) @LAB(L) }
| #+TAGS:      { @Online(O) @Offline(F) }
`----

So you could deduce NEXT wasn't a tag.  But I wrongly assumed you knew
about combined tags/TODO searches.  I agree these are a bit complex, but
they are very well documented in the manual and the "Matching tags and
properties" section explicitely refers to id
 
  (info "(org)Matching tags and properties")

> As I said before one of the problems with flexible programs like org
> is that sometimes preferred usage doesn't immediately become apparent
> to the reader.

I don't know if using combined searches in custom agenda views
"preferred" and I certainly should have gone more into details here.

If you see anything that could clarify the manual for what you were
searching, please suggest.

-- 
Bastien

Re: Categories

[Bastien]

Richard G Riley <rileyrgdev@googlemail.com> writes:

> When I get a work process sorted out then I will try and produce my own
> small "tutorial" while it is fresh in my mind along with links back to
> the relevant online documentation.

That would be great, thanks!

-- 
Bastien

Re: Categories

[Carsten Dominik]

On Oct 12, 2007, at 17:04, Richard G Riley wrote:
>
> Yes. The concept of not having to worry about where things are in the
> org file doesn't really work for me. I like things having a certain
> category in that category section - otherwise there seems little point
> in having lines like
>
> ,----
> | * Emacs
> |
> | :PROPERTIES:
> | :CATEGORY: Emacs
> | :END:
> `----

Check out this message - it might contain what you are looking for.

http://thread.gmane.org/gmane.emacs.orgmode/3179/focus=3586

>
> This might seem like an incredibly naive question, but with the concept
> of "general properties", where do TAGs fit in now?  Is a tag a special
> kind of property? I am having difficulty seeing the best way to utilise
> the tools and would appreciate some wise words of guidance here.

See my other message in a new thread.

- Carsten

Re: Categories

[Richard G Riley]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Oct 12, 2007, at 17:04, Richard G Riley wrote:
>>
>> Yes. The concept of not having to worry about where things are in the
>> org file doesn't really work for me. I like things having a certain
>> category in that category section - otherwise there seems little point
>> in having lines like
>>
>> ,----
>> | * Emacs
>> |
>> | :PROPERTIES:
>> | :CATEGORY: Emacs
>> | :END:
>> `----
>
> Check out this message - it might contain what you are looking for.
>
> http://thread.gmane.org/gmane.emacs.orgmode/3179/focus=3586
>
>>
>> This might seem like an incredibly naive question, but with the concept
>> of "general properties", where do TAGs fit in now?  Is a tag a special
>> kind of property? I am having difficulty seeing the best way to utilise
>> the tools and would appreciate some wise words of guidance here.
>
> See my other message in a new thread.
>
> - Carsten

I have a possible bug here (5.12). When embedding the CATEGORY as a
property e.g in my org file

** TODO master tags/categories						 :VOCAB:
   SCHEDULED: <2007-10-14 Sun> DEADLINE: <2007-10-15 Mon>
   :PROPERTIES:
   :CATEGORY: Emacs
   :MISC:     test
   :END:
   [2007-10-12 Fri]
  
   [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#886][Email from Bastien:
   Re: Orgmode Categories]]

when I change the state e.g with this custom command sample

,----
|  '(org-agenda-custom-commands
|    (quote (
| 	   ("d" org-todo "DELEGATED" nil)
|            ("c" org-todo "DONE|DEFERRED|CANCELLED" nil)
|            ("w" org-todo "WAITING" nil)
| 	   ("W" agenda "" 
`----

I hit "C-c x d" to move to "DELEGATED", I get prompted for a note, but
the note is not stored as a sub item of the parent task anymore. In fact
I don't know where it is stored.

Re: Categories

[Carsten Dominik]

On Oct 12, 2007, at 19:20, Richard G Riley wrote:
> I have a possible bug here (5.12). When embedding the CATEGORY as a
> property e.g in my org file

Yes, logging state changes is broken in 5.12, *#$&*&#&$.

Fixed in 5.12c, thanks.

> ,----
> |  '(org-agenda-custom-commands
> |    (quote (
> | 	   ("d" org-todo "DELEGATED" nil)
> |            ("c" org-todo "DONE|DEFERRED|CANCELLED" nil)
> |            ("w" org-todo "WAITING" nil)
> | 	   ("W" agenda ""
> `----


What an innovative way of totally misusing org-agenda-custom-commands.
`C-c a d' will indeed change a TODO state, something 
org-agenda-custom-commands
was not designed for (and which I do not recommend...)!

But "c" will not work, the symbol for creating a TODO list is
`alltodo', not `org-todo'.

- Carsten

>
> I hit "C-c x d" to move to "DELEGATED", I get prompted for a note, but
> the note is not stored as a sub item of the parent task anymore. In 
> fact
> I don't know where it is stored.

Re: Categories

[Richard G Riley]

Carsten Dominik <dominik@science.uva.nl> writes:

> On Oct 12, 2007, at 19:20, Richard G Riley wrote:
>> I have a possible bug here (5.12). When embedding the CATEGORY as a
>> property e.g in my org file
>
> Yes, logging state changes is broken in 5.12, *#$&*&#&$.
>
> Fixed in 5.12c, thanks.
>
>> ,----
>> |  '(org-agenda-custom-commands
>> |    (quote (
>> | 	   ("d" org-todo "DELEGATED" nil)
>> |            ("c" org-todo "DONE|DEFERRED|CANCELLED" nil)
>> |            ("w" org-todo "WAITING" nil)
>> | 	   ("W" agenda ""
>> `----

I took this from a tutorial out there in google land.

>
>
> What an innovative way of totally misusing org-agenda-custom-commands.
> `C-c a d' will indeed change a TODO state, something
> org-agenda-custom-commands
> was not designed for (and which I do not recommend...)!
>
> But "c" will not work, the symbol for creating a TODO list is
> `alltodo', not `org-todo'.

I'm not sure I understand, but I will remove this regardless. Why are
you mentioning creating a TODO list? The commands above are "jumpt to
state commands - not create commands. So, if the code I cribbed above is
not correct, how is the best way to add commands to agenda mode - its
not obvious how to jump straight to a state as opposed to cycling to it
manually with all the note prompts that come with that flow.

>
> - Carsten
>
>>
>> I hit "C-c x d" to move to "DELEGATED", I get prompted for a note, but
>> the note is not stored as a sub item of the parent task anymore. In
>> fact
>> I don't know where it is stored.

Re: Categories

[Carsten Dominik]

On Oct 13, 2007, at 14:22, Richard G Riley wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> On Oct 12, 2007, at 19:20, Richard G Riley wrote:
>>> I have a possible bug here (5.12). When embedding the CATEGORY as a
>>> property e.g in my org file
>>
>> Yes, logging state changes is broken in 5.12, *#$&*&#&$.
>>
>> Fixed in 5.12c, thanks.
>>
>>> ,----
>>> |  '(org-agenda-custom-commands
>>> |    (quote (
>>> | 	   ("d" org-todo "DELEGATED" nil)
>>> |            ("c" org-todo "DONE|DEFERRED|CANCELLED" nil)
>>> |            ("w" org-todo "WAITING" nil)
>>> | 	   ("W" agenda ""
>>> `----
>
> I took this from a tutorial out there in google land.
>
>>
>>
>> What an innovative way of totally misusing org-agenda-custom-commands.
>> `C-c a d' will indeed change a TODO state, something
>> org-agenda-custom-commands
>> was not designed for (and which I do not recommend...)!
>>
>> But "c" will not work, the symbol for creating a TODO list is
>> `alltodo', not `org-todo'.
>
> I'm not sure I understand, but I will remove this regardless. Why are
> you mentioning creating a TODO list?

All the commands in org-agenda-custom-commands are intended to
create some kind of list, either an agenda view, or a sparse tree.
But, since in the end they call a function, someone has used this
to create commands to directly jump to a state.

>  The commands above are "jumpt to
> state commands - not create commands. So, if the code I cribbed above 
> is
> not correct, how is the best way to add commands to agenda mode - its
> not obvious how to jump straight to a state as opposed to cycling to it
> manually with all the note prompts that come with that flow.

The recommended way is to set up keys for the TODO keywords like this:

#+SEQ_TODO: TODO(t) WAITING(w) | DONE(d)

(you can also do this in lisp customization)

If you then call C-c C-t with a prefix arg (i.e. C-c C-c C-t)
you can directly jump to any state.  If you like that a lot,
you can even get this interface without the prefix argument, by
setting the variable org-use-fast-todo-selection to t.

- Carsten