Open mikew opened 2 weeks ago
This is working around the failings of nvim-tree's handling of multiple instances (across tabs etc.) and shouldn't be needed. This should be tested for and resolved when completing https://github.com/nvim-tree/nvim-tree.lua/issues/2255
I think this is a valid case for nvim-tree regardless, as users may want the tree to change across tabs: different root, filters, marks etc.
I can imagine aerial users may want similar for, say, different file sets or languages across tabs.
I think this is a valid case for nvim-tree regardless, as users may want the tree to change across tabs: different root, filters, marks etc.
Agreed, now to come up with a better name for it 😅
I came across this issue when debugging, I'll keep an eye on it. Also, wish I took a look at edgy.vim earlier. Pretty neat.
edgy.vim
Different use cases; drawer is more dynamic.
Aye, I tried it out a couple of hours ago and found out the splits don't stick around
I do like the general concept of it, how you give it file / buffer / your own logic and it makes a window out of it.
I am looking to add "sub-splits" to nvim-drawer, and considered grouping drawers on the same side. And some sort of convert _to_drawer(winid)
API
I ended up renaming this variable, hack
is never a great thing to call something public, and it's also not cool to associate another plugin with hack
.
I ended up adding a special option for nvim-tree and I'll try to explain a little what's going on.
The option is named
nvim_tree_hack
. What is does, is not keep the same buffer when changing tabs. Ideally, nvim-drawer could just keep using the same buffer (that is kind of its whole point lol).If you re-use an nvim-tree buffer in a different window, it might update, but it doesn't respond to any mappings. Calling its included
default_attach
also doesn't seem to do it, tho that would be a better solution tonvim_tree_hack
.There's also some evidence this could be on nvim-drawer's end:
nvim_tree_hack
is legit and could be named something better.