[Bug]: File preview highlight not work on multi word query

[thuan1412]

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

UI issue, no logs.

Description

The highlighing for multi word sections isn't working as expected. Please see the attached images.

Single word query

Multi word query -> it only highlights in the list item.

[gustav-fff]

[triage-bot] NEEDS INFO:

Cannot reproduce reliably without more context. Preview highlight path differs by mode:

• File picker (fuzzy file search): preview has no per-match highlighting at all by design (lua/fff/location_utils.lua:42 only highlights when a grep_query is set). If you are in file-picker mode, single-word highlight in preview would also not work — so likely not this.
• Grep mode + fuzzy grep submode: preview highlights come from precomputed fuzzy_match_ranges from Rust (lua/fff/picker_ui/preview_manager.lua:177), single line only.
• Grep mode + plain/regex submode: preview uses vim.pesc(grep_text) + literal string.find (lua/fff/location_utils.lua:207-224). For a multi-word query like foo bar, this scans the preview line for the literal substring foo bar — which won't match lines where the rust grep matched foo and bar separately.

@thuan1412 please share:

1. Which picker — file finder or grep (<C-g> or whichever toggles you use)?
2. The exact query string from the screenshots.
3. Current grep submode (status line shows plain/regex/fuzzy).
4. A 2-3 line snippet of a file where the bug is visible (so we can pin which highlight path is failing).

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff he means that when the matched bytes contains "." they highlight doesn't work - analyze why this is happening

[gustav-fff]

[triage-bot] DIRECTED:

Root cause: lua/fff/location_utils.lua:207 runs vim.pesc(search_text) then string.find(search_line, search_pat, start_pos, true) at lua/fff/location_utils.lua:224. The 4th arg true is plain=true, which makes string.find do a literal byte match, not pattern match. vim.pesc Lua-escapes specials, so a needle containing . becomes the literal needle foo%.bar, which never appears in file content foo.bar. Same for (, ), %, [, ], +, *, ?, ^, $, -.

This explains the screenshots: the list-item highlight uses Rust-computed match_ranges (crates/fff-core/src/grep.rs:1894-1909 -> lua/fff/picker_ui/grep_renderer.lua:220) so it works regardless of the query content. The preview path is a separate Lua re-scan with vim.pesc + plain=true, which silently misses any line where the needle has a Lua-pattern special — common in multi-word queries because they often contain . (dots in identifiers, filenames, version numbers).

Note this only affects the plain/regex grep submodes. Fuzzy submode is fine — it short-circuits via fuzzy_match_ranges at lua/fff/location_utils.lua:177-191 using the Rust byte offsets.

Fix: drop the vim.pesc call. With plain=true the needle should be the raw search_text (or its lowercase form for smart-case):

local search_pat = has_upper and search_text or search_text:lower()

Trivial change. Want me to open a PR?

Honk-Honk 🪿

[thuan1412]

Thanks @gustav-fff for the analysis, i've implemented and confirmed it fix the issue. Created a PR #637

[dmtrKovalenko]

I don't really remember why did we have vim.pesc there at a first place hope this wouldn't result in some crashes