When grepping (`search rg`), preview could highlight the first match about yazi HOT 6 OPEN

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.

from yazi.

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.

from yazi.

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).

from yazi.

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.

from yazi.

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

from yazi.

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

from yazi.