Delete json buffer cause bug

[ThaiDuy12345]

Description

Using BufferClose cmd on a .json buffer filetype cause this error

Error message:

E5108: Error executing lua: vim/_editor.lua:0: nvim_exec2(): Vim:...e/.local/share/nvim/lazy/barbar.nvim/lua/barbar/bbye.lua:60: nvim_exec2()..DiagnosticChanged Autocommands for "*": Vim(append):E315: ml_get: Invalid lnum: 1

https://github.com/romgrk/barbar.nvim/assets/103923561/3dce663d-7a9c-4c80-b631-5bb4a74a63b1

To Reproduce

my config:

barbar_opts = {
    animation = true,
    auto_hide = false,
    tabpages = true,
    clickable = true,
    focus_on_close = 'left',
    hide = {extensions = false, inactive = false},
    highlight_alternate = false,
    highlight_inactive_file_icons = false,
    highlight_visible = true,
    icons = {
      buffer_index = false,
      buffer_number = false,
      button = '',
      diagnostics = {
       -- [vim.diagnostic.severity.ERROR] = {enabled = false},
       -- [vim.diagnostic.severity.WARN] = {enabled = false},
       -- [vim.diagnostic.severity.INFO] = {enabled = false},
       -- [vim.diagnostic.severity.HINT] = {enabled = false},
      },
      gitsigns = {
       added = {enabled = false, icon = '+'},
       changed = {enabled = false, icon = '~'},
       deleted = {enabled = false, icon = '-'},
      },
      filetype = {
       custom_colors = false,
       enabled = true,
      },
      inactive = {
       separator = {left = '', right = ''},
      },
      -- separator = {left = '▎', right = ''},
      separator = {left = '', right = ''},
      separator_at_end = false,
      modified = {button = '●'},
      pinned = {button = '', filename = true},
      -- Use a preconfigured buffer appearance— can be 'default', 'powerline', or 'slanted'
      preset = 'default',

      -- Configure the icons on the bufferline based on the visibility of a buffer.
      -- Supports all the base icon options, plus `modified` and `pinned`.
      -- alternate = {filetype = {enabled = false}},
      -- current = {buffer_index = true},
      -- inactive = {button = '×'},
      -- visible = {modified = {buffer_number = false}},
    },

    insert_at_end = false,
    insert_at_start = false,
    maximum_padding = 4,
    minimum_padding = 2,
    maximum_length = 30,
    minimum_length = 0,
    semantic_letters = true,

    sidebar_filetypes = {
      NvimTree = true,
    },
    letters = 'asdfjkl;ghnmxcvbziowerutyqpASDFJKLGHNMXCVBZIOWERUTYQP',
    no_name_title = nil,
   }

Steps to reproduce the behavior:

1. Open a .json file
2. Then exec BufferClose

Informations Neovim version: 0.10 ( also using Neovide 0.12.2 but this is not relevant ) OS: WSL Ubuntu 22.04 - Window 11

[linrongbin16]

I can also reproduce this issue:

Though the error message seems different.

There're two more facts (info) I want to share:

1. Actually I had met this error long time ago, with another lua plugin: bufdelete.nvim.
2. This error never show up in the vimscript plugin: vim-bbye.

This is super strange, because after #579, the window_number variable should be first check is a valid window number before calling set_current_win API: https://github.com/romgrk/barbar.nvim/blob/79f7d16578a167bdf5355725551ef7d90613a601/lua/barbar/bbye.lua?plain=1#L159

So the fact of this error must be, the window_number is truly a valid window number, but still failed to be set as current window.

Based on my limited Neovim plugin developing knowledge:

1. We could simply wrap the set_current_win API with pcall, it should help avoid directly throw the exception to user. We can simply silently swallow/ignore the error.
2. The heading part of the error message Error executing Lua callback: reminds me something: the Neovim editor sometimes can have conflict behavior with the uv module. I am not an expert in this part, so maybe we could try wrap the flow after the set_current_win API with the vim.schedule.

[linrongbin16]

Update: I submit PR #584 to try to fix this issue, but this issue seems to be much more complicated than I thought.

For now I simply go back to use vim-bbye plugin.

[ThaiDuy12345]

Update: I submit PR #584 to try to fix this issue, but this issue seems to be much more complicated than I thought.

For now I simply go back to use vim-bbye plugin.

Okay, will try it out when the PR is up 😊

[romgrk]

That's messy :| Thanks for the details, I'll review the PR when it's ready.

[Zheng-ying-rong]

Good

[linrongbin16]

hi @romgrk ,

After spend some time to study vim-bbye, I believe the behavior of execute window . "wincmd w" - bbye.vim#L28 and set_current_win(window_number) - bbye.lua#L160 are different, and is the root cause of this issue.

I submit two PRs: #584 and #585 , using two solutions to fix this issue.

• 584 is using the pcall wrapper to avoid throwing exception when calling set_current_win API.

• 585 is using the execute window . "wincmd w" code. I personally prefer this PR, because wrap with pcall is just ignoring the error, not fixing it.

Both PR work correctly in my manual testing, here's the screen recording:

https://github.com/romgrk/barbar.nvim/assets/6496887/c02bfbbb-5653-432f-aa16-2d7bab4c5cb7

[swahpy]

Hi, I have the same issue. It happened when I go to definition using lsp navigation and then close the newly opened source file buffer. Hope we could have this fixed. For now I just filter this out in noice. Thank you.

[Iron-E]

Is this reproducible on earlier versions of Neovim, by chance?

Edit: Couldn't reproduce on 0.10, so update incompatibilities seem unlikely

[romgrk]

@swahpy I'm not sure I understand what happens in your case, details & screenshots appreciated.

[Iron-E]

Can someone who experiences this post a minimal reproduction? I have a template here:

--[[ minimal.lua ]]
local lazy = vim.fn.stdpath('data') .. '/lazy/'
vim.opt.rtp:prepend {
  lazy .. 'barbar.nvim',
  lazy .. 'nvim-web-devicons',
}

vim.g.barbar_auto_setup = false
require('barbar').setup { 
  -- additional options
}

-- additional code

vim.api.nvim_create_autocmd('VimEnter', { 
  callback = vim.schedule_wrap(function()
    -- additional post-startup code
    vim.cmd [[
      edit foo.json
      edit bar.json
      BufferClose
    ]]
  end),
})

Looking to run nvim --clean -u minimal.lua and see the error

[ThaiDuy12345]

Can someone who experiences this post a minimal reproduction? I have a template here:

--[[ minimal.lua ]]
local lazy = vim.fn.stdpath('data') .. '/lazy/'
vim.opt.rtp:prepend {
  lazy .. 'barbar.nvim',
  lazy .. 'nvim-web-devicons',
}

vim.g.barbar_auto_setup = false
require('barbar').setup { 
  -- additional options
}

-- additional code

vim.api.nvim_create_autocmd('VimEnter', { 
  callback = vim.schedule_wrap(function()
    -- additional post-startup code
    vim.cmd [[
      edit foo.json
      edit bar.json
      BufferClose
    ]]
  end),
})

Looking to run nvim --clean -u minimal.lua and see the error

Been testing with a minimal config, tested with the barbar plugin alone didn't happen anything, but cause when I setup LSPconfig along. Maybe the bug come from the LSP server itself? In this video I also use bdelete, the result is the same as BufferClose and it only happen on .html, .json, .css ...Didn't seem to catch this bug when I install others LspServer

https://github.com/romgrk/barbar.nvim/assets/103923561/a3eeb4ac-e5b0-4fa9-8997-2857b7626a5b

init.lua file:

local lazypath = vim.fn.stdpath("data") .. "/lazy/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",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({
  { "nvim-tree/nvim-web-devicons" },
  { "neovim/nvim-lspconfig", event = "VeryLazy" },
  { "williamboman/mason.nvim", event = "VeryLazy" },
  {
    "romgrk/barbar.nvim",
    keys = {
       { "<A-h>", "<cmd>BufferPrevious<CR>", desc = "Navigate to the previous buffer" },
       { "<A-l>", "<cmd>BufferNext<CR>", desc = "Navigate to the next buffer" },
       { "<A-H>", "<cmd>BufferMovePrevious<CR>",  desc = "Move the buffer to the previous" },
       { "<A-L>", "<cmd>BufferMoveNext<CR>",  desc = "Move the buffer to the next" },
       { "<A-c>", "<cmd>BufferClose<CR>", desc = "Delete current buffer and then navigate to the previous one" },
    },
    event = "VimEnter",
    config = function() require('barbar').setup() end
  },
  {
    "williamboman/mason-lspconfig.nvim",
    event = "VeryLazy",
    config = function()
      -- NOTE: Disabled LSP generate logging file
      vim.lsp.set_log_level("off")

      require("mason").setup({})

      -- local setupLSP = 
      require("mason-lspconfig").setup({
        ensure_installed = {
          "jsonls",                          -- json
          "html",                            -- html
      "cssls",
        },
        handlers = { 
           function(lsp_server)
              require("lspconfig")[lsp_server].setup({})
           end
        },
        automatic_installation = true,
      })
    end,
  },
})

[ThaiDuy12345]

According to https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md

The LSP causing the bug when delete the buffer are from https://github.com/hrsh7th/vscode-langservers-extracted

[ravibrock]

For what it's worth, I run into this bug when using basedpyright LSP to go to definition of library functions in Python and then running :bdelete afterwards. What I noticed, though, is that it only throws the error once, and after that (i.e. after clicking <CR> to clear the error messages) it seems to work fine, even if I repeat the go to definition -> close buffer process. Additionally, something else that seems to fix it is running :BarbarDisable followed by :BarbarEnable after opening Neovim. Not sure why this is.

[ThaiDuy12345]

For what it's worth, I run into this bug when using basedpyright LSP to go to definition of library functions in Python and then running :bdelete afterwards. What I noticed, though, is that it only throws the error once, and after that (i.e. after clicking <CR> to clear the error messages) it seems to work fine, even if I repeat the go to definition -> close buffer process. Additionally, something else that seems to fix it is running :BarbarDisable followed by :BarbarEnable after opening Neovim. Not sure why this is.

Agree, I also getting this error once, after pressing <CR>, repeat the step didnt catch the bug until I restart neovim...

while waiting to have this bug fix, Im right now using Telescope buffers to navigate between among buffers, pretty annoying since im coding an angular project, but no bug is showed up 🐞

[linrongbin16]

After several days back (I spent some days with family), I opened my macbook and upgrade all plugins and LSP servers (managed by mason.nvim) as usual.

And this issue is just gone..... I didn't do anything. I will notify if I have this issue again.

[ravibrock]

Still happening to me, though for some reason the bug appears on my work Macbook but not my personal one. As before, it's resolved by toggling Barbar on and off before closing buffers--this could perhaps be an easy, if somewhat hacky, fix for this issue.

EDIT: seems like it's not being resolved by toggling Barbar anymore. Strange.

[ThaiDuy12345]

After several days back (I spent some days with family), I opened my macbook and upgrade all plugins and LSP servers (managed by mason.nvim) as usual.

And this issue is just gone..... I didn't do anything. I will notify if I have this issue again.

Still happening the me

[romgrk]

So it should be fixed with the PR above but I haven't had time to reproduce. If you still experience the issue let me know I'll reopen this.

[ThaiDuy12345]

So it should be fixed with the PR above but I haven't had time to reproduce. If you still experience the issue let me know I'll reopen this.

Thanks, will try it after my work hour 😊