bug: label highlight group in char mode overrides match

[simonmandlik]

Did you check docs and existing issues?

• [X] I have read all the flash.nvim docs
• [X] I have searched the existing issues of flash.nvim
• [X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.1

Operating system/version

MacOS 13.4.1

Describe the bug

Even if labels are not used in char mode, to properly color matches, one has to use highlight group for label, which also takes precedence over the match one.

Steps To Reproduce

1. nvim -u repro.lua
2. Insert "test test"
3. "ft"

I see the following:

that is, highlight group is not used at all.

When I uncomment the label highlight group, both label and match are used, but the foreground is taken from the label hl

Expected Behavior

I would expect that defining match would be enough, and see the following:

Repro

local root = vim.fn.fnamemodify("./.repro", ":p")
for _, name in ipairs({ "config", "data", "state", "cache" }) do
    vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

local plugins = {
    {
        "folke/flash.nvim",
        opts = {
            modes = {
                char = {
                    jump_labels = false,
                    highlight = {
                        backdrop = false,
                        groups = {
                            match = "Blue",
                            label = "Red",
                        },
                    }
                }
            }
        }
    }
}

require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

vim.cmd[[set termguicolors]]
vim.cmd[[hi Blue guibg=blue guifg=blue]]
vim.cmd[[hi Red guifg=red]]

[simonmandlik]

I dug deeper and the difference can be seen better when running "tt"

Now, the label hlg highlights matched character, and the match hlg highlights next positions. I am confused and would expect it to be the other way around

[savchenko]

UPDATE: See the next comment.

---

The bug is non-obvious until one tries t instead of f.

Might be something to do with the priorities logic? E.g. here cursor is at the search, fe:

Looks like the label indeed overwrites both current and match.

:Inspect executed via @: with highlights visible reveals that it's there, under the FlashCursor:

te makes match highlight group clearly visible:

FlashCursor gets inverted when nVim is in focus. Hence it's possible to "fix" this for fF:

...but it will be reversed back when using tT:

Having separate highlight group for tT or (better!) keeping unified, non-inversed behaviour throughout would help.

[savchenko]

@simonmandlik, think I have solved it. Config below works perfectly as expected:

char = {
    enabled = true,
    keys = { 'f', 'F', 't', 'T' },
    search = { wrap = true },
    jump = { register = false },
    autohide = false,
    jump_labels = false,
    multi_line = true,

    label = {
        style = "overlay",
        current = false,
        after = false,
        before = false,
        distance = false,
    },

    highlight = {
        backdrop = true,
        matches = true,
        priority = 5000,
        groups = {
            label = 'GreenHighlight', -- :hi for f/F
            match = 'GreenHighlight', -- :hi for t/T
        },
    },

You can adjust label and match highlight groups to your own preference.

Screenshots

f/F

ff

t/T

t,

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[simonmandlik]

please keep

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[simonmandlik]

please keep

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[simonmandlik]

please keep

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[simonmandlik]

please keep