nvim-tree

[mikew]

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 to nvim_tree_hack.

There's also some evidence this could be on nvim-drawer's end:

• The first version of this plugin didn't have this issue.
• Maybe the functionality included with nvim_tree_hack is legit and could be named something better.

[alex-courtis]

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 nvim-tree/nvim-tree.lua#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.

[mikew]

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 😅

nvim-tree/nvim-tree.lua#2255

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.

[alex-courtis]

edgy.vim

Different use cases; drawer is more dynamic.

[mikew]

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

[mikew]

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.