Re: Re: Counter cookies and mixed checkbox lists/subtasks

[Carsten Dominik <carsten.dominik@gmail.com>]

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