emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-18 19:58   ` Bug: " Mark S
@ 2011-03-22 18:43     ` Mark S
  2011-03-22 18:59       ` Nick Dokos
  2011-03-24 17:31       ` Mark S
  0 siblings, 2 replies; 12+ messages in thread
From: Mark S @ 2011-03-22 18:43 UTC (permalink / raw)
  To: emacs-orgmode


You know, I think this may be the same bug I ran into 3 years ago when I  
last tried Org-mode. Is there any hope that this will be addressed? I note  
that this forum is the only location given for sending bug reports in the  
documentation.

Thanks!
Mark

--- On Sat, 3/19/11, Nick Dokos <nicholas.dokos@hp.com> wrote:

> From: Nick Dokos <nicholas.dokos@hp.com>
> Subject: Re: [O] Bug: Recurring items don't always show up in timeline
> To: "Chris Randle" <chris@amlog.co.uk>
> Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org
> Date: Saturday, March 19, 2011, 11:46 AM
> Chris Randle <chris@amlog.co.uk>
> wrote:
>> On 2011-03-18 21:20, Nick Dokos wrote:
> > > Mark S<throaway@yahoo.com>wrote:
> > >
> > >> I posted this before as a question, but since
> it has been confirmed by
> > >> others, and shows up under Linux and Windows,
> I'll now post the
> > >> details as a bug.
> > >>
> > >> The Timeline view *would* be very useful for
> scheduling months in
> > >> advance, reviewing history, or printing a
> year event
> > >> calendar. Unfortunately, it appears that it
> can't really be trusted.
> > >> The basic problem is that in AGENDA TIMELINE
> view ("C-a L") recurring
> > >> items are frequently and unpredictably
> dropped from the view. The
> > >> regular AGENDA view works fine AFAIK -- its
> the TIMELINE that is at
> > >> issue.
> > >
> > > AFAICT, the culprit is org-get-all-dates: it
> matches date strings, translates
> > > to number of days since the (imaginary) date
> 0001-12-31bce,
> > > accumulates them in a list, sorts them, takes
> care of gaps - but
> > > completely ignores any repeaters: iow, the "don't
> always show" in the
> > > Subject line should more accurately say "never
> show".
> >> Unless I'm missing something (again!), when I try it,
> they *do* repeat
> > *sometimes*. For example, the entry
> >> TODO [#A] Bath for dog <2011-03-10 Thu +1w>
> >> appears in agenda timeline as follows:
> >> 2011-03-10, miss 1 week, 2011-03-24, 2011-03-31,
> 2011-04-07, miss 7
> > weeks, 2011-06-02, miss 8 weeks (agenda terminates
> 2011-07-31).
> >That's true. I believe that's when it coincides with
> another entry: it
> sneaks in on the heels of the other entry. But I may very
> well be wrong:
> I have only scratched the surface a bit.
>Nick
>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-22 18:43     ` Bug: Recurring items NEVER show up in timeline unaccompanied Mark S
@ 2011-03-22 18:59       ` Nick Dokos
  2011-03-22 20:10         ` Nick Dokos
  2011-03-24 17:31       ` Mark S
  1 sibling, 1 reply; 12+ messages in thread
From: Nick Dokos @ 2011-03-22 18:59 UTC (permalink / raw)
  To: throaway; +Cc: nicholas.dokos, emacs-orgmode

Mark S <throaway@yahoo.com> wrote:

> 
> You know, I think this may be the same bug I ran into 3 years ago when I  
> last tried Org-mode. Is there any hope that this will be addressed? I note  
> that this forum is the only location given for sending bug reports in the  
> documentation.
> 
> Thanks!
> Mark
> 

I went looking for a bug report but the only thing that I can find
posted by you was a thread on "Getting org-agenda-sorting-strategy to
work" - nothing about the timeline.  I also searched for timeline and
although there was a fair amount of activity in 2008, none of it seemed
related to this bug (I might have overlooked it of course). Can you
provide a pointer to the bug report?

Be that as it may, it will certainly be addressed when somebody provides
a patch and the maintainer applies it. *When* that will be is anybody's
guess of course (remember, everybody is a volunteer here with a day job
that might or might not leave much time for org bug fixing).  But
generally speaking, once a bug bubbles to the surface, it does not stay
a bug for long.

And finally: this is the right place to post bug reports.

HTH,
Nick

PS. BTW, if you gave up on org because the timeline was not working, you
have been missing out on a bunch of good things :-) Even with a broken
timeline, org is incredibly useful. And some of us (both Chris and I e.g.,
who have been most active in the recent discussion) have never used the
timeline at all...

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-22 18:59       ` Nick Dokos
@ 2011-03-22 20:10         ` Nick Dokos
  2011-03-24  7:08           ` Carsten Dominik
  0 siblings, 1 reply; 12+ messages in thread
From: Nick Dokos @ 2011-03-22 20:10 UTC (permalink / raw)
  To: throaway; +Cc: nicholas.dokos, emacs-orgmode

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.

Comments?

Nick

  

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
@ 2011-03-23 18:02 Mark S
  2011-03-23 18:56 ` Nick Dokos
  0 siblings, 1 reply; 12+ messages in thread
From: Mark S @ 2011-03-23 18:02 UTC (permalink / raw)
  To: emacs-orgmode

Hi Nick,

Lisp tends to bring out my inner dyslexic,  but is it possible to use a  
"while" or other construct instead of "mapcar" and then make the "if"  
construction inside of the lambda check for the :omitted symbol and return  
it as nil? And it would need to break out of the loop as soon as it  
encountered a date equal or greater to the present.

Philosophically, the way I think the calendar should work for recurring  
events is that they only occur until the last event in the calendar UNLESS  
an argument has been given to specify how far out the calendar is to be  
drawn OR there is a global end-date / end-range variable.

Mark


--- On Tue, 3/22/11, Nick Dokos <nicholas.dokos@hp.com> wrote:

> From: Nick Dokos <nicholas.dokos@hp.com>
> Subject: Re: [O] Bug: Recurring items NEVER show up in timeline  
> unaccompanied
> To: throaway@yahoo.com
> Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org
> Date: Tuesday, March 22, 2011, 1:10 PM
> 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.
>Comments?
>Nick
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-23 18:02 Mark S
@ 2011-03-23 18:56 ` Nick Dokos
  0 siblings, 0 replies; 12+ messages in thread
From: Nick Dokos @ 2011-03-23 18:56 UTC (permalink / raw)
  To: throaway; +Cc: nicholas.dokos, emacs-orgmode

Mark S <throaway@yahoo.com> wrote:

> 
> Lisp tends to bring out my inner dyslexic,  but is it possible to use
> a "while" or other construct instead of "mapcar" and then make the
> "if" construction inside of the lambda check for the :omitted symbol
> and return it as nil? And it would need to break out of the loop as
> soon as it encountered a date equal or greater to the present.
> 
> Philosophically, the way I think the calendar should work for
> recurring events is that they only occur until the last event in the
> calendar UNLESS an argument has been given to specify how far out the
> calendar is to be drawn OR there is a global end-date / end-range
> variable.
> 
 
The bug is indeed easy to fix. What's harder is to figure out how things
*should* work as you point out:

o where should it start? should the timeline include past dates by
  default? when the user says so? should it *ever* include past dates?

o where should it stop? The last explicit entry is one possibility,
  user-input is another (but this would require changes to the user
  interface), a time limit specified by the user in some configuration
  variable is a third.

The more one looks at these things, the more one marvels at the choices
that Carsten and Bastien and Nicolas and the Babel developers (and on and
on) have made: getting things so that they work *just* right most of the
time and providing enough flexibility to cover most of the remaining
cases is hard work.

Nick

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-22 20:10         ` Nick Dokos
@ 2011-03-24  7:08           ` Carsten Dominik
  2011-03-24 18:40             ` Nick Dokos
  0 siblings, 1 reply; 12+ messages in thread
From: Carsten Dominik @ 2011-03-24  7:08 UTC (permalink / raw)
  To: nicholas.dokos; +Cc: emacs-orgmode, throaway

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  

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-22 18:43     ` Bug: Recurring items NEVER show up in timeline unaccompanied Mark S
  2011-03-22 18:59       ` Nick Dokos
@ 2011-03-24 17:31       ` Mark S
  2011-03-28 17:05         ` Carsten Dominik
  1 sibling, 1 reply; 12+ messages in thread
From: Mark S @ 2011-03-24 17:31 UTC (permalink / raw)
  To: emacs-orgmode

Hello Carsten et al,

--- On Thu, 3/24/11, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> 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.

This would mean that you could never *trust* the
timeline when dealing with events more than a week or
two out. You would always have that lingering worry
that you forgot to bump one of the repeaters.

> 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.

This would be great if there were a "sparse"
agenda. There isn't a way to make the agenda not show
empty days is there? As it is, if you make an agenda
extending out a year, you will have to wade through
several hundred lines worth of empty days.

> 3. Change the section of the timeline code that
>    produces the list of interesting dates.

That seems like a good solution. Is it difficult?

> 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.

This would work too, I think. Creating an agenda that
goes out one year only took about 3 seconds on my
not-state-of-the-art machine. Presumably the timeline
would be faster, since it wouldn't produce all the
extra gap lines.

Actually, when I tried to make a year long agenda using
v-y I spent just about as much getting past the "are
you sure" screens as it took to build the agenda.

The ideal solution would be that the Timeline view
would process dates exactly like the agenda, including
multiple-files, but display them like the traditional
timeline, with ranges of dates omitted.

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-24  7:08           ` Carsten Dominik
@ 2011-03-24 18:40             ` Nick Dokos
  0 siblings, 0 replies; 12+ messages in thread
From: Nick Dokos @ 2011-03-24 18:40 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: emacs-orgmode, nicholas.dokos, throaway

Carsten Dominik <carsten.dominik@gmail.com> wrote:

> Dear all,
> 
> Maybe I can add the following background information to Nick's
> amazing analysis.

I wouldn't call it "amazing", but thanks for the kind words!

> 
> - 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.
> 

A very interesting history lesson: thanks very much for that.

> 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.
> 

And a very clear analysis of the situation. In these possibilities,
there is the underlying assumption that the timeline is kept as a
feature. What about the additional possibility of actually declaring it
obsolete and getting rid of it? Can the agenda (possibly with some
extension) cover the need of Mark S for omitting days where nothing
happens?  Is there anything else that the timeline offers?

> Hope this helps.

Extremely helpful, thanks!

Nick

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-24 17:31       ` Mark S
@ 2011-03-28 17:05         ` Carsten Dominik
  0 siblings, 0 replies; 12+ messages in thread
From: Carsten Dominik @ 2011-03-28 17:05 UTC (permalink / raw)
  To: throaway; +Cc: emacs-orgmode


On 24.3.2011, at 18:31, Mark S wrote:

> Hello Carsten et al,
> 
> --- On Thu, 3/24/11, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> 
>> 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.
> 
> This would mean that you could never *trust* the
> timeline when dealing with events more than a week or
> two out. You would always have that lingering worry
> that you forgot to bump one of the repeaters.
> 
>> 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.
> 
> This would be great if there were a "sparse"
> agenda. There isn't a way to make the agenda not show
> empty days is there? As it is, if you make an agenda
> extending out a year, you will have to wade through
> several hundred lines worth of empty days.
> 
>> 3. Change the section of the timeline code that
>>   produces the list of interesting dates.
> 
> That seems like a good solution. Is it difficult?
> 
>> 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.
> 
> This would work too, I think. Creating an agenda that
> goes out one year only took about 3 seconds on my
> not-state-of-the-art machine. Presumably the timeline
> would be faster, since it wouldn't produce all the
> extra gap lines.
> 
> Actually, when I tried to make a year long agenda using
> v-y I spent just about as much getting past the "are
> you sure" screens as it took to build the agenda.
> 
> The ideal solution would be that the Timeline view
> would process dates exactly like the agenda, including
> multiple-files, but display them like the traditional
> timeline, with ranges of dates omitted.

This is already possible, by binding the variable
org-agenda-show-all-dates to nil around the call to make
the agenda (for examples using the options section of a
custom agenda command).  So the only missing piece for
your preferred solution is the determination of starting
dates and end date in  a useful and automatic way.  Maybe
I can take a look some time this week and see if 
there is a simple way to replace the time line with
something better.

- Carsten

> 
> Mark
> 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
@ 2011-03-29 17:38 Mark S
  2011-03-29 17:50 ` Carsten Dominik
  0 siblings, 1 reply; 12+ messages in thread
From: Mark S @ 2011-03-29 17:38 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org

Hello Carsten et al,


--- On Mon, 3/28/11, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> > The ideal solution would be that the Timeline view
> > would process dates exactly like the agenda,
> including
> > multiple-files, but display them like the traditional
> > timeline, with ranges of dates omitted.
>This is already possible, by binding the variable
> org-agenda-show-all-dates to nil around the call to make
> the agenda (for examples using the options section of a
> custom agenda command).  So the only missing piece
> for
> your preferred solution is the determination of starting
> dates and end date in  a useful and automatic
> way.  Maybe
> I can take a look some time this week and see ifthere is a simple way to  
> replace the time line with
> something better.


Maybe I spoke too soon. I tried the org-agenda-show-all-dates == nil.  
Although it worked, without the warning about the month-long gaps it was a  
bit hard to navigate. It was easier to navigate a full year of complete  
agenda weeks. Its a shame I'm the only one to have noticed how handy the  
(L) Timeline feature is ;-) Its output was (is) nice and clean. It was the  
first thing I tried when I was looking to set up an appointment several  
months down the road. I suppose I could do my own "recurrences" by hand.

Mark



 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
  2011-03-29 17:38 Mark S
@ 2011-03-29 17:50 ` Carsten Dominik
  0 siblings, 0 replies; 12+ messages in thread
From: Carsten Dominik @ 2011-03-29 17:50 UTC (permalink / raw)
  To: throaway; +Cc: emacs-orgmode@gnu.org


On 29.3.2011, at 19:38, Mark S wrote:

> Hello Carsten et al,
> 
> 
> --- On Mon, 3/28/11, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> 
>> > The ideal solution would be that the Timeline view
>> > would process dates exactly like the agenda,
>> including
>> > multiple-files, but display them like the traditional
>> > timeline, with ranges of dates omitted.
>> This is already possible, by binding the variable
>> org-agenda-show-all-dates to nil around the call to make
>> the agenda (for examples using the options section of a
>> custom agenda command).  So the only missing piece
>> for
>> your preferred solution is the determination of starting
>> dates and end date in  a useful and automatic
>> way.  Maybe
>> I can take a look some time this week and see ifthere is a simple way to replace the time line with
>> something better.
> 
> 
> Maybe I spoke too soon. I tried the org-agenda-show-all-dates == nil. Although it worked, without the warning about the month-long gaps it was a bit hard to navigate. It was easier to navigate a full year of complete agenda weeks. Its a shame I'm the only one to have noticed how handy the (L) Timeline feature is ;-) Its output was (is) nice and clean. It was the first thing I tried when I was looking to set up an appointment several months down the road. I suppose I could do my own "recurrences" by hand.

Can you be more specific on what is so handy about the timeline format, that you do not get in the agenda?  Is it only the notice about the left-out days?  Or other things as well?

- Carsten

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Bug: Recurring items NEVER show up in timeline unaccompanied
@ 2011-03-29 21:59 Mark S
  0 siblings, 0 replies; 12+ messages in thread
From: Mark S @ 2011-03-29 21:59 UTC (permalink / raw)
  To: emacs-orgmode@gnu.org

Hello Carsten et al,

--- On Tue, 3/29/11, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> > --- On Mon, 3/28/11, Carsten Dominik <carsten.dominik@gmail.com>
> > Maybe I spoke too soon. I tried the
> org-agenda-show-all-dates == nil. Although it worked,
> without the warning about the month-long gaps it was a bit
> hard to navigate. It was easier to navigate a full year of
> complete agenda weeks. Its a shame I'm the only one to have
> noticed how handy the (L) Timeline feature is ;-) Its output
> was (is) nice and clean. It was the first thing I tried when
> I was looking to set up an appointment several months down
> the road. I suppose I could do my own "recurrences" by
> hand.
>Can you be more specific on what is so handy about the
> timeline format, that you do not get in the agenda?  Is
> it only the notice about the left-out days?  Or other
> things as well?
>

Yes, the left-out days provide visual relief. However, probably some other  
sort of visual break -- for instance at the month boundaries -- would work  
as well. Either a space, or a month title. Something to keep the eye from  
sliding right past date changes.

I looked at the various agenda-view options, but didn't see any "month"  
setting other than to set how many days show up. By month I don't mean a  
full-blown grid calendar (though that would be nice!) but the weekly  
format with spacers (note or space) whenever the month changed.

And of course, being able to review the whole year from the start. But I  
understand I could achieve that with a customized view.

Thanks!
Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2011-03-29 21:09 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-29 21:59 Bug: Recurring items NEVER show up in timeline unaccompanied Mark S
  -- strict thread matches above, loose matches on Subject: below --
2011-03-29 17:38 Mark S
2011-03-29 17:50 ` Carsten Dominik
2011-03-23 18:02 Mark S
2011-03-23 18:56 ` Nick Dokos
2011-03-14 19:02 Recurring items don't always show up in timeline Mark S
2011-03-14 22:55 ` Mark S
2011-03-18 19:58   ` Bug: " Mark S
2011-03-22 18:43     ` Bug: Recurring items NEVER show up in timeline unaccompanied Mark S
2011-03-22 18:59       ` Nick Dokos
2011-03-22 20:10         ` Nick Dokos
2011-03-24  7:08           ` Carsten Dominik
2011-03-24 18:40             ` Nick Dokos
2011-03-24 17:31       ` Mark S
2011-03-28 17:05         ` Carsten Dominik

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).