Feature Request: Open and operate dirbuf from a floating window

[jeetsukumaran]

Floating windows are perfect way to handle "meta-buffers" like this (if you do not need access to any other buffer at the same time). This doesn't interfere with all your other window arrangements like opening and closing dirbuf does in regular windows/splits.

This modality would be nicely supported by the following plug dirbuf-local mappings while inside the floating window:

• <plug>(dirbuf-float-cancel) Close the floating window.

• <plug>(dirbuf-open) Open the currently selected file in the previous window.

• <plug>(dirbuf-open-vsplit) Open the currently selected file in a vertical split off the previous window.

• <plug>(dirbuf-float-open-split) Open the currently selected file in a horizontal split off previous window.

etc.

[elihunter173]

I think this is an interesting idea. I actually kinda like it, but I think adding floating windows to Dirbuf would be better suited as either personal user configuration or as a companion plugin.

My rationale for this is having good floating window support is fairly complex with a lot of configuration knobs, especially compared to how much value it brings to Dirbuf, so it's not something I'm personally willing to maintain. In general, one of my main goals with Dirbuf is to have it be minimal where it has only features (almost) everyone uses and only exposes configuration variables that are simple or otherwise difficult for a user to configure (e.g. sort_order).

I also suspect (and hope) Dirbuf is currently flexible enough that you could implement floating window support with a combination of dirbuf.init_dirbuf(), remapping <CR> to dirbuf.enter({cmd}) with a different command, and/or using dirbuf.get_cursor_path() for custom mappings / re-mapping features.

[jeetsukumaran]

Fair enough.

But TBH, floating windows actually solve a lot of problems with window layouts being messed up. In all my plugins, e.g. Buffergator, FileBeagle etc., that open a temporary buffer in a window, it takes a LOT of overhead to store previous layouts and restore them when exiting the temporary window/buffer -- you have to store the calling window / buffer, restore the previous buffer in its original window (if a new window was not opened), and then delete the temporary buffer in background.

While the initial investment in figuring out the floating window is tricky, from a plugin developer perspective, it makes maintenance and operation sooooooo much easier in the long run (assuming that seamless/non-intrusive exiting of your plugin is an important design consideration). All IMHO, of course :)

[elihunter173]

But TBH, floating windows actually solve a lot of problems with window layouts being messed up

I completely agree here with opening temporary windows, but I don't think I have these issues with Dirbuf. I always open it in a vim-vinegar style where I either use Dirbuf to change directories or to briefly do some modifications on the directory. Could you give an example where using Dirbuf results in messing up your window layout?

assuming that seamless/non-intrusive exiting of your plugin is an important design consideration

It is! My general philosophy with Dirbuf with respect to window management is to have simple vim-vinegar style window management but be extensible enough that user configuration or companion plugins can implement any specific window management they like

[jeetsukumaran]

Could you give an example where using Dirbuf results in messing up your window layout?

1. Have two splits, say Left and Right. Two different buffers in the split.
2. In Split Left, call Dirbuf directly.
3. Look around, etc. but don't select a file.

Now, how do I quit and go back to the layout I had before?

If I ":bwipe", I lose a split.

If I "<C-o>", it works in some cases --- i.e., Dirbuf closes and I am back to what I had before. But it fails when:

• if I use some Vim motions while navigating files/directories, the first few <C-O>'s might take me to places within Dirbuf rather than the previous buffer
• If I have changed the name of the original buffer, <C-o> gives me an error
• If the previous buffer was a [No Name] then it will take me to a buffer that I did not ever want to get to and may not even have been open in this session (just the last jump location saved from a previous session)
• Worse, <C-o> (at least in my setup) loads a whole bunch of files as unlisted buffers (try <C-o> from Dirbuf and then do :ls!)
• In any case, <C-o> in this case is an anti-pattern because it uses the jumplist and that should not be part of a Dirbuf "excursion"

A lot of this will go away with https://github.com/elihunter173/dirbuf.nvim/issues/29#issuecomment-1079778286, admittedly, but all of it will go away with floating windows ...

[jeetsukumaran]

As for the other (valid) "style" of using Dirbuf -- i.e. creating a split first and then opening Dirbuf in there ...

(1) I do that myself sometimes when appropriate (2) But other times, I find this awkward:

• it adds an split to a view that makes all the other splits smaller and itself is small; maybe this not a problem at times . But sometimes the reduced split size is a pain
• when leaving Dirbuf without choosing anything, I now have an extra split that I have to close

So many times I prefer to open Dirbuf in the current split and want the previous buffer restored when I exit. It is precisely these times that a floating window would be fantastic, not only not disturbing my background layout, but at the same time providing so much more real estate to view and focus on the filesystem (as opposed to crowded in on a split) and then drop back seamlessly into whatever I was doing before.

[elihunter173]

Now, how do I quit and go back to the layout I had before?

You can also hit <C-6> to go back to the previous buffer you had before you opened the directory buffer since Dirbuf preserves your alternate buffer!

But I get what you mean in both of your comments since this isn't very elegant or intuitive and I understand the appeal of floating windows. I hope #29 and #28 should provide a sufficient solution for these situations. If you (or anyone else reading this) wants to take a stab at making a companion floating window plugin, I'd be happy to link it in the README and make reasonable changes to Dirbuf to make the plugin possible.

But I do feel strongly that Dirbuf itself shouldn't implement floating windows because I would like to keep Dirbuf very minimal, stable, and vim-vinegar-esque and I think floating windows would significantly expand it's command and function surface area and would take a lot of tweaks (i.e. instability) to get right. And a lot of this comes from a frustration with the state of floating windows in Neovim where the API is fairly low level and every plugin has to re-implement decorations like borders which results in floating windows looking inconsistent and having a lot of duplicated configuration

[jeetsukumaran]

Now, how do I quit and go back to the layout I had before?

You can also hit <C-6> to go back to the previous buffer you had before you opened the directory buffer since Dirbuf preserves your alternate buffer!

Yes, but in doing so this would break the alternate buffer's actual alternate buffer! E.g., I'm switching back and forth between two files using <C-6>. E.g., "A" and "B". Calling up Dirbuf from "A" and then <C-6>-ing back means I've lost the ability to <C-6> back to "B" again and have to manually open it up to restore where I was before.

But I get what you mean in both of your comments since this isn't very elegant or intuitive and I understand the appeal of floating windows. I hope #29 and #28 should provide a sufficient solution for these situations. If you (or anyone else reading this) wants to take a stab at making a companion floating window plugin, I'd be happy to link it in the README and make reasonable changes to Dirbuf to make the plugin possible.

Fair enough. Thanks!

But I do feel strongly that Dirbuf itself shouldn't implement floating windows because I would like to keep Dirbuf very minimal, stable, and vim-vinegar-esque and I think floating windows would significantly expand it's command and function surface area and would take a lot of tweaks (i.e. instability) to get right. And a lot of this comes from a frustration with the state of floating windows in Neovim where the API is fairly low level and every plugin has to re-implement decorations like borders which results in floating windows looking inconsistent and having a lot of duplicated configuration

No worries. Happy to close this now and maybe I'll reopen it if I come up with PR or a plugin that might help. Thanks for the consideration.