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
Our main methods to get members nowadays ensure that the member list is
synchronized with the server. This is nice and convenient but might not
be desirable for a couple of reasons.
Firstly it might be costly to fetch all members at once depending on
what the client is doing and the number of rooms and secondly some
clients might have a hybrid setup where not everything is running on a
tokio thread, sending out requests is only possible on a tokio thread.
Damir Jelić
timorl
Austin Ray
projectmoon
Jonas Platte
Johannes Becker
Devin Ragotzy
Devin Ragotzy
Kévin Commaille