This also lays some foundation for coalescing other event types in the
future (maybe even grouping by sender, which might replace the awkward
code for inserting sender headers for the "Elemental" message format;
but that would need to be done very carefully, because events can
arrive out of order, which might require splitting coalesced events at
times).
The last event in a room's timeline may not always be the last event
displayed in the room's buffer (e.g. a reaction to an earlier event).
So when intending to mark all events in the room as read (when point
is after the last displayed event), mark the latest event as read
rather than the last displayed event. (Otherwise, the room would not
get fully marked as read, and could display as an unread room.)
When reopening closed room buffers that contain retro-loaded messages
that include events that have been replaced by later edits, the
original messages were inserted alongside the edits, because the edit
events were inserted before the original events, so the original
events were not replaced by the edits.
This happened because the edits were processed before the originals,
because the events were stored out-of-order in the timeline. Now,
this shouldn't have been the case, because when retro-loading
messages, we store them at the beginning of the timeline, before the
newer events. But, for some reason, this isn't always working. The
Matrix spec says that the definition of "chronological order" is
up to the server, so maybe it's not always returning them in the order
we would expect.
So this is a mildly hacky workaround: if the event's unsigned data
indicates it's been replaced, we just don't insert it. Theoretically,
we should already have any such replacing event.
If we wanted to be extra careful, we could look up the replacing event
in the hash table to ensure we've got it, but we can add that later if
necessary; for now, let's not.
Ideally we would just call ement-room--insert-sender-headers for the
proper nodes, but at the moment this seems to work properly, so let's
just use this. We can refactor this into that again later.
It seems that `mwheel-scroll' no longer signals an error at
beginning-of-buffer, so to detect whether that is the case, we'll have
to compare window-start.
It seems that various types of events may be accepted and forwarded by
servers despite being malformed. We don't want any malformed event to
prevent other events from being processed, or to prevent further
syncing. So we demote all errors encountered while running event
handlers. Ement's users seem attentive, so it's likely that they will
still report any that they encounter regularly, even though they'll
only be reported as messages.
Closes#61. Thanks to @jfmcbrayer for reporting.
