nvim_buf_call() causes rendering artifacts with :redrawstatusline

[dmitmel]

Neovim version (nvim -v)

0.6.1

Vim (not Nvim) behaves the same?

N/A

Operating system/version

Arch Linux

Terminal name/version

kitty 0.23.1

$TERM environment variable

xterm-kitty

Installation

pacman, official repositories

How to reproduce the issue

1. The minimal vimrc:

   set runtimepath^=~/.config/nvim/plugged/nvim-lspconfig
   
   " I chose sumneko/lua-language-server because it publishes empty lists of
   " diagnostics for all files in the workspace upon completing indexing of the
   " project, so it makes the problem more apparent.
   lua require('lspconfig')['sumneko_lua'].setup({})
   
   set title
   
   " A sufficiently complex statusline to show the screen rendering glitches.
   set runtimepath^=~/.config/nvim/plugged/vim-airline
   let g:airline#extensions#tabline#enabled = 1
   let g:airline#extensions#nvimlsp#enabled = 1
   
   " I have this in my vimrc to update the counters in the statusline.
   autocmd DiagnosticChanged * redrawstatus
   
   " This is unrelated to the bug, it is simply done to ease the wait for the
   " workspace to be fully indexed.
   autocmd User LspProgressUpdate echo v:lua.vim.lsp.util.get_progress_messages()

2. Inside the neovim work tree, run nvim -u minimal_init.vim runtime/lua/vim/lsp/buf.lua runtime/lua/vim/lsp/*.lua. Strictly speaking, opening multiple files like this is not a requirement, but it just shows more rendering artifacts with the statusline. The buf.lua file is first in the list because there are some diagnostics reported for it, and they will be shown in the statusline.

Expected behavior

Neovim v0.6.0

simplescreenrecorder-2022-01-01_18.58.42.mp4

Actual behavior

Neovim v0.6.1 (the pink flashing box is caused by redrawstatus)

simplescreenrecorder-2022-01-01_18.59.44.mp4

Additional context

The problem is caused by #16474 and #16589. I believe that a proper solution would be to execute the autocommands with Vim's internal functions (apply_autocmds_group?), that only change the effective buffer (<abuf>) instead of also changing the real current buffer.

[gpanders]

I wonder if this is because of the nvim_buf_call. If you remove that wrapper from diagnostic.lua can you still reproduce the issue?

[dmitmel]

Yes, it is because of nvim_buf_call. I've tried that and it worked just fine - that's why I pinpointed the cause to those two PRs.

[dmitmel]

Merely calling vim.api.nvim_buf_call (without doing :doautocmd inside of it) in vim.diagnostic.set is enough to reproduce the issue (at least the part with changing terminal title - so this may be a bug of nvim_buf_call in and of itself). And, again, it has the problem of changing the real current buffer, so you can't do something like this (which you would be able to only if the effective buffer was changed):

autocmd DiagnosticChanged * if +expand('<abuf>') == bufnr('') | redrawstatus | endif

[gpanders]

Yes, it is because of nvim_buf_call. I've tried that and it worked just fine - that's why I pinpointed the cause to those two PRs.

Apologies, I missed that in your original comment (I really ought to stop replying to issues on mobile).

It seems that the issue is really with nvim_buf_call switching buffers, not with the DiagnosticChanged autocommand itself. Out of curiosity, if you add a check in diagnostic.lua to see if bufnr is the current buffer and omit the call to nvim_buf_call in that case, does that fix the problem (I am guessing it won't, but I'm still curious)?

[dmitmel]

Apologies, I missed that in your original comment (I really ought to stop replying to issues on mobile).

Ah, no problem, I edited the body of the issue after posting it.

if you add a check in diagnostic.lua to see if bufnr is the current buffer and omit the call to nvim_buf_call in that case, does that fix the problem (I am guessing it won't, but I'm still curious)?

Just tried - no effect.

[tomtomjhj]

I had a similar issue with lightline:

au DiagnosticChanged * call lightline#update()

Lightline thinks that the nvim_buf_called buffer/window is the "active window", and this makes statusline for active window appear in an actually inactive window.

Wrapping the command with schedule_wrap fixed the issue for me.

au DiagnosticChanged * lua vim.schedule_wrap(function() vim.fn['lightline#update']() end)

[dmitmel]

This bug may be fixed by using nvim_exec_autocmds, now that it exists, it has a bufnr argument.

[dmitmel]

@tomtomjhj By the way, vim.schedule_wrap creates a function that calls vim.schedule with the function you gave it. So, in your code, lightline#update is not called at all.

[tomtomjhj]

@dmitmel Ah, thanks. vim.schedule(function() vim.fn['lightline#update']() end seems to do what I actually meant.