From: Ulf Stegemann <ulf-news@zeitform.de>
To: emacs-orgmode@gnu.org
Subject: Re: Counter cookies and mixed checkbox lists/subtasks
Date: Thu, 16 Apr 2009 15:24:47 +0200 [thread overview]
Message-ID: <zf.upneivs3f4w.fsf@zeitform.de> (raw)
In-Reply-To: BD276E26-850C-4928-BE33-D6D5705B3790@gmail.com
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
next prev parent reply other threads:[~2009-04-16 13:25 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=zf.upneivs3f4w.fsf@zeitform.de \
--to=ulf-news@zeitform.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
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).