From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Bug: Recurring items NEVER show up in timeline unaccompanied Date: Thu, 24 Mar 2011 08:08:07 +0100 Message-ID: <6E34140C-D706-496F-AE7A-91406C04F163@gmail.com> References: <3491.1300820358@alphaville.usa.hp.com> <3965.1300824655@alphaville.usa.hp.com> Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from [140.186.70.92] (port=55328 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q2eeU-0003o8-Nl for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 03:08:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q2eeT-0006qg-6w for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 03:08:14 -0400 Received: from mail-ey0-f169.google.com ([209.85.215.169]:51651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q2eeS-0006qQ-U0 for emacs-orgmode@gnu.org; Thu, 24 Mar 2011 03:08:13 -0400 Received: by eyh6 with SMTP id 6so2480030eyh.0 for ; Thu, 24 Mar 2011 00:08:11 -0700 (PDT) In-Reply-To: <3965.1300824655@alphaville.usa.hp.com> 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: nicholas.dokos@hp.com Cc: emacs-orgmode@gnu.org, throaway@yahoo.com Hi everyone, On 22.3.2011, at 21:10, Nick Dokos wrote: > Some more comments and another bug in org-timeline: >=20 > o a repeater always gets reported on its initial date - it only gets = reported > on subsequent instances iff it coincides with some other entry that = will be > reported on that date. >=20 > o the initial comment of org-timeline says "Only entries with a time > stamp of today or later will be listed." However, in the let*, we = have > (let* ((dopast t) > ... > so by default we get past dates as well. >=20 > o [the additional bug] if dopast is set to nil in the let*, then we = run the > following code to get rid of past dates: >=20 > (if (not dopast) > ;; Remove past dates from the list of dates. > (setq day-numbers (delq nil (mapcar (lambda(x) > (if (>=3D x today) x nil)) > day-numbers)))) >=20 > But day-numbers isn't just numbers: it's a list of day numbers > interspersed with gap information: >=20 > (733451 (:omitted . 28) 733479 (:omitted . 5) 733484 (:omitted . 21) = 733505 (:omitted . 15) 733520 ...) > and the mapcar function chokes when it has to deal with a gap = argument. >=20 >=20 > Since there is no way to set dopast from the outside, perhaps the = thing > to do is to remove both it and the above code (as well as one = additional > instance of the variable) and declare that org-timeline will always do > both past and future. Or, given some global option variable, it can be > set to that value, in which case the code above needs to be fixed to > deal with the gaps. >=20 > Also, some stopping point will need to be provided. Right now, that is > the last explicit date in the file, but in the presence of repeaters > (and assuming that org-timeline gets modified to deal with them), that > natural stopping point gets pushed all the way to infinity, so some > other way will need to be provided to stop the enumeration. Dear all, Maybe I can add the following background information to Nick's amazing analysis. - The timeline was the first agenda-like view I implemented, it used to be (many years ago) the only way to see what was coming up. That is why it only listed the future, and included the past when used with e prefix argument (I believe). - Since then the agenda view came along, with vastly better properties for being used as a planning tool for the coming day an d week. It also included the possibility to look at several files, which made the timelines view of a single file look poor. Since then, the timeline has been a more or less orphaned feature, and this is why it does not work well with stuff like repeaters (repeaters where added MUCH later). - So the use-case of the timeline view became slowly redefined as a way to look at the milestones and events of a single project. One consequence was to always include the past. - For historic reasons, the timeline uses the same mechanics as the agenda: Pick a date, find everything that is going on on that date, move on to the next date. Lather, rinse, repeat. However, when looking at a project that may have dates spread over potentially many years, this mechanics is not very practical. First, there will be many empty days where nothing is going on. This will make the view look very boring and will make it hard to find useful dates. Second, constructing the view in this way takes forever because of the inefficient pick-a-day, scan-entire-file-to-see-what-fits-strategy. - To makes things more efficient, the timeline starts by first making a list of relevant days in the project by looking at all explicit dates, and at ranges. Here is where the repeaters go wrong - they should return a whole list of dates where they are important - but they only add one, the starting date. With this list of dates, it knows how to skip ranges of dates where nothing is happening. Solutions for this problem are (these are alternatives) 1. Be satisfied with the way things are, just realize that repeaters only show up on the first date when the event happens for the first time. 2. Use the agenda, restricted to a single file, for a time range you specify. This has the advantage that also diary sexps will work properly - the timeline currently has no way to deal with these. 3. Change the section of the timeline code that produces the list of interesting dates. One strategy could be to first make a list of explicit dates, in order to define an overall range. Then find all repeaters and add dates this repeater targets, restricted to the range of explicit dates in the file. If done like this, you could always put a target date for conclusion of the project into the file, and that far-into-the-future date would define the range of the repeaters automatically. 4. Define a variable that will make the timeline always look at *every* date in the range covered by the file. And live with the fact that constructing the view might take long. Maybe it will not even to terribly long if you really use this view for single projects. This would be easy to implement. 5. Rebuilt the entire timeline view to not use the agendas mechanics of picking a date, scanning the file, picking a date etc. Instead, do a single pass over the file and build a list of dates with events in this way and then format and display the list. Disadvantage here would be that many things which now work easily, like log view to include logging dates, would have to be thought over and reimplemented specially for the timeline. Hope this helps. - Carsten =20