aerial.nvim icon indicating copy to clipboard operation
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

Open krishnakumarg1984 opened this issue 2 years ago • 6 comments

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:

  1. 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
  2. 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.
  3. 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).
  4. Open more vertical and horizontal splits with files to view and edit
  5. :AerialClose or :AerialToggle do not work and the irrelevant symbols tree persists
  6. Navigate all the way back to the original buffer from which the aerial window was initially opened. Now, :AerialClose or :AerialToggle will work
  7. 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 image

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. image

Have to navigate back to the original buffer from which the aerial window was opened to close the aerial buffer. image

And now, move back to the far right split to continue writing. image

krishnakumarg1984 avatar May 03 '22 16:05 krishnakumarg1984

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

stevearc avatar May 04 '22 02:05 stevearc

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.

krishnakumarg1984 avatar May 04 '22 12:05 krishnakumarg1984

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.

stevearc avatar May 05 '22 00:05 stevearc

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.

krishnakumarg1984 avatar May 05 '22 17:05 krishnakumarg1984

Ah, you meant for buffers with support but zero symbols. Updated and it should handle that case now too.

stevearc avatar May 08 '22 19:05 stevearc

Yes. I can confirm that this now works well.

krishnakumarg1984 avatar May 15 '22 14:05 krishnakumarg1984