I think this may be a better default, because it allows more of
Emacs's power to be used, e.g. Occur buffers to show all messages from
a user (which needs the username displayed with each message rather
than as a header above a group of messages).
The ultimate fix for this was to send /messages the proper kind of
filter, a RoomEventFilter, rather than sending it the kind of filter
that /sync expects. This is legitimately confusing, and there's even
an issue about it:
<https://github.com/matrix-org/matrix-doc/issues/706>.
This commit fixes the problem by using the right kind of filter for
/messages.
Thanks to Michael (@t3chguy) in #matrix-dev:matrix.org, who helped me
identify the problem.
Also thanks to him for clarifying that membership events may be in
both state and timeline events in a room, so calculating a displayname
requires searching both. This commit tries to be more...comprehensive
in doing this (perhaps more than necessary, but tidying that up can be
done later if optimization is needed).
Squashed commit of the following:
commit 1f393d7dde
Author: Adam Porter <adam@alphapapa.net>
Date: Thu Jul 22 10:48:19 2021 -0500
Comment: TODOs
commit 7e039a7b4f
Author: Adam Porter <adam@alphapapa.net>
Date: Thu Jul 22 10:48:08 2021 -0500
WIP: Docstring for handler lambdas
commit 441c23113c
Author: Adam Porter <adam@alphapapa.net>
Date: Thu Jul 22 10:40:58 2021 -0500
WIP: Don't insert reaction events as nodes
This seems to work well. However, the event-processing needs some
refactoring, because the logic is now spread across a few places.
commit 4fdf0ddf37
Author: Adam Porter <adam@alphapapa.net>
Date: Thu Jul 22 10:30:28 2021 -0500
WIP: Key face, and fix help-echo
Remaining issue is that reactions still insert empty events in the
buffer.
commit 5f700ccc16
Author: Adam Porter <adam@alphapapa.net>
Date: Thu Jul 22 09:30:18 2021 -0500
WIP: Fix: Use pushnew to avoid duplicating reactions
commit a40a6e6bc1
Author: Adam Porter <adam@alphapapa.net>
Date: Wed Jul 21 20:17:32 2021 -0500
WIP: And in -retro-callback
A bug now is that, every time a room's buffer is created anew, the
reactions are duplicated.
commit dbfec18e45
Author: Adam Porter <adam@alphapapa.net>
Date: Wed Jul 21 19:49:47 2021 -0500
WIP: Call -room---process-events in -room--buffer
This almost seems to work, in that reactions from old timeline
events are displayed when the buffer is made...or not? It seems to
work in some cases, but not in others, like when retro-loading...
The big issue now is that the reaction events cause blank events to be
inserted into the buffer. Fixing that will require conditionally
inserting events, which probably means moving message event handling
into the defevent macro, which will require some more refactoring...
commit 81757536f2
Author: Adam Porter <adam@alphapapa.net>
Date: Wed Jul 21 17:02:29 2021 -0500
WIP: Add: Reactions
It works for newly received reactions, but after initial sync,
reactions that happened in the past are not displayed. I think it's
because the related events aren't found in the room's timeline, but I
tried to fix that, and it still doesn't work.
I'm guessing there are some assumptions that I'm making wrongly, or
something that I don't understand about how the server sends events.
We may have to save a list of certain types of events and process them
after all other events have been processed. Ugh.
The good news is that EWOC makes it pretty easy and reliable to update
messages in the buffer.
I found that some ement-user structs were not being read properly (and
who knows why--tracing that down may be tedious), which caused errors
when rooms were displayed after loading the session, so for now we'll
just clear these slots. This means that the first sync will be an
initial sync, so we aren't persisting the whole session. That may not
be ideal, but it's much simpler and avoids a whole lot of potential
bugs, too.
This seems to work correctly, but it wouldn't surprise me if some
unreadable types accidentally end up in the data and cause a read
error at some point (which this tries to account for). If so, those
types should be omitted from the saved session struct.
Also, this effectively saves all room events locally, which means they
will accumulate over time. This is probably undesirable, and some
kind of limiting or filtering should be implemented.
