Skip to content

search: highlight file path matches

Administrator requested to merge tl/implement-path-match-ranges into main

Created by: tbliu98

Part of #18374

This PR adds highlighting for path matches in the search UI.

Right now, paths will only be highlighted if the search result is explicitly a PathMatch. In other words, if content and/or symbol matches are available to be rendered, then the rendering and highlighting of those match types takes precedent over path matches.

For example, if a file contains both a content and a path match on the string foo, and the query does not contain select:file or type:path, then the rendered result will show the content match highlighted and the path will not be highlighted. The reason for this decision is mainly to minimize added visual noise, as certain queries could potentially produce a huge amount of highlighting on the results page if we always highlighted path matches for every result type. Note that for the content match in the screenshot below, the path is not highlighted despite containing a match:

Screen Shot 2022-09-04 at 6 00 54 PM

Looking for feedback and thoughts on what I just outlined above.

Implementation details:

  • At job creation, the search patterns are compiled into a regex or a list of regexes that is populated as a field on the corresponding job. These regexes respect the case sensitivity setting that is set in the search bar.
  • During conversion of a searcher FileMatch or a Zoekt FileMatch to a result.FileMatch, match the file name against the regex and append the submatches as result.Ranges to the resulting result.FileMatch.
  • If the result.FileMatch does not have content or symbol matches, then frontend will send an EventPathMatch to the client, which then highlights the matched ranges in the file path using the highlightNode() function.

Test plan

Added unit tests Manual testing to feel good about the additions

Merge request reports

Loading