Add inheriting classes to DocTools

[AThousandShips]

Integrating a documentation hierarchy into DocTools

Part of the work for #77471 and #62524, see there for the discussions and background

Edit: I believe this is ready

• Fixes: Documentation: @GDScript and @GlobalScope are at the bottom of the list #63799

[YuriSizov]

Still working on deciding how to deal with the ordering searches, as this changes the previous order which put Object at the top, if maintaining that order is important I can rework it

Order should be alphabetical, so global scopes go at the top and then everything else is in their case-independent alphanumerical order (natural, perhaps?). This is something that I've been working on, actually, when I stumbled upon your work :) So if you actually manage to address this issue here, that's an amazing improvement!

[AThousandShips]

Will change the ordering to natural, I think there's a helper already for it! Sounds great

Bonus: unlike before new classes will end up in the right place in both search and the header of the help page, where before they were at the end

Note that at least currently this is not true for searching without hierarchy, as it uses the order in class_list, and can't easily resolve that here, #77213 would help with this

[AThousandShips]

We could use case sensitive natural sorting, but I think in this case this is sufficient, I'm not sure which order is preferred:

• Light3D
• LightmapProbe
• LightOccluder3D

or:

• Light3D
• LightOccluder3D
• LightmapProbe

[YuriSizov]

I'd say the first one makes more sense when you search for something by the name. Either way, we can try and see if there are complaints.

[AThousandShips]

I think this stage is ready for review properly now, and will continue to investigate the wider help indexing system as I am able

[AThousandShips]

Might solve #66407, will test

Seems to still be an intermittent problem, will try investigate

Edit: Does not solve it, seems to be caused by issues with the parser and circular references and don't think any implementation here can solve it, it appears to be that the inheriting data in the documentation is not correctly assigned if the parent class has cyclic errors like this, would require some more complicated updates to the data in the docgen for GDScript, so out of scope for this

[akien-mga]

Would you have a screenshot of the result?

[AThousandShips]

Will provide, for the correct order of sorted inherited classes?

[akien-mga]

Well I'm not 100% sure what this PR changes but I'm assuming there's a before/after for the EditorHelp changes?

[AThousandShips]

This makes the hierarchy of inherited classes explicitly available in DocTools, which improves the sorting, and makes the accessing of the inheriting classes easier to access, for example when generating the doc view, it is also part of a larger documentation enhancement where the access to that is convenient

The direct benefit is avoiding scanning the entire class list in order to figure out inherited classes, and also a building block for handling the same

Will provide screenshot for the sorting

Edit: Forgot it also makes help search sorted alphabetically

Before:

After:

[AThousandShips]

This is the relevant change for that, which also avoids scanning the entire class list for all classes just to find inheriting ones

[YuriSizov]

This looks great to me, love the new ordered list very much!

Some minor notes remain, and I'm also not great with data structures, so maybe @KoBeWi could take a quick look. But overall it all seems sensible.

---

PS. We should improve at some point the relevance of what is selected as the closest match, I think. Typing "path" with "Display All", for example, selects the first complete match which is a property of a navigation server struct. Very unlikely to be relevant.

[AThousandShips]

Will see about the relevance part in the final part, unsure how to improve it but good point!

[akien-mga]

Thanks!

[AThousandShips]

Thank you! Great to have this one done with