Step 3.iii of the naming algorithm[0] covers name calculation for empty
rooms; however, it isn't an else condition for steps 3.i and 3.ii. It's a
final conditional in the algorithm before returning the name. The
current implementation treats it as an else condition.
To fix this, use step 3.i and 3.ii to calculate a room name then check
if the user is alone. If alone, return "Empty room (was...)" containing
any former member names. If alone and there aren't any former members,
return "Empty room"
Fixes#133
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
The current implementation uses number of invited and joined members for
"and {} others" message. This assigns rooms with 5 members the name "a,
b, c, and 5 others" suggesting 8 room members. The correct message is
"a, b, c, and 2 others". To get this, subtract number of heroes from
invited and joined member count.
Step 3.ii of the naming algorithm[0] confirms using a remaining users
count in the name.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
Split `calculate_room_name()` into a high-level function using Matrix
data types and low-level function containing the core logic using plain
Rust data types. Since the low-level function uses simple data types,
unit testing becomes easier.
Step 3.ii of the name calculation algorithm[0] specifies the conditional
as `heroes < invited + joined - 1 AND invited + joined > 1`. However,
current implementation uses `invited + joined - 1 > 1` in the
conditional, which can trigger the conditional if the user is alone.
Correct this by using two variables representing `invited + joined` and
`invited_joined - 1` and updating the conditional. `invited + joined` is
kept as a variable since step 3.iii uses it for its conditional.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
This patch changes the way we store and load the majority of events that
are in the state store. This is done so custom fields in the event
aren't lost since a deserialize/serialize cycle removes all the unknown
fields from the event.
