Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Handling of messages requires more thought. #3
I've backed myself into a corner by having
If I allow the current message to be marked as read it will immediately disappear from the display post-read.
The alternative is to have get_message retrieve all messages from the selected folders, then have the display function iterate and decide which ones should be displayed.
The problem with that approach is that the same logic must be applied in all cases where the current message is required. For example I expect we'll expose the "
That means duplicating that "Convert all messages to current subset" logic in multiple places.
Also although we can have the union of all message stored in:
This could be updated when a selected folder is added/removed/cleared, but that won't
function. Which I thought we didn't need to do when teh display updated "magically".
I expect this means I need to pause and rethink things.
Having spent most of the day thinking about this I'm choosing to break down the handling of messages in folder(s) into two parts:
The first part is obviously to fetch all possible messages from the selected folders. The second part is to limit the messages such that the appropriate subset may be displayed.
The difference between the current behaviour is that the display code will display both "the messages that match" and "the current message". The notion of a current message will be changed from an integer offset against the list of all messages into a CMessage object - or more likely the path the message contains.
This handles the fetch vs. display case of:
The secondary concern of updating in real-time such that new (incoming) mail is displayed "instantly" is a minor complication, but we can cache based on the mtime of the parent folders, or even fetch each on demand...
added a commit
May 13, 2013
added a commit
May 13, 2013
As per the last comment showing both things will work:
The downside here is that we currently handle navigation by merely incrementing/decrementing the global "offset form start of messages". If we show only new messages then this won't work. Consider the case when there are several messages:
If you're showing only "new" messages, and the current message is the first then incrementing the offset by one will jump the the second message, which will suddenly be displayed because it matches the "current message".
Instead we need to rework the next/prev message navigation to instead be "next/prev matching the limit in place". This is doable, but it starts to feel like a mess.
I think this is probably what I'll go for, but I'm not committing anything until I've mulled it over some more.