Aerial and stickyness

[LeonardoMor]

This has been merged for some time now.

It's been some time since I last modified my Neovim config. So as is, it still relies on stickybuf.nvim.

Sometimes when I'm editing a file and want to go to an already open aerial window, I press the normal key combination and I get an error like this:

Error executing vim.schedule lua callback: Vim(buffer):E86: Buffer 373 does not exist
stack traceback:
        [C]: in function 'win_execute'
        .../.local/share/nvim/lazy/stickybuf.nvim/lua/stickybuf.lua:47: in function '_on_buf_enter'
        .../.local/share/nvim/lazy/stickybuf.nvim/lua/stickybuf.lua:242: in function ''
        vim/_editor.lua: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

I have no idea how to reproduce this issue. I thought it was happening after the symbols changed, say by introducing a new function. But I tested and that was not the case.

I don't know if I should change my config or if aerial should be modified to not rely on stickybuf.nvim.

[stevearc]

Technically aerial doesn't rely on stickybuf, stickybuf adds an autocmd that hooks and pins aerial buffers. Switching to winfixbuf is unfortunately not straightforward. What stickybuf gives you is the ability to run some lua function to determine if the buffer can be replaced or not, whereas winfixbuf just pins exactly the current buffer. This is incredibly helpful because you may want to have a window that is the "aerial window", but it actually does switch buffers to always display the symbols for your other currently active buffer. This is also useful for things like help docs, where you may want that window to only display help, but any help file. To make winfixbuf work, I'd have to refactor the logic in aerial to use it directly, then unpin & repin whenever aerial itself needs to switch the buffer.

That said, if you manage to get a repro I can look into it.