Joypad Search, Function naming and possible Documentation errors

SUMMARY: Searching for Joypad Rumble was not straight forward, Search results not clear, dont have consistent priority.
REGARDING: https://docs.godotengine.org/en/stable/classes/class_input.html and Search results
My Whish: If a user searches for Joypad make Input page be the first search result that shows up, since its the most usefull one.

First of all entering joypad into search yields very interessting results, and they are not straight forward, which is concerning...


The priority is all boched which does not help newcomers at all, and got me confused! Input should show up first since all the method heads written out there are actually the ones you use to get input or activate rumble, which i did not expect to be in input, rather in InputEvent, but as I learned tonight, this is just a data type, but the usage in code seems like its an actuall object, but at the same time the code stays consistent with has a and is a Unified Modelling Language terminology, I am torn on this one. Or is the actuall Documentation wrong in saying InputEvent is a data type, and its actually an Object. This would make a lot more sense, since data types are self enclosed and there exist no derivatives of int, theres a difference in byte size, like long, but InputEvent has other derived "datatypes" like InputEventKey, as stated in the code example on the page for InputEvent. The naming convention, as well as the usage and perceived behavior of code hint at InputEvent being a parent of InputEventKey, which is hammered down by the naming convention here. I would love an explanation.

Why is a tutorial page showing up first in the documentation when entering common words into search like joypad.

Searching for Controller does offcourse lead to different search results, allthough Joypad is a common naming convention in a lot of engines and frameworks, so i dont mind that added level of complexity for beginners.

PS.: Also, something pertaining function naming conventions on the side, if you have a get, as in get_joy_vibration_duration, you expect there to be a set as well, but theres a start and stop function going along with rumble functionality... this shouldnt be a reason to consult the documentation and can be frustrating even if theres linting and code suggestion in the editor, the essential rumble function may not show up... and after glancing over the methods in the documentation page Input they were hard to spot. All in all those Input method names for the most part are pretty snuck, but there needs to be a little more uniformity in the naming, so it is clear at one glance and easier searchable. In short naming a function that should have been a setter method start creates more problems than solutions.