aerial.nvim
aerial.nvim copied to clipboard
AerialClose, AerialToggle etc should work from any buffer, and not just the buffer from which the original symbols outline was opened from
Description
Let's say that the aerial window is open that displays the symbols tree for the current buffer. Now, let's open a new vertical split, and the cursor is now in the newly opened vertical split. If we don't wish to display the aerial window any more (because it is no longer relevant), neither the :AerialClose
nor the :AerialToggle
commands work from the newly opened split.
We are forced to navigate back to the original buffer that corresponds to the aerial window, so as to close the Aerial window, and then navigate back to the newly opened split for editing. This is disruptive to a user's coding flow, and could be a pain when there are multiple splits open (we are forced to navigate back to the original split just to close the aerial window).
System information
- OS: Linux
- Neovim version:
- AerialInfo:
Filetype: lua
Configured backends:
treesitter (supported) (attached)
lsp (not supported) [LSP client not attached]
markdown (not supported) [Filetype is not markdown]
Show symbols: Array, Boolean, Class, Constant, Constructor, Enum, EnumMember, Event, Field, File, Function, Interface, Key, Method, Module, Namespace, Null, Number, Object, Operator, Package, Property, String, Struct, TypeParameter, Variable
- Aerial config:
require("aerial").setup({
backends = { "treesitter", "lsp", "markdown" },
min_width = 20,
on_attach = function(bufnr)
-- Jump forwards/backwards with '{' and '}'
vim.keymap.set('n', "}", "}", { silent = true })
vim.keymap.del("n", "}")
vim.keymap.set("n", "<leader>{", "<cmd>AerialPrev<cr>", { buffer = bufnr, desc = "Jump backwards in Aerial" })
vim.keymap.set("n", "<leader>}", "<cmd>AerialNext<cr>", { buffer = bufnr, desc = "Jump forwards in Aerial" })
-- Jump up the tree with '[[' or ']]'
vim.keymap.set('n', "]]", "]]", { silent = true })
vim.keymap.del("n", "]]")
vim.keymap.set('n', "[[", "[[", { silent = true })
vim.keymap.del("n", "[[")
vim.keymap.set("n", "<leader>[", "<cmd>AerialPrevUp<cr>", { buffer = bufnr, desc = "Jump up and backwards in Aerial" })
vim.keymap.set("n", "<leader>]", "<cmd>AerialNextUp<cr>", { buffer = bufnr, desc = "Jump up and forwards in Aerial" })
end,
placement_editor_edge = true,
open_automatic = function(bufnr)
-- Enforce a minimum line count
return vim.api.nvim_buf_line_count(bufnr) > 26
-- Enforce a minimum symbol count
and require("aerial").num_symbols(bufnr) > 3
-- -- A useful way to keep aerial closed when closed manually
and not require("aerial").was_closed()
end,
close_behavior = "close", -- aerial window will close when original file is no longer visible
})
To Reproduce Steps to reproduce the behavior:
- Edit a buffer that has some symbols e.g. your neovim
init.lua
config file. Open the aerial window that shows the symbols in a vertical split to the far right - In a vertical split, open another file (maybe a plain text file from your filesystem) that doesn't have any symbols, so that the aerial symbols window is irrelevent.
- In the newly opened split with the plain-text file, try running
:AerialClose
or:AerialToggle
. The aerial window persists (which is taking up screen space on a narrow laptop display). - Open more vertical and horizontal splits with files to view and edit
-
:AerialClose
or:AerialToggle
do not work and the irrelevant symbols tree persists - Navigate all the way back to the original buffer from which the aerial window was initially opened. Now,
:AerialClose
or:AerialToggle
will work - Navigate back to the other split to continue editing (sigh!).
Screenshots
Let's say we are editing this init.lua
that has a symbols tree aerial window opened as shown below
Now, we want to edit some plain-text notes. The symbols tree to the right becomes irrelevant, and taking up more space. :AerialClose
or :AerialToggle
does not work.
Have to navigate back to the original buffer from which the aerial window was opened to close the aerial
buffer.
And now, move back to the far right split to continue writing.
I can add logic to make :AerialClose
close the first unrelated aerial window if the buffer doesn't have any symbols, but making this work for :AerialToggle
may not be possible. If a user issues :AerialToggle
from a buffer with no symbols, it's not clear if they wanted aerial to open (not knowing that there are no symbols), or if they wanted to close another visible aerial window. The ambiguity means that no solution will be intuitive 100% of the time, so I'm inclined to keep it the way it currently is.
The :AerialClose
case is less ambiguous, so I feel okay about adding that functionality
Hi, thank you for considering implementing :AerialClose
from an unrelated buffer.
I see that you've made a commit towards implementing this. However, even after pulling the latest commits, with the default settings of aerial.nvim
, this does not still work.
Can't reproduce; it works fine for me. Note that it won't close if you are in a window that does support symbols. This was only added for buffers with no aerial support, since close_behavior = 'global'
should cover the other cases.
I have double-checked. This works with buffers with no symbols only when close_behavior = global
. In the 3 other cases i.e. with auto
, persist
or close
, issuing :AerialClose
from a non-supported buffer does not work all all.
Ah, you meant for buffers with support but zero symbols. Updated and it should handle that case now too.
Yes. I can confirm that this now works well.