[Bug]: Entering command/ex mode while dropbar is active causes lualine delay

[KodyVB]

Description

This problem is only noticeable to me through lualine, but I can only reproduce it when dropbar is active, which makes me think it might be dropbar related. If the lualine repo is a more appropriate place to submit this bug report, please let me know.

I use lualine with laststatus = 3 so that the bar always stays in the same place, but the contents will change. But if I have the following conditions met:

1. Have multiple panes on the screen
2. Focus anything other than the top left pane
3. Have dropbar active (e.g. opening it as a blank test.lua file)

Then, when I open the command/ex mode by pressing :, then lualine will blank and take some amount of time to reload. Sometimes, it's very quick, while other times it can be about a second.

nvim version

NVIM v0.12.0-dev-1755+g6383123326 Build type: RelWithDebInfo LuaJIT 2.1.1764593432

dropbar.nvim version

ce20224

Operating system and version

Linux arch 6.18.1-arch1-2

Minimal config

local tmp = vim.env.TMPDIR
  or vim.env.TEMPDIR
  or vim.env.TMP
  or vim.env.TEMP
  or '/tmp'
local data = tmp ..  '/' .. (vim.env.NVIM_APPNAME or 'nvim')
local packages_root = data .. '/site'
local cloned_root = packages_root .. '/pack/packages/start'
local cloned_path_dropbar = cloned_root .. '/dropbar.nvim'
local url_dropbar = 'https://github.com/Bekaboo/dropbar.nvim.git'
local cloned_path_lualine = cloned_root .. '/lualine.nvim'
local url_lualine = 'https://github.com/nvim-lualine/lualine.nvim.git'

vim.fn.mkdir(cloned_root, 'p')
vim.opt.pp:prepend(packages_root)
vim.opt.rtp:prepend(packages_root)

if not vim.loop.fs_stat(cloned_path_dropbar) then
  vim.fn.system({ 'git', 'clone', url_dropbar, cloned_path_dropbar })
end

if not vim.loop.fs_stat(cloned_path_lualine) then
  vim.fn.system({ 'git', 'clone', url_lualine, cloned_path_lualine })
end

vim.go.laststatus = 3
require('dropbar').setup()
require('lualine').setup()

Steps to reproduce

1. Save the above file as minimal.lua
2. nvim --clean -u minimal.lua
3. Open blank file which has dropbar :e test.lua
4. Split the pane :split or :vsplit
5. Press : and then <esc> a few times for expected lualine behavior
6. Navigate to the pane not in top left via <c-w>l or <c-w>j
7. Press : and then <esc> a few times to see the delayed lualine behavior

Expected behavior

Dropbar being active should not affect lualine

Actual behavior

With laststatus = 3, focus on a pane that's not in top left, and dropbar active, lualine is affected.

Additional information

Here's a video of me trying it with dropbar active and not active, in the focused split and not.

Screencast_20251219_220959.webm

[Bekaboo]

Hi thanks for reporting this! I can reproduce this. However, I have no clue how dropbar can affect lualine. Could you please also open the issue in lualine's repo and reference this report?

Also, are you encountering the same issue with other winbar plugins? There are some alternatives listed in https://github.com/rockerBOO/awesome-neovim?tab=readme-ov-file#bars-and-lines. Please try them out and tell me your findings!

[KodyVB]

Sure thing. I tried using it with just lualine and set winbar=%f as a baseline, then with barbecue+nvim-navic, then with barbecue+nvim-navic+nvim-web-devicons. I couldn't reproduce the issue with any of those setups.

[tianqiii]

I met this today

[tianqiii]

this bug also appeared when I set vim.o.winbar = "%{%v:lua.require'nvim-navic'.get_location()%}" and disable this dropbar.nvim plugin

[tianqiii]

and interesting thing is when I use lspsaga.nvim to take control of winbar and enable this plugin, keymaps from this plugin works just fine (<leader>; [; ];), and lualine stop flash.