From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Changing TODO state to DONE does not stop clock in frame Date: Sun, 22 Mar 2009 16:45:41 +0100 Message-ID: <3144EAA7-8ABF-4AC7-B31E-2733031A024D@uva.nl> References: <1FA17072-1917-414E-8AA8-2084343E97AB@uva.nl> 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 1LlPrw-0008BV-NP for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:45:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlPrs-00088h-9l for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:45:48 -0400 Received: from [199.232.76.173] (port=49067 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlPrs-00088e-6v for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:45:44 -0400 Received: from mail-ew0-f160.google.com ([209.85.219.160]:42645) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlPrr-0000SS-Ot for emacs-orgmode@gnu.org; Sun, 22 Mar 2009 11:45:44 -0400 Received: by ewy4 with SMTP id 4so1738839ewy.42 for ; Sun, 22 Mar 2009 08:45:43 -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: Matthew Lundin Cc: emacs-orgmode@gnu.org, Carsten Dominik On Mar 21, 2009, at 9:43 PM, Matthew Lundin wrote: > >> On Mar 19, 2009, at 1:26 PM, Chris Randle wrote: > >>> I've noticed that, when working in the new frame, changing the TODO >>> state of any item within the frame to DONE (when it is the currently >>> clocked in item) does not stop the clock. Going back to my main >>> frame >>> and doing the same thing there on the same item does stop the clock. > > Carsten Dominik writes: > >> I am no able to reproduce this. Can anyone else try, please? >> >> - Carsten > > I just tested it (with org from the git repo). The problem seems to > occur when a clock is started on an item before the indirect buffer is > created. In other words, the clock did not stop when I followed these > steps: > > 1. Clocked into an item. > > 2. Created an indirect buffer. > > 3. Clocked out within the indirect buffer. I am still unable to reproduce this. - Carsten