From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Counter cookies and mixed checkbox lists/subtasks Date: Fri, 17 Apr 2009 18:50:52 +0200 Message-ID: References: <7F5AF424-5413-44D5-A73C-A4BA6B9FB5F9@gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LurHM-0005Zp-KF for emacs-orgmode@gnu.org; Fri, 17 Apr 2009 12:51:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LurHG-0005XV-3S for emacs-orgmode@gnu.org; Fri, 17 Apr 2009 12:51:02 -0400 Received: from [199.232.76.173] (port=45291 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LurHF-0005XP-OV for emacs-orgmode@gnu.org; Fri, 17 Apr 2009 12:50:57 -0400 Received: from mail-ew0-f160.google.com ([209.85.219.160]:44403) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LurHF-00075r-5U for emacs-orgmode@gnu.org; Fri, 17 Apr 2009 12:50:57 -0400 Received: by ewy4 with SMTP id 4so977515ewy.42 for ; Fri, 17 Apr 2009 09:50:56 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Ulf Stegemann Cc: emacs-orgmode@gnu.org 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 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