Autocomplete does not show a class name when the class name is fully written

(I apologize: I attached the wrong screenshot.)

(Let's hide the wrong image.)

(Actually, the class for that block is in the src/Plugin/Block/SearchBlock.php file from the API project.)

The problem here is that "number" is a relatively generic word, and it appears in many objects (class names, functions, methods...), so the result gets truncated.

The results are sorted alphabetically, and then truncated to the first 10: https://git.drupalcode.org/project/api/-/blob/2.x/src/Controller/Autocom...

The only think that I can think of is to perform an (using "=") search first, and then do a fuzzy search after (using "LIKE"), but this will make the search slower (2 searches instead of 1) and the number of matches might still not be relevant, as it is a generic word, so I'm not in favor of this solution.

For example, I looked for the word number in PHPStorm, and we can see a lot of results, and "Number.php" is only the last one in the screenshot:

Also, note that the autocomplete is just suggestions, but you don't need to click on them, you can still click on the search, and you'll be taken to this page https://api.drupal.org/api/drupal/11.x/search/number, where we can see that "Number" classes are around position 30 to 40.

I think that this is a "work as designed", but I'll let you weigh in.

The issue is not the number of results shown, but the fact the perfect match is not shown as first result.

Furthermore, when searching for FormBase, I get the following results.

It shows all the properties/methods for ActionFormBase, which is not even the only class matching my search.

Yeah, it's the same as the above really. The only way to go about it is to do exact match first, and then fuzzy search after, and display the results in that order.

What I'm thinking is that if we have results in the exact search, we don't need to do a fuzzy one, so we'll only do the second one if the first search didn't return any results. I might as well raise the time to trigger the autocomplete to give users time to type what they want, as opposed to look for "FormB", "FormBa", "FormBas", "FormBase" (where the first tree will trigger two queries each).

I can work on that.

Yes, they are all "the entered value partially match the results" cases.ù
IMO, the FormBase case is worse because all the suggestions are for the ActionFormBase class: the class, the file containing the class, the class properties, and the class methods.

I know search for code is not easy to implement, but the search should return the more relevant results.

I don't know how much difficult is implementing this, but would not limiting a result for a single file (when the file contains a class) given more different results?

The issue is that people might be searching for a method name, or a constant, so it's not just files.

We have good control over the code that is being run:
- Controller: https://git.drupalcode.org/project/api/-/blob/2.x/src/Controller/Autocom...
- Entity search by title: https://git.drupalcode.org/project/api/-/blob/2.x/src/Entity/DocBlock.ph...

So we can tweak things a little bit.

The issue is that people might be searching for a method name, or a constant, so it's not just files.

I meant for the case the match is with a class name: If I enter FormBase, and I get a match for ActionFormBase, I should not get the name of the file containing the class, or any property/method that class has. Instead, I should get another class name, or a property/method name for a different class.

MR: https://git.drupalcode.org/project/api/-/merge_requests/34/diffs

See the different in behaviour in this screen recording → .

When an exact match is found, it only shows that one, otherwise it shows partial matches.

The last commits where just to make the search go directly to the object if there is only one result. The fixes can go together with this.

What shown in the screen recording is very good: A search for FormBase does not show anymore all entries for ActionFormBase.

This is now deployed to the production site.

Automatically closed - issue fixed for 2 weeks with no activity.