From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernt Hansen Subject: Re: Clocking in the current task should clock it out first Date: Mon, 22 Mar 2010 20:25:50 -0400 Message-ID: <87k4t328a9.fsf@gollum.intra.norang.ca> References: <87sk7zt7w6.fsf@gollum.intra.norang.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ntrwm-0000FL-H0 for emacs-orgmode@gnu.org; Mon, 22 Mar 2010 20:26:16 -0400 Received: from [140.186.70.92] (port=58909 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntrwl-0000Ca-0h for emacs-orgmode@gnu.org; Mon, 22 Mar 2010 20:26:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ntrwj-0002QN-8u for emacs-orgmode@gnu.org; Mon, 22 Mar 2010 20:26:14 -0400 Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:54747) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ntrwj-0002Pz-6Q for emacs-orgmode@gnu.org; Mon, 22 Mar 2010 20:26:13 -0400 In-Reply-To: (Carsten Dominik's message of "Fri\, 19 Mar 2010 18\:36\:02 +0100") 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: Carsten Dominik , John Wiegley Cc: Org-mode Org-Mode Hi, I tried playing with this again last weekend and I can't get it to break on my Linux machine with GNU Emacs 22.2.1 I've seen it break (at least once) on windows at work... but I haven't tried to reproduce that in my spare time. Somehow I just can't get myself to use Windows for 'fun' :-P I tried the auto clock resolution with my normal clocking setup (where the clock runs all the time, and I explicitly clock in and out regardless of todo state changes). I can't get the clock resolution/idle time code to do anything really useful in my setup. If I do org-resolve-clocks when my current task is clocking it asks for how many minutes to keep etc, and then clocks in from *now* leaving a hole in my clock data which I don't want. I'm not sure exactly how this stuff is supposed to work - maybe John can shed some light on this. I can't find documentation about resolving clocks in the regular org-mode documentation either. I remember an article John posted on the mailing list but I don't think that got into the official org-mode documentation other than the lisp functions and docstrings. I have also notice that clock resolution (in the distant past) would overlap clock times. If it finds more than one open clock it can resolve them so that they overlap with other clock entries and for me that's _really_ _really_ bad. I'd rather have it to nothing than create hard-to-find overlapping clock entries. For now I'll continue to run with org-clock-auto-clock-resolution set to nil until I understand how this is supposed to work and make life better for me :) I would really like it to be more useful than it is in my setup but I'm not really missing this functionality alot at the moment and my time to play with it is extremely limited at present. Regards, Bernt Carsten Dominik writes: > Hi, > > strangely enough, this does not happen for me. Maybe you > have some setup for clock resolution that I do not have? > > - Carsten > > On Mar 17, 2010, at 2:06 PM, Bernt Hansen wrote: > >> Daniel Clemente writes: >> >>> Hi, >>> in recent org-modes a new behaviour was added: when doing C-c C-x >>> C-i on the current task, it isn't clocked out first. It shows the >>> message =E2=80=9EClock continues in "[task]"=E2=80=9C and adds a new li= ne for the >>> clock in. >>> This creates a clock section like: >>> >>> #+BEGIN_EXAMPLE >>> *** after pressing many successive C-c C-x C-i =E2=80=A6 >>> :CLOCK: >>> CLOCK: [2010-03-17 dc 10:25]--[2010-03-17 dc 10:30] =3D> 0:05 >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-17 dc 10:20] >>> CLOCK: [2010-03-12 dv 16:38]--[2010-03-12 dv 16:39] =3D> 0:01 >>> :END: >>> #+END_EXAMPLE >>> >>> >>> They are later correctly found to be dangling clocks. >>> I presume this is a bug? >> >> Hi Daniel, >> >> Yes I believe this is a bug. I think I've also run into this issue >> but >> I have auto clock resolution disabled so this is not leaving open >> clocks >> in my setup. >> >> (setq org-clock-auto-clock-resolution nil) >> >> This of course is only a temporary work around until a real fix >> occurs. >> I haven't had the time to investigate this yet but it is on my list of >> things to look at. >> >> -Bernt >> >> >> _______________________________________________ >> Emacs-orgmode mailing list >> Please use `Reply All' to send replies to the list. >> Emacs-orgmode@gnu.org >> http://lists.gnu.org/mailman/listinfo/emacs-orgmode > > - Carsten > > > > > > _______________________________________________ > Emacs-orgmode mailing list > Please use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode