sort output by file last modified time

[wavexx]

I'm throwing this here for consideration. When I'm searching through my source files, I often not only want to find all occurrences, but when multiple hits are involved, I also want to find the most recent modification (by mtime). It would be nice to be able to sort output files (with context), sorted by time and reverse time.

Afaik, none of the various searching tools allow to do this. Not easily at least.

To do it currently, I actually do two passes:

• find file candidates fist
• sort files by mtime
• search within files

This is necessary as I obviously like to see the match context as well (otherwise I could stop at step 2). But having to find candidates first introduces extra overhead that cannot be avoided.

This requires buffering matches before showing the output, of course, but the search can be ran in parallel still.

[BurntSushi]

@wavexx This does seem mildly useful, but I don't know when I'll have the time to work on it.

This requires buffering matches before showing the output, of course, but the search can be ran in parallel still.

While strictly true, this is an oversimplification. Namely, running a search in parallel requires buffering to avoid interleaving results. Sorting with parallelism requires something more than just a simple buffering scheme however, and it is rather difficult to do in the current setup (which parallelizes things at level of directory traversal). This is why the --sort-files flag forces ripgrep to operate in single threaded mode.

[BurntSushi]

It should be possible to implement this in the ignore crate without too much trouble now that walkdir's sort_by method exposes the necessary information. Namely, you can get the Path from the DirEntry and stat it to determine various attributes. This will have performance implications and should force single threaded mode. We'll also need to think carefully about flags.

[BurntSushi]

Here is what I propose:

• Add new --sort and --sortr flags to ripgrep. Both accept the same set of pre-determined choices. The former sorts in ascending order where as the latter sorts in descending order (or "reverse" order).
• Implementation detail: Whenever --sort or --sortr are given, ripgrep enters single threaded mode.
• Initially, the set of available parameters to the flag will be path, modified, accessed, created. path will sort by the file path (and therefore, --sort path will behave exactly the same as --sort-files does today). modified/accessed/created will sort by a file's last-modified/last-accessed/created timestamps, when available. When not available, ripgrep will stop execution before searching and print an error if possible. Otherwise, sort order will be unspecified.

We'll likely therefore deprecate --sort-files, but leave it as a hidden alias for --sort path.

Thoughts?

[wavexx]

I like it.