bug: "AerialOpen float" is always empty, but "left" and "right" work

[Hubro]

Neovim version (nvim -v)

v0.10.0-dev-d2e7cc6

(Just tested v0.9.4 and it works, so it's specifically an issue with nightly)

Operating system/version

NixOS 23.11

Output of :AerialInfo

Aerial Info
-----------
Filetype: python
Configured backends:
  treesitter (supported) (attached)
  lsp (supported)
  markdown (not supported) [Filetype is not markdown]
Show symbols: Class, Constructor, Enum, Function, Interface, Module, Method, Struct

Describe the bug

AerialOpen left and AerialOpen right always work, but AerialOpen float is always empty:

The first time I run AerialOpen float in a Neovim session, it shows "Loading", but nothing ever happens:

If I reopen it, it's an empty window like above.

Steps To Reproduce

1. Open any document supported by Aerial
2. Run :AerialOpen float
3. See empty floating window, no visible error messages

Expected Behavior

Should have the same content as :AerialOpen left/right

Minimal example file

class Foo:
    def foo():
        pass

    def bar():
        pass

Minimal init.lua

-- 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",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  {
    "stevearc/aerial.nvim",
    config = function()
      require("aerial").setup({
        -- add your aerial config here
      })
    end,
  },
  {
    "nvim-treesitter/nvim-treesitter",
    build = ":TSUpdate",
    config = function()
      require("nvim-treesitter.configs").setup({
        ensure_installed = { "c", "lua" },
        auto_install = true,
        highlight = { enable = true },
      })
    end,
  },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

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

Result:

Additional context

Tried with and without my Aerial config, didn't make a difference.

:AerialNavOpen works, so the only thing that doesn't work is :AerialOpen float, which is my preferred use case 😄

[Hubro]

I just updated my nightly build to v0.10.0-dev-b32b5b2 and it's still broken, but then I tried downloading the official nightly AppImage (v0.10.0-dev-1731+g0bbe8e7fc) and there it works 😕

So it seems to only be broken in my nightly builds from neovim-nightly-overlay for some reason. Very strange. Sorry for the noise!

[Hubro]

Hold on, now it's broken in the nightly appimage too. Demonstration:

Neovim 0.9.4 and 0.9.5:

Neovim v0.10.0-dev-2129+gba9f86a9c (nightly appimage):

Symptoms are all as initially described.

[stevearc]

I found two bugs. One of them was easy to fix, the other one I have filed upstream neovim/neovim#27121

[b0o]

In case it's helpful to anyone, I'm using this workaround until the bug is fixed upstream:

vim.keymap.set('n', '<leader>af', function()
  -- NOTE: Workaround for https://github.com/stevearc/aerial.nvim/issues/331
  require('aerial').refetch_symbols()
  vim.cmd.AerialOpen 'float'
  vim.cmd.doautocmd 'BufWinEnter'
end)

[stevearc]

This appears to be fixed upstream now. Can you try it again on the most recent nightly?

[b0o]

This appears to be fixed upstream now. Can you try it again on the most recent nightly?

Works for me now without manually triggering the autocommand, but I still need to do refetch_symbols first or else the symbols might be stale. Not sure if that is the same issue or not.

[stevearc]

When you say the symbols might be stale, what problem does this manifest as? Like if you've recently added a symbol it may not be present? Or there won't be any symbols? And is this sporadic or does it happen every time for you?

[b0o]

Like if you've recently added a symbol it may not be present

Yes, after I open Aerial for the first time, the symbols will be correct at first, but won't update as I add/remove them in the buffer until I call refetch_symbols.

And is this sporadic or does it happen every time for you?

Every time.

I just checked my config and switching from backends = { 'lsp', 'treesitter', 'markdown', 'man' } to backends = { 'treesitter', 'lsp', 'markdown', 'man' } seems to have fixed that issue.

[stevearc]

Hmmm...this sounds like it might be related to the specific LSP server. Does this happen with other LSP servers? Another thing you can try is setting the config value lsp.diagnostics_trigger_update = false. That should be more reliable about updating your symbols.

Also, does this only happen for :AerialOpen float, or does it also happen for :AerialOpen left?

[b0o]

Does this happen with other LSP servers?

It happens with both tsserver and lua_ls. Not sure about others.

Also, does this only happen for :AerialOpen float, or does it also happen for :AerialOpen left?

It happens with both.

Another thing you can try is setting the config value lsp.diagnostics_trigger_update = false

That works!

[stevearc]

If lsp.diagnostics_trigger_update = false fixes the problem, then it's probably just an issue with our interaction with the LSP diagnostics as a trigger to re-fetch symbols. I'll mark this issue as closed now and look into making that config option the default.