1743211 - Searchfox does not find layout/tools/reftest/README.txt with query "readme" and path filter "layout/tools"

Status: NEW

(Webtools :: Searchfox, enhancement)

Description

[Botond Ballo [:botond]]

STR

1. Enter readme into the Searchfox search box
2. Enter layout/tools into the path filter box
3. Ensure the "Case-sensitive" checkbox is unchecked

Expected results

The file layout/tools/reftest/README.txt is one of the results.

Actual results

No results.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The searchfox UX is unintuitive here. Your search should be for layout/tools**readme to accomplish what you want (within the existing implementation).

If you specify a path filter only, we only do a path search and do simple globbing. If you put anything in the search field, we explicitly only do a fulltext search per this logic and won't do our default identifier_search. However, if you use a path filter and use symbol:FOO or id:FOO we will filter those results by path.

This arguably is not intuitive. (That said, once you know the right thing to do, the documentation at https://searchfox.org/ under "Query Language" will make sense, but not before, as when I look at it right now I feel like my instinct would be to put the examples in the "search" box instead of the "path filter" box.)

I think it makes sense for us to move to change searchfox's behavior so that when the "path filter" is used in conjunction with the "search" box that it behaves like it's filtering what you would have gotten from the "search" box. I think this means for the default case logic that we would:

• have our search_files invocation build the glob equivalent of ${parsed['pathre']}**${parsed['default']} to use the JS syntax and hand-wave about the points where the regexp transformation happens.
• Set the path_filter for identifier_search like in the id case (but using "default").

When fixing this we definitely need to add test coverage for this. I added query support to enable tests like this but some small enhancements will be necessary to make the searchfox-tool mechanism able to generate the proper query. This means touching:

• The actual query generated by the RemoteServer to be able to take a "pathre".
  • The parent signature for the method to match, plus the local no-op impl.
• The query command and its structopt inputs, which I guess would give us pathre: Option<String> with an annotation of #[structopt(long)].

Comment 3

[Dave Townsend [:mossop]]

This just tripped me up as well and I could have sworn I've done this before and it worked but I guess not.