Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: Statusline symbols from previous buffer shown on buffer with buftype = 'nofile' #602

Open
4 tasks done
cameronr opened this issue Nov 16, 2024 · 2 comments
Open
4 tasks done
Labels
bug Something isn't working

Comments

@cameronr
Copy link

cameronr commented Nov 16, 2024

Did you check docs and existing issues?

  • I have read all the trouble.nvim docs
  • I have updated the plugin to the latest version before submitting this issue
  • I have searched the existing issues of trouble.nvim
  • I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.2 Build type: Release LuaJIT 2.1.1727870382

Operating system/version

MacOS 15.0.1

Describe the bug

Statusline symbols from a previous buffer are shown on the current buffer if the buftype of the current buffer is 'nofile'. First noticed when using Neogit but also happens with :checkhealth:

Screenshot 2024-11-16 at 13 42 09
Screenshot 2024-11-16 at 13 42 15

In the above example, :=require('trouble.view.main'):get() returns:

{
  buf = 1,
  cursor = { 15, 0 },
  filename = "/Users/cam/.local/share/nvim-cam/lazy/trouble.nvim/lua/trouble/config/init.lua
",
  win = 1000
}

:=require('trouble.view.main')._main:

{
  buf = 1,
  cursor = { 15, 0 },
  filename = "/Users/cam/.local/share/nvim-cam/lazy/trouble.nvim/lua/trouble/config/init.lua
",
  win = 1005
}

:=require('trouble.view.main')._buf:

nil

It seems like it's happening because buffers with buftype ~= "" are being ignored. Commenting out this buftype ~= "" check fixes it:

if vim.bo[buf].buftype ~= "" then
return false
end

But I don't know if that's the "right" way to fix it.

Steps To Reproduce

  1. nvim -u repro.lua lua/trouble/config/init.lua
  2. Wait for lua_ls to index project
  3. place the cursor on a line that displays symbols on the statusline (e.g. lua/trouble/config/init.lua:15)
  4. run :checkhealth

Note: I was getting some weirdness where mason wouldn't correctly install lua_ls with repro.lua. If you get an error about lua_ls, just :MasonInstall lua-language-server to fix it.

Expected Behavior

No statusline symbols are displayed for the health window

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    -- minimal mason/lsp setup
    {
      "neovim/nvim-lspconfig",
      dependencies = {
        "williamboman/mason.nvim",
        "williamboman/mason-lspconfig.nvim",
        -- just for ls status
        { "j-hui/fidget.nvim", opts = {} },
      },
      config = function()
        require("mason").setup()

          require("mason-lspconfig").setup({
            ensure_installed = { "lua_ls" },
            handlers = {
              function(server_name)
                require("lspconfig")[server_name].setup({})
              end,
            },
          })
      end,
    },
    { "folke/trouble.nvim", opts = {} },
    {
      "nvim-lualine/lualine.nvim",
      opts = function()
        local trouble = require("trouble")
        local symbols = trouble.statusline({
          mode = "lsp_document_symbols",
          groups = {},
          title = false,
          filter = { range = true },
          format = "{kind_icon}{symbol.name:Normal}",
          -- The following line is needed to fix the background color
          -- Set it to the lualine section you want to use
          hl_group = "lualine_c_normal",
        })
        return {
          sections = {
            lualine_c = {
              { "filename" },
              {
                symbols.get,
                cond = symbols.has,
              },
            },
          },
        }
      end,
    },
  },
})
@cameronr cameronr added the bug Something isn't working label Nov 16, 2024
Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Dec 17, 2024
@cameronr
Copy link
Author

This still repros so i think is still an issue.

@github-actions github-actions bot removed the stale label Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant