improve agenda options

[geier]

enable showing events on the next X days, e.g.:

khal agenda --days 7

should show all events in the next 7 days,

khal agenda --days 7 01.08.

should show all events from 1st to 8th of august

--days might not be the best name for that option

[geier]

also an option --events N for listing the next N events would be nice

[tvk7]

That was fast... Many Thanks.

[untitaker]

As noted in #156 the current name of the agenda command is misleading, since it limits the range of days whose events are shown. I think it should only limit the amount of events shown by default.

[untitaker]

We could also abandon all options and instead do this similarly to how git shows logs: Just print all and throw them into a pager. I'm not sure of the performance implications, we should figure out how to do lazy loading.

[geier]

I like the pager idea (and also something similar in ikhals event list). But I still would like two different behaviours.

1) event centric: just list all events in order 2) day centric: kind of like it is now, showing dates as headlines and every event that is scheduled for that day below it, meaning that events that span multiple days are displayed several times. Showing headlines for days without any scheduled events could be optional.

Lazy loading should be pretty easy, I'll get to this once I have merged event_rewrite and got deleting and modifying of single recurrence instances (and THISANDFUTURE) working.

[untitaker]

I think instead of calling them modes there should be one flag that determines whether to group events by day, which also implies repeating multi-day events.

[untitaker]

@geier I'd like to start working on this soon-ish. Should I wait for #223 or would a PR for this issue cause no conflicts?

[geier]

This really depends what you want to do. Lazy loading would probably need to be implemented again.

[untitaker]

I don't think lazy loading is related to the event class, but rather a property of get_agenda in khal.controllers, no?

[geier]

I would implement this through a new backend method which does this with SQL and I rewrote parts of the backend as well

Quoting Markus Unterwaditzer (2015-07-15 13:00:53)

I don't think lazy loading is related to the event class, but rather a property of get_agenda in khal.controllers, no?

---

Reply to this email directly or view it on GitHub: https://github.com/geier/khal/issues/93#issuecomment-121581851

[geier]

but feel free to have go at this if you want to and have the time, as long as you don't touch anything in the backend you should be good

Quoting Markus Unterwaditzer (2015-07-15 13:00:53)

I don't think lazy loading is related to the event class, but rather a property of get_agenda in khal.controllers, no?

---

Reply to this email directly or view it on GitHub: https://github.com/geier/khal/issues/93#issuecomment-121581851

[untitaker]

I wonder if we should switch to an ORM for querying the backend more flexibly. The current thing I have is rather slow (as it queries chunk-wise for each day). It streams properly and less is usable while khal is still sending SQL queries for the year 2030, but as soon as I hit G to get to the end of the list, less hangs up and I have to hit ^C which kills khal but not less.

I'm doing this without Click's echo_via_pager because that one requires us to build a string upfront. Perhaps this should be improved as well: echo_via_pager could take arbitrary iterators or files, for example.

[geier]

What flexibility would you expect could be gained from switching to an ORM?

I do agree that the current way of querying the the database sucks and I intend to improve that. E.g. I want to remove the whole collection construct, which should already reduce the number of queries. While we won't get rid of separate queries for localized and floating events this shouldn't really be exposed to the higher levels.

Currently I'm thinking of something like this:

def get_events_at(self, at=datetime):
   """get all events at datetime"""
    returns list of Events

def get_events_onnself, on=date):
    "get all events that are on date"""

def get_events_from(self, start=datetime, end=None):
    return an iterator that lazily gets new events from the db

I'm not yet sure if the second one is really needed

[untitaker]

We wouldn't have to create our own API for querying the backend anymore, and don't write any SQL.

Flexibility is the wrong word I suppose but I think we'd save a lot of code.

On Tue, Jul 21, 2015 at 06:57:12AM -0700, Christian Geier wrote:

What flexibility would you expect could be gained from switching to an ORM?

I do agree that the current way of querying the the database sucks and I intend to improve that. E.g. I want to remove the whole collection construct, which should already reduce the number of queries. While we won't get rid of separate queries for localized and floating events this shouldn't really be exposed to the higher levels.

Currently I'm thinking of something like this:

def get_events_at(self, at=datetime):
   """get all events at datetime"""
    returns list of Events

def get_events_onnself, on=date):
    "get all events that are on date"""

def get_events_from(self, start=datetime, end=None):
    return an iterator that lazily gets new events from the db

I'm not yet sure if the second one is really needed

---

Reply to this email directly or view it on GitHub: https://github.com/geier/khal/issues/93#issuecomment-123315289

[geier]

@untitaker what do expect to see when hitting G? (especially once lazily expansion of recurrence rules is implemented).

[untitaker]

Less scrolls to the bottom when hitting G. I don't think implementing our own pager is worth it.

On 21 July 2015 17:48:08 CEST, Christian Geier notifications@github.com wrote:

@untitaker what do expect to see when hitting G? (especially once lazily expansion of recurrence rules is implemented).

---

Reply to this email directly or view it on GitHub: https://github.com/geier/khal/issues/93#issuecomment-123380611

Sent from my phone. Please excuse my brevity.

[geier]

if there is no ORM that supports icalendar's RRULE and floating and localized events I'm against using one, because it will not make the insertion process any easier (which IMO is the hard part) but adds complexity to the technology stack (ok this might be me, because I don't use any ORM anywhere but do know some SQL).

[geier]

Less scrolls to the bottom when hitting G. I don't think implementing our own pager is worth it.

But what is the bottom of an infinite list? I think we should somehow limit how far agenda shows events into the future.

[untitaker]

I assumed that it should stop at the last even in the db but that's costly.

On 21 July 2015 17:52:10 CEST, Christian Geier notifications@github.com wrote:

Less scrolls to the bottom when hitting G. I don't think implementing our own pager is worth it.

But what is the bottom of an infinite list? I think we should somehow limit how far agenda shows events into the future.

---

Reply to this email directly or view it on GitHub: https://github.com/geier/khal/issues/93#issuecomment-123381998

Sent from my phone. Please excuse my brevity.

[geier]

closed, see #273