Sender headers may need updating after receiving new/old events

[Stebalien]

Sender headers aren't displayed when the previous event isn't a message (e.g., it's a membership change event).

---

At the beginning of the buffer:

(this one gets fixed by loading more messages)

---

After a timestamp header + some membership changes:

(the reply after the time change was sent by you but isn't attributed)

---

Another case. Everything after the timestamp isn't.

[alphapapa]

Yeah, I've made changes to that code to try to make it more robust many times, but I don't use that format myself, so it's not as well-tested. Part of the problem is that there are two functions, one for inserting sender headers and one for inserting timestamp headers. As well, the, shall we say, continuity of the buffer can change when retrieving older events: after they are inserted at various places, the headers that seemed correct before may now seem incorrect.

A possible solution would be to remove all headers in the range in which events were added, then reinsert headers as appropriate. IIRC something like that is already done for timestamp headers.

Anyway, I don't know how soon I'll have time to work on this, but I'll plan to improve it eventually. Or, patches welcome (with FSF copyright assignment).

Thanks for reporting and providing good screenshots of the cases.

[Stebalien]

I'm on vacation right now so I'll take a crack at it and see where I get.

[alphapapa]

Cool, thanks. Probably the way that non-event elements are inserted into room buffers could use a redesign/refactor. Feel free to talk about a design for that if you're interested in it. Otherwise, probably a few well-placed fixes would resolve this issue too.

[Stebalien]

The fix turned out to be pretty easy (#158).

[Stebalien]

Ok, I take that back. The correct fix turned out to be more complicated. But this function should be less error prone now.

[alphapapa]

@Stebalien Thanks for your work on this and your patience.