Re: [O] Bug: Recurring items NEVER show up in timeline unaccompanied

[Carsten Dominik]

Hi everyone,

On 22.3.2011, at 21:10, Nick Dokos wrote:

> Some more comments and another bug in org-timeline:
> 
> 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.
> 
> 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.
> 
> 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:
> 
>    (if (not dopast)
>       ;; Remove past dates from the list of dates.
>       (setq day-numbers (delq nil (mapcar (lambda(x)
>                                             (if (>= x today) x nil))
>                                           day-numbers))))
> 
>  But day-numbers isn't just numbers: it's a list of day numbers
>  interspersed with gap information:
> 
>   (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.
> 
> 
> 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.
> 
> 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