Filtering entries

[pspeter]

There's a few requirements for the filter feature:

1. It must be defined and implemented as a plugin to be extendable or replaceable
2. The filters themselves must be extendable - it should always be possible to add new filter options
3. It should ideally work before parsing all the entries to drastically improve performance for large journals

At first, 1) and 2) seem fairly straightforward: provide a hookspec that takes an entry and the config with cli args and return a Boolean whether to keep this entry (return False) or drop it (return True). If any hookimpls return True, the entry will not be processed further (for editing or reading).
However, if you have multiple filters that are unaware of each other, then that might become a problem. If you have a filter that only allows entries from last year and a last_n filter of 2, then the last_n filter will have no effect as it will drop the entries from last night that are also dropped by the date filter.

Furthermore, 3) makes this issue even more complicated. The question is: at what point will the filter activate? After reading the journal file based on the raw text? After splitting the entries? Or only after parsing each entry (I want to avoid this)?

I might have to end up writing multiple hooks at each of these points in time so that different filters can implement one of the hooks -> the earlier the better. For example, the current last_n filter can be used after splitting the entries but before they are parsed, while a date-filter needs to know the dates of each entry and thus only works with parsed entries. But having multiple hooks makes 1) and 2) even more complicated.

I need to think about this some more before attempting an implementation. One complication are directory-based journals that contain entries in different places, as this might add another hook - before reading each file. Depending on what metadata is known about these files some filters could hook in there and prevent reading the file altogether.