Keep autocompletion sort whenever user list updates

[xPaw]

~~This solution is not ideal for two reasons:

1. Users that leave (or change name) are left in auto completion
2. Users that change name in case sensitive manner are not updated~~

I didn't fix these two because it would get rather expensive to do a lot of manipulation on the arrays. Perhaps we should take names list from the server and merely sort it based on the old users array client has, probably would need to invert the users array so that nicks become order.

Fixes #92

This PR keeps previous order whenever user list is updated, newly joined users are pushed to the bottom, quit users are removed from the list.

[maxpoulin64]

Looks good to me, pretty clever solution the sort trick here! 👍

[AlMcKinlay]

newly joined users are pushed to the top

Hmmm, not sure I like that. This could cause problems, I feel, if I'm talking to someone and then someone else joins with a similar name and suddenly I'm auto-completing their name.

[xPaw]

It's not explicitly put at the top, but that appears to be how it works, might need more testing in that regard.

[astorije]

So if I understand correctly, whenever a user joins, it gets added to the bottom of the completion list. So if we have users ['aa', 'aj', 'ax'] on the channel and ab joins, if I start typing a in the message input then hit Tab repeatedly, the following cycle will take place: aa -> aj -> ax -> ab -> aa -> ....
Am I correct?
If so, why not just alphabetically, as this is what is expected (and also what happens when you refresh): aa -> ab -> aj -> ax -> aa -> ...?

[xPaw]

Behaviour in master is to push talking people to the top, but the bug is that whenever the user list is refreshed, that order is destroyed (thus becomes alphabetical), this PR fixes it by keeping the order, and pushing new users to the bottom. And yes it gets reset on page refresh as there is no server tracking for this.

[AlMcKinlay]

Yeah, I think it's much better to either do what this PR does, or to always do alphabetical entirely. If you do a kinda inbetween, you end up with confusion. I'm happy with this PR, and give me 👍, but won't merge because it has changed since @maxpoulin64 gave it 👍

And yes it gets reset on page refresh as there is no server tracking for this.

FWIW, we don't need server tracking for it. We just need to keep it in local storage. That might be a good thing to do in general.

[maxpoulin64]

Shouldn't we keep this as-is, for consistency with the remaining of the code? While I admit id makes a lot more sense, everywhere else sends chan: chan.id:

➜ lounge git:(PR-217) grep -F 'chan.id' -B1 -R src/
src/plugins/irc-events/quit.js-         client.emit("users", {
src/plugins/irc-events/quit.js:             chan: chan.id
--
src/plugins/irc-events/join.js-     client.emit("users", {
src/plugins/irc-events/join.js:         chan: chan.id
--
src/plugins/irc-events/topic.js-        client.emit("topic", {
src/plugins/irc-events/topic.js:            chan: chan.id,
--
src/plugins/irc-events/message.js-
src/plugins/irc-events/message.js:      if (!self && chan.id !== client.activeChannel) {
--
src/plugins/irc-events/nick.js-         client.emit("users", {
src/plugins/irc-events/nick.js:             chan: chan.id
--
src/plugins/irc-events/kick.js-     client.emit("users", {
src/plugins/irc-events/kick.js:         chan: chan.id
--
src/plugins/irc-events/names.js-        client.emit("users", {
src/plugins/irc-events/names.js:            chan: chan.id
--
src/plugins/irc-events/part.js-         client.emit("part", {
src/plugins/irc-events/part.js:             chan: chan.id
--
src/plugins/irc-events/part.js-         client.emit("users", {
src/plugins/irc-events/part.js:             chan: chan.id
--
src/plugins/inputs/part.js- this.emit("part", {
src/plugins/inputs/part.js:     chan: chan.id
--
src/client.js-  client.emit("more", {
src/client.js:      chan: chan.id,
--
src/client.js-      target.chan.highlight = false;
src/client.js:      this.activeChannel = target.chan.id;
--
src/client.js-  client.emit("names", {
src/client.js:      id: target.chan.id,

[xPaw]

What do you mean by consistency with the remaining of the code? Changing chan to id allows the client side to use the same function to render user list without thinking about which variable to use.

[xPaw]

Oops, I see what you mean now. Yeah we should just fix it in a separate PR to use chan everywhere then.

[astorije]

Alright, the more I think about this, the less it makes sense to me, but here is a shift: why not just do like the entire world is doing and sort completion alphabetically?

Think about it, from a user standpoint, keeping a list of users based on how recently they joined is not intuitive at all, especially on a tool that helps users stay always connected!
From our standpoint, it's also much easier to handle: no custom sorting, no server tracking or localStorage or whatever needed.
In terms of usability, I actually can't think of a decent use case for not going alphabetical.

In the end, I'm glad the autocomplete has been "broken" for longer than I can remember: it's been alphabetical ever since.

Am I out of line here? If I'm missing an obvious usability concern / use case for least recently joined vs. alphabetical autocomplete, I'd be happy to hear it. Removing the "second review needed" badge until then, to make sure that either we're all on the same page or I am dumb and missed something obvious :-)

[xPaw]

@astorije Auto completion becomes infinitely more useful when it's context aware. Having to deal with alphabetical auto completion in big channels is complete pain in the ass.

Recently joined users are kept at the bottom of the sort list. People that talk are pushed all the way up, so they are guaranteed to be completed first.

[astorije]

As discussed on the IRC channel, I understand the use case of keeping the 3-5 most recent people who talked at the top, and in case I wasn't clear, I like the idea. However, in all other use cases, it ends up building a list of nicks in a complete random order.
This will become even worse if we ever store things on server or local storage or whatever.

So I'm overall not OK with the feature, but as @xPaw said, let's fix this and build upon it. 👍 for the PR.

---

For archive purpose, here is what @xPaw and I said on the topic today:

<astorije> I get the use case when user is trying to mention the last 5 users who chatted, but past that it becomes unusable
<astorije> Correct
<astorije> For example, if you are trying to mention someone who hasn't chatted in a while (and a while could simply mean in messages that appear behind the "Show more" button, so on a crowded channel, it's not that long ago), then the order becomes completely random
<xPaw> I don't see how it's easier. You'd have to be looking at the user list to know which next match you'll get, or have to carefully hit tab and see if thats the name you want
<astorije> You would have to carefully hit tab anyway unless the mention is to someone you see on the screen
<astorije> YaManicKill, we do not have that currently: because it's broken, it's been sort-of-alphabetical since forever.
<xPaw> not true
<xPaw> complete on 'x', youll hit me first
<xPaw> if someone joins, the first match wont be me
<xPaw> that's where the bug lies
<astorije> Sure, but past you everything else is alphabetical, because I opened my browser 10 minutes ago
<xPaw> basically sorting the list in real time is infinitely more useful
<xPaw> keeping it strictly alphabetical is almost entire useless
<astorije> And that's my point actually: everyone who has spoken before you about 10 minutes ago, since I was not looking the channel, is in random order for me
<astorije> Infinitely more useful in the only use case where you are trying to mention someone who just spoke
<astorije> Everything other use case = random
<astorije> I definitely get your use case though
<astorije> I just think that making this use case easier entirely kills all others
<astorije> I think this would make more sense when using it if we have a list opening up when hitting Tab, showing users matching that tab cycle (a bit like FB, Telegram or Slack is doing, to put it in picture)
<astorije> And the top of the list could be the users who most recently discussed (like, the 5 ones) followed by all others in alphabetical
<astorije> My point is that, when hitting a letter then Tab, if 20 users match, once you have cycled through the first 3 ones, the remaining are probably completely random if they haven't talked within the last hour
<astorije> Does that make sense?
<xPaw> kinda, however I think this order overweights usefulness. you're most likely spending more time completing names that recently talked, rather than the non talkative ones

[xPaw]

I will merge as @maxpoulin64 and @YaManicKill agreed on it, and @maxpoulin64 had a previous 👍.