@mention full name autocomplete doesn't work with international characters

There is a severe issue with the implementation that must be resolved first if we were even to consider this.

IF you searched for “bob mar” and got zero results, we should not bother searching for “bob marl” cause it can not exist. As it stands our search logic is not smart enough to cover this.

A change in this department would heavily increase the search traffic as “@bob bob bob bob would trigger a search”

Also another terrible edge case would be when you already match @sam and then type @sam s it would show a search pop up, which is clearly not intended.

Its possible this could work, but full of complex dragons. So my vote for now is simple to cut off on space.

4 Likes

… or linebreak :end:

I tested on my local installation with the patch applied.

After the search list is closed, no further requests are being made. So after you search for “bob mar” and get zero results, “bob marl” isn’t searched.

@bob bob bob does trigger a repeated search. But this seems rather rare to me, and can be fixed by returning an empty result list if the query string contains multiple occurrences of the same word (only words followed by a space should be considered).

If you already match @sam (by pressing enter), the autocomplete list gets closed, and so doesn’t show up again if you continue to @sam s. If you type something like @sam how are you, the autocomplete list would be closed as soon as there isn’t a matching user, so it would be quite fast.

To summarize, the current logic is quite simple – close the list as soon as there are no matching users or if a user is selected, and then forget about the search. It solves all of your concerns except for bob bob bob, which seems like a pretty rare case for me and can be solved by adding a simple logic to the search function.

Basically, I don’t see dragons here because the chance of a string to match a user drop rapidly as its length increases, so the autocomplete list would be closed pretty quickly anyway.

1 Like

We will not be matching spaces, sorry. Matching Unicode is a different issue.

OK. That’s your call after all!

Sorry for reviving this, but having read the whole thread I fail to understand why it was abandoned - it seems to me like there is a consensus that matching on (at least) any non-space character is acceptable. So why is the regex still matching only ASCII alphanumerics and dots/underscores?

Perhaps you can submit a PR with test cases for a proposed change?

Sam, I’ve read the js file in question and it mentions that Site Settings isn’t avaliable at load time.

I really would like to customize this, because when I search for “Rafael” and there are 5.000 “Rafael*” on my instance it makes the search useless. :sadpanda:

Would we be able to overwrite the it when it gets moved to ES6?

1 Like

Fixed by https://github.com/discourse/discourse/commit/7c950321d1b6d0d83359d6ccc4560d3b41e53c45#diff-508d69f2260fdad85feebdd21da2cba7