bug: in search input, when text is deleted, it is still visible

[Galicarnax]

Did you check docs and existing issues?

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

Neovim version (nvim -v)

0.10.0

Operating system/version

Arch Linux

Describe the bug

While searching, press <backspace> until cursor gets to the beginning of the line. The first character stays visible. Type new symbols, that character is gone. Or press <c-w> to delete preceding words, until cursor is at the beginning of the line. The entire first word stays visible. Type something new, that word is gone. This behavior is not observed in command mode (:), only in search mode (/ or ?). It happens both with view = "cmdline" and view = "cmdline_popup". This behavior emerged recently (1-2 weeks perhaps) after one of the updates. Could reproduce with minimal repro.lua.

Steps To Reproduce

1. Do search: /some text.
2. Press <c-w> twice to delete both words.
3. The word some is still there (but is gone when you type something new)

Expected Behavior

Input should be completely cleared when text is deleted.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
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)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "folke/noice.nvim", opts = {} },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[Kaiser-Yang]

I meet the same issue.

[SuXYIO]

Same issue.

[dpetka2001]

To add to this, I also noticed that when you have mini.pairs enabled with option modes = { command = true } it also doesn't show the pair of parenthesis in search mode for example (most of the times, because a few times it does show it).

I tried different commits to see where this behavior started happening and found out that the last working commit is b3f08e6. After that commit it stopped working. The culprit seems to be something in real cursors commit.

[dpetka2001]

So, I tried testing something. I created an autocmd

vim.api.nvim_create_autocmd("CmdlineChanged", {
  group = vim.api.nvim_create_augroup("update_search_redraw", {}),
  desc = "Update search redraw",
  callback = function()
    vim.schedule(function()
      vim.cmd("redraw")
    end)
  end,
})

Not sure how safe this is, since it mentions

Be careful not to mess up the command line, it may cause Vim to lock up.

Still in testing phase, I haven't observed any lock ups. But if you encounter any problems, it might be because of this autocmd, so use it at your own risk. This is not a suggestion to solve the problem at hand, it's just something I'm experimenting with.

Hopefully Folke will have some more insight after he comes back.

[hb0nes]

So, I tried testing something. I created an autocmd

vim.api.nvim_create_autocmd("CmdlineChanged", {
  group = vim.api.nvim_create_augroup("update_search_redraw", {}),
  desc = "Update search redraw",
  callback = function()
    vim.schedule(function()
      vim.cmd("redraw")
    end)
  end,
})

Not sure how safe this is, since it mentions

Be careful not to mess up the command line, it may cause Vim to lock up.

Still in testing phase, I haven't observed any lock ups. But if you encounter any problems, it might be because of this autocmd, so use it at your own risk. This is not a suggestion to solve the problem at hand, it's just something I'm experimenting with.

Hopefully Folke will have some more insight after he comes back.

Wow how did you find this out? I was having a completely different issue, where text wasn't showing up for me AT ALL while searching with noice, unless cmp was showing me completions.

The only conclusion I can draw with my limited knowledge is that noice is not redrawing properly.

With your change (snappy/fast):

Without:

[dpetka2001]

noice does not seem to be redrawing while in search mode (or at least not redrawing properly). It was just a lucky guess while searching through the commits and found this one. Of course the code has changed since then and now the relevant code is here and here, but still I'm not familiar with noice's codebase, so this is all just a deduction from my part (which might be entirely wrong, since I don't understand that much to be honest).

Then I just tried to experiment with triggering a redraw in cmdline mode and was going through the events in Neovim autocmds to see what I could use. I also tried to add flush = true in this line, but there was a visual flickering effect and did not like it.

I'm sure Folke is much more knowledgeable and will have a better response than mine. This is just something I'm experimenting with after all just based on pure hunch. It doesn't seem to cause any problems for the time being, but I can't be 100% sure due to my lack of knowledge and understanding.

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

[dpetka2001]

Not stale.

[gengdz]

Same issue.

[steve21168]

So, I tried testing something. I created an autocmd

vim.api.nvim_create_autocmd("CmdlineChanged", {
  group = vim.api.nvim_create_augroup("update_search_redraw", {}),
  desc = "Update search redraw",
  callback = function()
    vim.schedule(function()
      vim.cmd("redraw")
    end)
  end,
})

Not sure how safe this is, since it mentions

Be careful not to mess up the command line, it may cause Vim to lock up.

Still in testing phase, I haven't observed any lock ups. But if you encounter any problems, it might be because of this autocmd, so use it at your own risk. This is not a suggestion to solve the problem at hand, it's just something I'm experimenting with. Hopefully Folke will have some more insight after he comes back.

Wow how did you find this out? I was having a completely different issue, where text wasn't showing up for me AT ALL while searching with noice, unless cmp was showing me completions.

The only conclusion I can draw with my limited knowledge is that noice is not redrawing properly.

With your change (snappy/fast):

Without:

I have this same issue where the search text wasn't showing at all. The redraw auto command is also a successful workaround for me.

[dpetka2001]

Please do bare in mind that my knowledge is very limited and this was purely based on me testing things out. In case you have other side effects, this autocmd might be at fault (it already has a warning about this on the help page of the CmdLineChanged event that I've already mentioned in my previous post). Again, the more correct way will surely be something that Folke comes up with to solve this problem. I'm just not at that level to understand and come up with a proper solution with regards to noice's codebase.

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

[hb0nes]

Not stale.

On Sun, Oct 13, 2024, 04:06 github-actions[bot] @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/folke/noice.nvim/issues/892#issuecomment-2408786023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJIOJVKJX4BOVEISOK3LE2LZ3HIT5AVCNFSM6AAAAABKYYX4H6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYG44DMMBSGM . You are receiving this because you commented.Message ID: <folke/noice. @.***>