From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Piotr Zielinski" Subject: Re: Re: depending TODOs, scheduling following TODOs automatically Date: Fri, 12 Oct 2007 00:54:32 +0100 Message-ID: <3c12eb8d0710111654s22e6c4e5pcaac1215c3b6b500@mail.gmail.com> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008202652.GA18426@atlantic.linksys.moosehall> <87k5pxnicj.fsf@bzg.ath.cx> <8a4d082edbc607440d4f12604b2f6332@science.uva.nl> <18295.1192118022@lap1.smtl.co.uk> <20071011163712.GC6275@odin.demosthenes.org> <27900.1192122650@lap1.smtl.co.uk> <20071011175547.GD6275@odin.demosthenes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ig7rP-0005ts-JK for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 19:54:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ig7rO-0005tY-O7 for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 19:54:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ig7rO-0005tV-Kh for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 19:54:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ig7rO-0000n8-8T for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 19:54:34 -0400 Received: by nz-out-0506.google.com with SMTP id f1so572581nzc for ; Thu, 11 Oct 2007 16:54:32 -0700 (PDT) In-Reply-To: Content-Disposition: inline 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: Leo Cc: emacs-orgmode@gnu.org Hi, I am generally against introducing very specialized features to org-mode, for the same reasons as described by others in this thread. The power of org-mode lies in simplicify of the model it offers: information is a collection of lists that can be queried in various ways. This model is simple yet powerful. For example, org-mode can be used not only to store ordinary tasks ("pay rent", every month), but also meta-tasks concerning the org-file itself ("make sure there are no stuck projects", every week). I find this simple idea of storing meta-tasks very useful. It gives your org-file "life", making it the single point of trust. As long as you remember to check your org-mode every day, you will never forget anything. Instead of following the books that tell you to "develop a habit of ..." just put this habit as an repetitive task in org-mode. Back to task dependencies. I use three tags: NEXT for enabled actions, TODO for actions that wait for the previous one on the list, and WAITING for actions that wait for something else. Whenever an action is completed, you can easily check whether the next TODO should be enabled (changed to NEXT) or not. WAITING actions (with dependencies across different lists) are more tricky, but in my experience, are quite rare. Here, if you know that completing task A will enable task Q in another part of the file, insert a meta-task "TODO enable [[Q]]" just after A. No special functionality needed, just standard linking. Of course there are some cases in which this scheme doesn't work, but these are not many, and I don't believe making them work automatically is worth the effort. This is because, in my case, most of the WAITING actions rely on external triggers (email, phone call), which are simply not automatable. Piotr