Loading the users into the autocomplete provider is quite a large
chunk of work for a large room. Try lazy loading it the first time
a completion is done rather than up front when the room is loaded,
given that a lot of the time you switch to a room you won't say
anything.
Because we need to support tab completing `"@some_user"` if `@some_user` has a display name that is totally different and will therefore not match what the user typed in.
This does have the disadvantage of a display name appearing (the pill) that isn't at all what the user typed in, but the autocomplete box and the tooltip should give enough information to let the user know what's going on. (e.g. typing `@kyr*tab*` and getting `Remmy`).
This _does_ run contrary to vector-im/riot-web#4495
related to vector-im/riot-web#4794
cc @lampholder
to make sure that the length of text in the decoration (See <Pill>) is equal to the length of text in the completion (underlying text range that the Entity covers).
These will appear decorated because they are inserted as entities. It was necessary to modify pills to have an explicit linkText that is derived from the `href` being pillified (and is thus no longer the inserted completion but rather the display name (or user ID) or room alias.
This modifies the composer completion such that completing a room or user will insert an IMMUTABLE matrix.to LINK Entity for the range that was replaced. Display names will not have a colon after their name anymore as it seemed strange that we would insert one after a pill.
`Array.prototype.splice` will return the array of removed items, not a new array. The array operated on is actually modified in-place.
This was causing a few weird things to happen: https://github.com/vector-im/riot-web/issues/4511 and https://github.com/vector-im/riot-web/issues/4533. This should fix both of them but it is concerning that doing the tab completion is required to reproduce. Let's just see how this goes before closing the issues.
Thanks @turt2live for reproducing both bugs, giving enough information for a fix :)
Accepting an invite would cause a room to arrive via /sync only for it to throw an error in the auto complete code and cause the client to go wibbly (infinite spinner or preview bar).
The logs that lead to the debugging of this are https://github.com/matrix-org/riot-web-rageshakes/issues/239
Hopefully the error being throw isn't totally unrelated but looking at the sync handling for inviteRooms in sync.js, new rooms are stored and _then_ the Room event is emitted. The Room event could trigger setUserListFromRoom, which is where the bug was. So the room should have been stored regardless of this bug and the client should have been recoverable by swapping away and viewing the room again.
QueryMatcher: sort results based on the position of the query within the matching value. The closer to the beginning of the word, the higher the result apears.
UserProvider: perf improvement (slice early) and refactor onUserSpoke
