From: Nick Dokos <nicholas.dokos@hp.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: emacs-orgmode@gnu.org, nicholas.dokos@hp.com, throaway@yahoo.com
Subject: Re: Bug: Recurring items NEVER show up in timeline unaccompanied
Date: Thu, 24 Mar 2011 14:40:37 -0400 [thread overview]
Message-ID: <3336.1300992037@alphaville.usa.hp.com> (raw)
In-Reply-To: Message from Carsten Dominik <carsten.dominik@gmail.com> of "Thu, 24 Mar 2011 08:08:07 BST." <6E34140C-D706-496F-AE7A-91406C04F163@gmail.com>
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
next prev parent reply other threads:[~2011-03-24 18:40 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-14 19:02 Recurring items don't always show up in timeline Mark S
2011-03-14 20:36 ` Chris Randle
2011-03-14 22:36 ` Mark S
2011-03-15 15:39 ` Chris Randle
2011-03-14 22:55 ` Mark S
2011-03-14 23:29 ` Nick Dokos
2011-03-15 15:57 ` Chris Randle
2011-03-15 16:59 ` Nick Dokos
2011-03-15 18:17 ` Chris Randle
2011-03-15 17:34 ` Mark S
2011-03-15 18:20 ` Chris Randle
2011-03-16 17:06 ` Mark S
2011-03-18 19:58 ` Bug: " Mark S
2011-03-18 21:20 ` Nick Dokos
2011-03-19 17:45 ` Chris Randle
2011-03-19 18:46 ` Nick Dokos
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 [this message]
2011-03-24 17:31 ` Mark S
2011-03-28 17:05 ` Carsten Dominik
-- strict thread matches above, loose matches on Subject: below --
2011-03-23 18:02 Mark S
2011-03-23 18:56 ` Nick Dokos
2011-03-29 17:38 Mark S
2011-03-29 17:50 ` Carsten Dominik
2011-03-29 21:59 Mark S
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3336.1300992037@alphaville.usa.hp.com \
--to=nicholas.dokos@hp.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=throaway@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).