* Counter cookies and mixed checkbox lists/subtasks @ 2009-04-08 8:40 Ulf Stegemann 2009-04-08 14:47 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Ulf Stegemann @ 2009-04-08 8:40 UTC (permalink / raw) To: emacs-orgmode The following applies to Emacs 23.0.92 and Org 6.25trans, both checked out a few minutes ago. I'm quite fond of using counter cookies in headlines (`[/]' or `[%]'). However, when using those cookies in headlines where the body mixes up checkbox lists and subtasks org-mode changes reference of the cookie between list items and tasks depending on what has been last updated (probably due to the fact that the cookies may refer to both types). To give an example: --8<--------------------------snip-------------------------->8--- * TODO Something to do [/] - [ ] first item - [ ] second item - [ ] third item ** TODO first subtask ** TODO second subtask --8<--------------------------snap-------------------------->8--- Now, when checking a check box this would look like: --8<--------------------------snip-------------------------->8--- * TODO Something to do [1/3] - [x] first item - [ ] second item - [ ] third item ** TODO first subtask ** TODO second subtask --8<--------------------------snap-------------------------->8--- Given that, changing the state of a subtask will lead to: --8<--------------------------snip-------------------------->8--- * TODO Something to do [1/2] - [x] first item - [ ] second item - [ ] third item ** DONE first subtask ** TODO second subtask --8<--------------------------snap-------------------------->8--- So the question is: Is it possible to give the counter cookie a clear reference, i.e. always counting the checkbox list *or* the subtasks? Ulf ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-08 8:40 Counter cookies and mixed checkbox lists/subtasks Ulf Stegemann @ 2009-04-08 14:47 ` Carsten Dominik 2009-04-16 9:05 ` Ulf Stegemann 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2009-04-08 14:47 UTC (permalink / raw) To: Ulf Stegemann; +Cc: emacs-orgmode Hi Ulf, there is no way currently to force a cookie either way. I think the the right solution is to modify the structure, so that the check boxes are only in entries without children. Seems to me that this is always possible - in your case you could just create a "first child" that gets the checkboxes. - Carsten On Apr 8, 2009, at 10:40 AM, Ulf Stegemann wrote: > The following applies to Emacs 23.0.92 and Org 6.25trans, both checked > out a few minutes ago. > > I'm quite fond of using counter cookies in headlines (`[/]' or `[%]'). > However, when using those cookies in headlines where the body mixes up > checkbox lists and subtasks org-mode changes reference of the cookie > between list items and tasks depending on what has been last updated > (probably due to the fact that the cookies may refer to both types). > > To give an example: > > --8<--------------------------snip-------------------------->8--- > * TODO Something to do [/] > > - [ ] first item > - [ ] second item > - [ ] third item > > ** TODO first subtask > ** TODO second subtask > --8<--------------------------snap-------------------------->8--- > > Now, when checking a check box this would look like: > > --8<--------------------------snip-------------------------->8--- > * TODO Something to do [1/3] > > - [x] first item > - [ ] second item > - [ ] third item > > ** TODO first subtask > ** TODO second subtask > --8<--------------------------snap-------------------------->8--- > > Given that, changing the state of a subtask will lead to: > > --8<--------------------------snip-------------------------->8--- > * TODO Something to do [1/2] > > - [x] first item > - [ ] second item > - [ ] third item > > ** DONE first subtask > ** TODO second subtask > --8<--------------------------snap-------------------------->8--- > > So the question is: Is it possible to give the counter cookie a clear > reference, i.e. always counting the checkbox list *or* the subtasks? > > Ulf > > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-08 14:47 ` Carsten Dominik @ 2009-04-16 9:05 ` Ulf Stegemann 2009-04-16 11:45 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Ulf Stegemann @ 2009-04-16 9:05 UTC (permalink / raw) To: emacs-orgmode Hi Carsten, Carsten Dominik <carsten.dominik@gmail.com> wrote: > there is no way currently to force a cookie either way. > > I think the the right solution is to modify the structure, so > that the check boxes are only in entries without children. > Seems to me that this is always possible - in your case > you could just create a "first child" that gets the checkboxes. okay, as said, this is rather a minor annoyance. However, fixing this might nevertheless be desirable since the combination of checkboxes and todo item is quite powerful. Imagine you are compiling a document where you need contributions from others. You could make a todo item for this with checkboxes for every chapter planned (or for every author you expect input from, or ...). As soon as contributions from authors arrive, you create todo items preferably below the same initial todo item, indicating that you have to integrate input. When compiling the document you finish those todo items on the one hand and on the other hand checkboxes will eventually get checked as chapters are finished. Although putting the chapter checkboxes into its own sub-item is possible, much of the simplicity and elegance of the original approach gets lost. What do you think? Ulf ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-16 9:05 ` Ulf Stegemann @ 2009-04-16 11:45 ` Carsten Dominik 2009-04-16 13:24 ` Ulf Stegemann 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2009-04-16 11:45 UTC (permalink / raw) To: Ulf Stegemann; +Cc: emacs-orgmode On Apr 16, 2009, at 11:05 AM, Ulf Stegemann wrote: > Hi Carsten, > > Carsten Dominik <carsten.dominik@gmail.com> wrote: > >> there is no way currently to force a cookie either way. >> >> I think the the right solution is to modify the structure, so >> that the check boxes are only in entries without children. >> Seems to me that this is always possible - in your case >> you could just create a "first child" that gets the checkboxes. > > okay, as said, this is rather a minor annoyance. However, fixing this > might nevertheless be desirable since the combination of checkboxes > and > todo item is quite powerful. > > Imagine you are compiling a document where you need contributions from > others. You could make a todo item for this with checkboxes for every > chapter planned (or for every author you expect input from, or ...). > As > soon as contributions from authors arrive, you create todo items > preferably below the same initial todo item, indicating that you > have to > integrate input. When compiling the document you finish those todo > items > on the one hand and on the other hand checkboxes will eventually get > checked as chapters are finished. Although putting the chapter > checkboxes into its own sub-item is possible, much of the simplicity > and > elegance of the original approach gets lost. What do you think? Well, I don't really agree. * TODO compile document [ ] get input from Chris [ ] get input from Alice ** TODO integrate input from Chris ** TODO integrate input from Alice. You could easily do: * TODO compile document ** Get input [ ] get input from Chris [ ] get input from Alice ** TODO integrate input from Chris ** TODO integrate input from Alice. This is what I mean with "you can always restructure to avoid the problem". I think the second option is at least as clear, maybe clearer. I do like the simplicity of the cookies right now, adding specifiers of what they refere to would make them less usable in my mind. - Carsten ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-16 11:45 ` Carsten Dominik @ 2009-04-16 13:24 ` Ulf Stegemann 2009-04-17 16:50 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Ulf Stegemann @ 2009-04-16 13:24 UTC (permalink / raw) To: emacs-orgmode Hi Carsten, Carsten Dominik <carsten.dominik@gmail.com> wrote: > On Apr 16, 2009, at 11:05 AM, Ulf Stegemann wrote: > >> Imagine you are compiling a document where you need contributions from >> others. You could make a todo item for this with checkboxes for every >> chapter planned (or for every author you expect input from, or ...). As >> soon as contributions from authors arrive, you create todo items >> preferably below the same initial todo item, indicating that you have to >> integrate input. When compiling the document you finish those todo items >> on the one hand and on the other hand checkboxes will eventually get >> checked as chapters are finished. Although putting the chapter >> checkboxes into its own sub-item is possible, much of the simplicity and >> elegance of the original approach gets lost. What do you think? > > Well, I don't really agree. > > * TODO compile document > [ ] get input from Chris > [ ] get input from Alice > ** TODO integrate input from Chris > ** TODO integrate input from Alice. > > You could easily do: > > * TODO compile document > ** Get input > [ ] get input from Chris > [ ] get input from Alice > ** TODO integrate input from Chris > ** TODO integrate input from Alice. > > This is what I mean with "you can always restructure > to avoid the problem". I think the second option is at > least as clear, maybe clearer. yes, certainly restructuring is an option but not necessarily a satisfying one. I've probably missed to make the example clear enough. Let's look at the checkbox part of the (top-level) todo item as a sort of list of milestones. They certainly belong to the (top-level) todo and are usually well defined from the very beginning. When the whole thing gets started, todos pop in and they are added to the original todo item ad hoc. Those todo items could be of varying quality, some simple 10-minutes jobs, others more complex, possibly with sub-items of their own. However, in respect of measuring the top-level todo item's progress, they are irrelevant, only milestones count. Outsourcing the milestones into a sub-item is in my opinion not clearer since the milestones really belong to the top-level and not the newly created sub-item. Furthermore, the integral difference between milestones and other todos blurs. A logically better solution would be to turn every checkbox item into an ordinary todo item and assign each new (non-milestone) todo to the relevant milestone item. This however would increase complexity of the whole structure and would pose problems with todos that do not belong to a single milestone. Of course, the current behaviour of Org does not hinder anyone to use a structure as outlined above (giving a great bunch of freedom to users on how to organise themselves is one of the great strength of Org IMHO). What's currently counted by the cookie is usually easy to recognise and that's why I said this is really a minor issue. Apart from all pros and cons on different structures there might be another reason to deal with the cookie issue: IMHO it's very close to a bug (although not a programming bug). Why? Because Org does something the user does not expect and (what's worse) is not really useful. When encountering an item with mixed types (checkboxes and sub-items), Org counter cookies could count a) all items and checkboxes, b) only one type (items or checkboxes) or c) the first type that appears in the item. All these option would make a certain sense. But counting the type that has been updated last is confusing and not really useful. Maybe it's already enough to describe the current behaviour in the docs. > I do like the simplicity of the cookies right now, adding specifiers > of what they refere to would make them less usable in my mind. I totally agree that the simplicity of the cookies should remain. Defining a reference should only be necessary if you have an item with mixed types below /and/ if you are not satisfied with the default behaviour. Sorry for that rather lengthy reply. It was not meant to steal your time by discussing a minor issue. Ulf ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-16 13:24 ` Ulf Stegemann @ 2009-04-17 16:50 ` Carsten Dominik 2009-04-20 8:00 ` Ulf Stegemann 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2009-04-17 16:50 UTC (permalink / raw) To: Ulf Stegemann; +Cc: emacs-orgmode Hmmm, I am still not convinced, in particular about adding new syntax. One thing I could imagine though, is this: If an entry has checkboxes, always put those into the cookie, not the children. Or maybe a variable, stating your preference for this. This would at least give predictable behavior. - Carsten On Apr 16, 2009, at 3:24 PM, Ulf Stegemann wrote: > Hi Carsten, > > Carsten Dominik <carsten.dominik@gmail.com> wrote: > >> On Apr 16, 2009, at 11:05 AM, Ulf Stegemann wrote: >> >>> Imagine you are compiling a document where you need contributions >>> from >>> others. You could make a todo item for this with checkboxes for >>> every >>> chapter planned (or for every author you expect input from, >>> or ...). As >>> soon as contributions from authors arrive, you create todo items >>> preferably below the same initial todo item, indicating that you >>> have to >>> integrate input. When compiling the document you finish those todo >>> items >>> on the one hand and on the other hand checkboxes will eventually get >>> checked as chapters are finished. Although putting the chapter >>> checkboxes into its own sub-item is possible, much of the >>> simplicity and >>> elegance of the original approach gets lost. What do you think? >> >> Well, I don't really agree. >> >> * TODO compile document >> [ ] get input from Chris >> [ ] get input from Alice >> ** TODO integrate input from Chris >> ** TODO integrate input from Alice. >> >> You could easily do: >> >> * TODO compile document >> ** Get input >> [ ] get input from Chris >> [ ] get input from Alice >> ** TODO integrate input from Chris >> ** TODO integrate input from Alice. >> >> This is what I mean with "you can always restructure >> to avoid the problem". I think the second option is at >> least as clear, maybe clearer. > > yes, certainly restructuring is an option but not necessarily a > satisfying one. I've probably missed to make the example clear enough. > > Let's look at the checkbox part of the (top-level) todo item as a sort > of list of milestones. They certainly belong to the (top-level) todo > and > are usually well defined from the very beginning. When the whole thing > gets started, todos pop in and they are added to the original todo > item > ad hoc. Those todo items could be of varying quality, some simple > 10-minutes jobs, others more complex, possibly with sub-items of their > own. However, in respect of measuring the top-level todo item's > progress, they are irrelevant, only milestones count. > > Outsourcing the milestones into a sub-item is in my opinion not > clearer > since the milestones really belong to the top-level and not the newly > created sub-item. Furthermore, the integral difference between > milestones and other todos blurs. > > A logically better solution would be to turn every checkbox item > into an > ordinary todo item and assign each new (non-milestone) todo to the > relevant milestone item. This however would increase complexity of the > whole structure and would pose problems with todos that do not > belong to > a single milestone. > > Of course, the current behaviour of Org does not hinder anyone to > use a > structure as outlined above (giving a great bunch of freedom to > users on > how to organise themselves is one of the great strength of Org IMHO). > What's currently counted by the cookie is usually easy to recognise > and > that's why I said this is really a minor issue. > > Apart from all pros and cons on different structures there might be > another reason to deal with the cookie issue: IMHO it's very close > to a > bug (although not a programming bug). Why? Because Org does something > the user does not expect and (what's worse) is not really useful. When > encountering an item with mixed types (checkboxes and sub-items), Org > counter cookies could count a) all items and checkboxes, b) only one > type (items or checkboxes) or c) the first type that appears in the > item. All these option would make a certain sense. But counting the > type > that has been updated last is confusing and not really useful. Maybe > it's already enough to describe the current behaviour in the docs. > >> I do like the simplicity of the cookies right now, adding specifiers >> of what they refere to would make them less usable in my mind. > > I totally agree that the simplicity of the cookies should remain. > Defining a reference should only be necessary if you have an item with > mixed types below /and/ if you are not satisfied with the default > behaviour. > > Sorry for that rather lengthy reply. It was not meant to steal your > time > by discussing a minor issue. > > Ulf > > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-17 16:50 ` Carsten Dominik @ 2009-04-20 8:00 ` Ulf Stegemann 2009-04-22 4:16 ` Carsten Dominik 0 siblings, 1 reply; 9+ messages in thread From: Ulf Stegemann @ 2009-04-20 8:00 UTC (permalink / raw) To: emacs-orgmode Hi Carsten, Carsten Dominik <carsten.dominik@gmail.com> wrote: > Hmmm, I am still not convinced, in particular about adding new syntax. > > One thing I could imagine though, is this: > If an entry has checkboxes, always put those into the cookie, not the > children. > Or maybe a variable, stating your preference for this. This would at least > give predictable behavior. or how about a property? Ulf ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-20 8:00 ` Ulf Stegemann @ 2009-04-22 4:16 ` Carsten Dominik 2009-04-22 8:08 ` Ulf Stegemann 0 siblings, 1 reply; 9+ messages in thread From: Carsten Dominik @ 2009-04-22 4:16 UTC (permalink / raw) To: Ulf Stegemann; +Cc: emacs-orgmode On Apr 20, 2009, at 10:00 AM, Ulf Stegemann wrote: > Hi Carsten, > > Carsten Dominik <carsten.dominik@gmail.com> wrote: > >> Hmmm, I am still not convinced, in particular about adding new >> syntax. >> >> One thing I could imagine though, is this: >> If an entry has checkboxes, always put those into the cookie, not the >> children. >> Or maybe a variable, stating your preference for this. This would >> at least >> give predictable behavior. > > or how about a property? You win. After your next git update, set the property "COOKIE_DATA" to either "todo" or "checkbox". - Carsten > > Ulf > > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Counter cookies and mixed checkbox lists/subtasks 2009-04-22 4:16 ` Carsten Dominik @ 2009-04-22 8:08 ` Ulf Stegemann 0 siblings, 0 replies; 9+ messages in thread From: Ulf Stegemann @ 2009-04-22 8:08 UTC (permalink / raw) To: emacs-orgmode Hi Carsten, Carsten Dominik <carsten.dominik@gmail.com> wrote: > On Apr 20, 2009, at 10:00 AM, Ulf Stegemann wrote: > >> Carsten Dominik <carsten.dominik@gmail.com> wrote: >> >>> Hmmm, I am still not convinced, in particular about adding new syntax. >>> >>> One thing I could imagine though, is this: >>> If an entry has checkboxes, always put those into the cookie, not the >>> children. >>> Or maybe a variable, stating your preference for this. This would at >>> least >>> give predictable behavior. >> >> or how about a property? > > You win. > > After your next git update, set the property "COOKIE_DATA" to either "todo" > or "checkbox". great! Works like a charm here. Thank you for the effort. Ulf ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-04-22 8:08 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-08 8:40 Counter cookies and mixed checkbox lists/subtasks Ulf Stegemann 2009-04-08 14:47 ` Carsten Dominik 2009-04-16 9:05 ` Ulf Stegemann 2009-04-16 11:45 ` Carsten Dominik 2009-04-16 13:24 ` Ulf Stegemann 2009-04-17 16:50 ` Carsten Dominik 2009-04-20 8:00 ` Ulf Stegemann 2009-04-22 4:16 ` Carsten Dominik 2009-04-22 8:08 ` Ulf Stegemann
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).