For all objects that have a "related objects" field in its meta data, the list of related objects will be added to the help index and will be displayed along with its description in the help browser. For related objects which can be located on the help path (given the help browser's search scope set in the gui preferences), the object will also be clickable, and open the corresponding help patch when clicked.
Moreover, objects will be listed in the search results if they have the search term as a related object. For instance, a search for 'pulse' will also list 'metro' because 'metro' has 'pulse' as a related object. Note that depending on the actual meta data, relatedness isn't necessarily symmetric. E.g., 'pulse' doesn't list 'metro' as a related object in turn and thus a search for 'metro' will not show 'pulse' in the search results, even though 'pulse' is related to 'metro'.
This feature makes it necessary to rework on the index creation process:
First, we'll iterate over the default hierarchy and the help path (if enabled) determining names and locations for each patch - this is important to resolve related object references meta data.
Secondly, we'll iterate over all index entries constructed in the previous step, adding all the available meta data, including cross references to related objects. When this step finishes, index construction is completed and the index cache is written to disk.
Note: The help browser now narrows indexing to just the -help.pd patches, while previous versions would index all .pd files. This may be subject to review (and is easy to change back if needed), but the new indexing scheme is faster and produces less noise in the search results (i.e., you won't see any helper abstractions or other patches which just happen to be bundled with the help patches), which actually seems preferable.