Currently, identifier search[1] performs an identifier lookup that internally retrieves one or more rows of [pretty id, raw symbol]. Given the symbols, the search performs a cross-ref lookup for each symbol and then merges all of those results into the same SearchResults object, discarding the association with the symbol. There are cases such as bug 1466692 where it would be useful for the UI to be able to separate the results for the individual symbols, but to do this we need to expose the symbol information in the returned search results. This would imply a new wire representation for the results. Currently results look like: - "normal"/"test"/"generated"/rust thing? - "Assignments (PRETTY)": List of PathLines objects - "Declarations (PRETTY)": same - "Definitions (PRETTY)": same - "Files": list of String paths - "IDL (PRETTY)": List of Pathlines objects - "Textual Occurrences": same - "Uses (PRETTY)": same An alternate representation somewhat inspired by my normalization for grokysis[3] would be: - "normal"/"test"/"generated"/rust thing? - "files": List of String paths. - "fulltext": List of PathLines objects - "semantic": A dictionary where the keys are pretty symbol names and values are lists of { symbol, pretty, ..., hits } where - "symbol" is the raw symbol name - "pretty" is the pretty version of the symbol which frequently will be the same as the parent key, but sometimes may be different when inheritance hierarchies are involved. This probably entails an additional column on each `identifiers` row to store this value since it may differ from the value in the first column. - It could also make sense to include other hierarchy-related metadata here when available, like "parentSymbols". - "hits" is a dictionary object with normalized non-presentational string keys like: - "defs"/"decls"/"uses"/"assignments"/"idl": List of PathLines objects Note that there is a structural change here. Currently, the SearchResults logic has hard-coded ordering precedences[4] and the UI depends on the resulting order of the object keys/values. My proposal would require the UI to do the ordering itself and moves the search endpoint to be more of an API and less of a pre-chewed structure to be fed to thin HTML formatting. Given that at least a few tools seem to be building on Searchfox, I think this is probably a good thing. (Although we probably would want to keep the existing search endpoint now to not break them!) I'm not sure how to best the additional information to the search UI. The simplest option is for "Definitions (nsDisplayItem::CreateWebRenderCommands)" to instead list the symbols with inline checkboxes like "Definitions ([x] nsDisplayOutline::CreateWebRenderCommands, [x] nsDisplayItem::CreateWebRenderCommands)" when multiple (pretty) symbols are retrieved. This may add a little visual noise and would want to change keyboard navigation. Currently the collapsible "Definitions (...)" headers are unable to receive keyboard focus to (un)collapse, but arguably should be along with the checkboxes. Checkboxes would be omitted when only a single symbol was present. (Disclaimer: I do have experimental not-for-landing UI stuff that looks like https://clicky.visophyte.org/files/screenshots/20181012-132831.png that would also love to have this additional detail...) 1: https://github.com/mozsearch/mozsearch/blob/89c1f849e18e91b72dad539576d73a8ac04bf5a4/router/router.py#L246 2: https://github.com/mozsearch/mozsearch/blob/89c1f849e18e91b72dad539576d73a8ac04bf5a4/router/router.py#L96 3: https://github.com/asutherland/grokysis/blob/master/src/server-hacks/normalize_search_results.js 4: https://github.com/mozsearch/mozsearch/blob/89c1f849e18e91b72dad539576d73a8ac04bf5a4/router/router.py#L124