reduced width from caller window (and some other visual nits)

[petobens]

Hi! I have the following aerial setup:

require('aerial').setup({
    layout = {
        width = 43,
        default_direction = 'left',
        placement = 'edge',
    },
    close_on_select = true,
    highlight_on_hover = true,
    highlight_on_jump = 500,
})

-- Autocmds
local aerial_acg = vim.api.nvim_create_augroup('aerial', { clear = true })
vim.api.nvim_create_autocmd('FileType', {
    group = aerial_acg,
    pattern = { 'aerial' },
    command = 'setlocal number relativenumber',
})

If, as in the GIF, I

1. Open aerial from a vertical split window then the window from which aerial is being called gets narrow (compared for instance with something like nvim.lua). I would expect the aerial window to open and have the other windows equally resized (in the gif you can see that the right window keeps its size but the left window gets terribly narrow).
2. If I open aerial and close it with q then cursor doesn't return to the calling window (in my case I'm calling aerial from the right window and when I press q the cursor jumps to the left window).
3. Is there a way to distinguish between AerialLine hl and the aerial buffer cursorline? I (personally) see no reason why if I move the cursor down a line then the previous line in the Aerial buffer is still highlighted by AerialLine (see the last seconds of the gif where gdk_env remains highlighted by the cursor is on qt_env).

Sorry for the multiple issues(?). Thanks in advance.

[stevearc]

1. This is an ongoing struggle. Vim has :help equalalways which preserves equality of window width, but not if you specify a width during the split operation. Resizing a window after the split does not preserve width equality. I think vim currently lacks the ability to express your desired window behavior with options, and lacks tools to enforce that layout. This is something I would happily read a design doc or pull request for, but I'm not inclined to try to hack around it myself.
2. That sounds reasonable. I've pushed a change that should do this
3. This is actually working as intended. The highlight is displaying where the cursor is in the code window

[petobens]

1. Ok. I though that maybe it could be added behind a flag or there was some sort of config/option I missed (nvimtree for instance does this)
2. Thanks!
3. Oh ok.

Feel free to close if you deem fit!

[stevearc]

For nvim-tree, they have a config option (view.preserve_window_proportions) that defaults to false, which means after opening the tree they run wincmd = which assigns all windows to be equal width. I initially used that behavior, but some users disliked it so I took it out. I could add it back in behind a config option, but you could also get the same behavior by using a mapping like

vim.keymap.set("n", "<leader>a", ":AerialToggle<CR>:wincmd =<CR>")

[petobens]

Mmm I tried the mapping but it doesn't seem to achieve the desired effect? Note that the second time I run wincmd = the window still gets resized.

[stevearc]

I don't think I understand. In the gif I see you open aerial, the windows are uneven, then :wincmd =, then the windows are evenly spaced (minus the fixed width of the aerial window). Isn't that what you wanted? What am I missing?

[petobens]

Oh sorry.. I'm calling the aerial window with your mapping above:

vim.keymap.set("n", "<leader>a", ":AerialToggle<CR>:wincmd =<CR>")

But it doesn't seem to work (since if I call wincmd = again, as in the GIF, the windows get resized)

[stevearc]

Ah, okay that makes sense then. There's a couple tricky edge cases because the width is technically set slightly after the window is initially opened. I think that it's difficult enough to deal with to merit inclusion as a config option. You should be able to get this behavior now

require("aerial").setup({
  layout = {
    preserve_equality = true
  }
})

[petobens]

Awesome! Thank you