Better sorting in tab-complete popover
Detailed description of the issue. Provide as much information as you can, potentially with images or videos showing the issue.
Steps to reproduce
- Open Fractal
- Be in a room for a while and interact with the same set of ~10 people with a few hundred idlers.
- Enter
tma<tab>
to try to complete the nick of one of your colleagues. - Get the nick of an idler who happens to have the word
hostmaster
as part of their login name, who has never actually said anything on the channel, and who I've never attempted to speak to before. - Watch this happen again and again and again.
Information
I'm using a freshly-updated version of the "new" Flatpak, version 5~beta2-c50076b
installed from gnome-nightly
. I'm running Fedora Silverblue 38 with the fedoraproject home server. The beta version has improved substantially in the last months and I'm using it as my primary "work" chat since after summer vacation. The biggest usability problem for me at present is the tab completion issue described above.
Ideas
Here's a list of things that could be done to improve tab completion, in my self-assessed order of importance. Fortunately, the first things in the list (which I consider to be the most important) are also the easier ones to implement.
- First and foremost, only prefix matches should be considered.
tma<tab>
should only match on strings that actually start withtma
. This should be easy, and it's implemented in GLib asg_str_match_string()
which is how the search in GNOME shell also works. This is super easy to implement because it's very binary — either something is a prefix match or it's not. - Secondly, a strong preference should be given to the display name of the person, and attributes like their matrix ID or homeserver should match less strongly. This is a bit more complicated to implement because it requires some kind of a scoring system.
- Third, we could consider the nicks of the people we have tab-completed most recently and give priority to those, but probably not more than the priority given as part of part 2, above. This is getting a fair bit more complicated now, because now we have to build a list. I guess this would be pretty effective as a tiebreaker, though, because I imagine most people interact with the same set of 2-10 people 90% of the time[citation needed].
- Fourth, we could consider how long it's been in the room since the person in question last said anything. The idea here would be to de-prioritize idlers (but again, not more than part 2). That wouldn't involve maintaining a separate database, but depending on how the code is structured, it might be difficult to determine.