emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Ulf Stegemann <ulf-news@zeitform.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: Counter cookies and mixed checkbox lists/subtasks
Date: Fri, 17 Apr 2009 18:50:52 +0200	[thread overview]
Message-ID: <A8C1DBA9-6164-4DB8-878A-198D33CE0213@gmail.com> (raw)
In-Reply-To: <zf.upneivs3f4w.fsf@zeitform.de>

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

  reply	other threads:[~2009-04-17 16:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2009-04-20  8:00           ` Ulf Stegemann
2009-04-22  4:16             ` Carsten Dominik
2009-04-22  8:08               ` Ulf Stegemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A8C1DBA9-6164-4DB8-878A-198D33CE0213@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ulf-news@zeitform.de \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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