When grepping (`search rg`), preview could highlight the first match

[mikavilpas]

Please describe the problem you're trying to solve

When I search using S (search rg), and preview a file that matched my search, the file preview could

• scroll the preview to a section that shows the location of the first match, so that I can see the context of the match
• highlight the first match, so that I can quickly see where it matched

Would you be willing to contribute this feature?

• [X] Yes, I'll give it a shot

Describe the solution you'd like

This is the neovim + telescope implementation

The matched files are displayed on the left, and the preview on the right.

Can it be done the same way? I think it's enough to just display each file once, even if it had multiple matches.

Additional context

Not sure what the performance implications might be.

[mikavilpas]

Btw, this is not urgent for me. I was able to add a feature to yazi.nvim where I can read the last cd DDS event and run telescope inside neovim, limiting the search to the directory. The experience is quite good.

https://github.com/sxyazi/yazi/assets/300791/b8a0123f-51ce-42a2-b381-a51a5cbc70bd

[sxyazi]

I'd like to know more about the implementation details:

• Currently, there's no saved information about the matching line numbers. Where do you plan to store them? Will it be in the file's own attributes or a separate variable?
• We need to consider the worst-case scenario: if the offset is large, for example, if the first match is the last line of a 10,000-line file, highlighting will take a long time. How will we handle this?
• Should we implement this as a unified feature, or distribute it among the Lua code for each previewer? If it's the latter, it will allow us to expand support for other file types in the future (e.g., PDF, where it would be page numbers instead of line numbers). This would make it easier to transition from rg to rga, which supports searching in file types other than just text files.

[mikavilpas]

Currently, there's no saved information about the matching line numbers. Where do you plan to store them? Will it be in the file's own attributes or a separate variable?

Here is a sample match from rg using the --json flag to get machine readable output (it seems to provide line numbers already):

// $ rg "window" --files-with-matches --json
{
  "type": "match",
  "data": {
    "path": { "text": "lua/yazi/utils.lua" },
    "lines": { "text": "---@param window YaziFloatingWindow\n" },
    "line_number": 195,
    "absolute_offset": 5224,
    "submatches": [{ "match": { "text": "window" }, "start": 10, "end": 16 }],
  },
}

One possibility would store it as a new struct, composing the existing File with additional information:

pub struct RgSearchMatch {
    pub file:        File,
    pub line_number: u32,
}

We need to consider the worst-case scenario: if the offset is large, for example, if the first match is the last line of a 10,000-line file, highlighting will take a long time. How will we handle this?

I don't know what would be the best way to handle this. I can think of a few approaches:

• If the file is too large, we could skip highlighting altogether. Maybe the user could configure this in some way, and yazi could provide a conservative default
• For large files, provide a faster but less accurate highlighting method. I'm not really sure about this approach since it increases the maintenance burden quite a lot.
• For all files, display the match without highlighting, but also start a background task to highlight the file. When the highlighting is done (for the area that is needed), we could update the previewer and kill the task.

Should we implement this as a unified feature, or distribute it among the Lua code for each previewer

To tell you the truth, I would personally be very happy with a super basic implementation in yazi that showed some context around the match. I would give previewer plugins the possibility of doing opt-in fancy things.

For example, a plugin could be written that applies a tree-sitter parser (I believe this is the implementation in https://github.com/nvim-telescope/telescope.nvim).

[mikavilpas]

Looks like rg also provides a rudimentary integration with delta: https://github.com/BurntSushi/ripgrep?tab=readme-ov-file#related-tools

I tried this out and it worked.. but some files were not highlighted correctly. Also, this requires a bit of tinkering to set up, so I don't really think it's that good.

[DreamMaoMao]

This task is want to make like fg.yazi to a built-in feature?

[mikavilpas]

Hmm, conceptually they are very similar, but here are some differences:

• fg.yazi seems to use external programs - I actually meant simple highlighting in yazi's current search
• fg.yazi seems capable of showing each match as a separate result - yazi shows each matched file only once