search

nvim-tree / nvim-tree.lua

A file explorer tree for neovim written in lua
Other
7.22k stars 610 forks source link

Multi Instance - Contributors Wanted - Please Take An Issue #2255

Open alex-courtis opened 1 year ago

alex-courtis commented 1 year ago

Project Board

Any and all contributions are most gratefully appreciated.

Please comment on or assign yourself an issue if you're working on it.

Current State

nvim-tree allows and supports exactly one window per tab, however there is some shared state between windows.

Problems

Desired Outcome

Implementation Notes

Limitations

Implementation Plan

An incremental approach is more practical, with a feature branch likely interrupting development due to its cross-cutting nature.

  1. Refactor: move global state / singletons under the explorer.
  2. Build, experimental feature flag: discrete tree instances for each window.
  3. Consolidate: callbacks or state updates such as git, watchers, refresh should be applied to each instance.
  4. Release 2.0.0: following experiment testing, release with the discrete option turned ON by default, as that is closest to current behaviour.

It's not clear yet whether 2 and 3 would be implemented at the same time or sequentially. Simplest/safest implementation can be determined once work begins on 2.

References

thenbe commented 1 year ago

Discrete nvim-tree windows, with their own state that does not affect others.

This could enable us to use NvimTree with edgy.nvim to achieve something like this:

raaymax commented 4 months ago

I've been following this issue since it started, and it's been over a year now. It feels like merging all these topics has stalled the discussion, and no progress is being made to address it. This is the feature I look forward to the most, and it's the only reason I still use NERDTree for some projects. I'm eager to move away from that plugin.

Overall, this plugin is fantastic, and it has significantly improved my workflow. I appreciate all the hard work that has gone into making it so great.

I'm willing to help with the development to get this feature implemented. Could you please share what's currently blocking this feature or provide a roadmap? This would help me and others to contribute more effectively.

alex-courtis commented 3 months ago

I'm willing to help with the development to get this feature implemented. Could you please share what's currently blocking this feature or provide a roadmap? This would help me and others to contribute more effectively.

Thanks for bearing with us @raaymax . The only blocker is developer time. Any and all contributions are most gratefully appreciated!

See high level implementation plan above and project board for some refactoring tasks.

alex-courtis commented 3 months ago

Project Board

Any and all contributions are most gratefully appreciated.

Please comment on or assign yourself an issue if would like to work on it OR create a PR (it can be a placeholder) with the issue number e.g. "fixes #9876" in the description.

Current State

nvim-tree allows and supports exactly one window per tab, however there is some shared state between windows.

Problems

  • Multiple windows may be opened in one tab via split, however this is not functional
  • Windows across tabs are somewhat discrete in that they have their own buffer, however some state is shared e.g. opened folders and bleeds across tabs

Desired Outcome

  • Discrete nvim-tree windows, with their own state that does not affect others.
  • Single shared nvim-tree windows across tabs, with identical / mirrored state. This is similar to the tree of some IDEs.

Implementation Notes

  • Single instance would use the one buffer and state. This would result in the tree being closed across tabs.
  • Discrete instances would require the global state to be stored per-instance.
  • Global states such as filesystem and git would need to be shared, with single global watchers / background tasks.

Limitations

  • This will likely need to be a binary option. Providing a means to manage discrete and shared instances would be (impossibly?) problematic from a UX perspective.
  • Floating tree windows are closed when they lose focus, including when swapping tabs. Floating would continue to be restricted to a single ephemeral instance.

Implementation Plan

An incremental approach is more practical, with a feature branch likely interrupting development due to its cross-cutting nature.

  1. Refactor: move global state / singletons under the explorer.
  2. Build, experimental feature flag: discrete tree instances for each window.
  3. Consolidate: callbacks or state updates such as git, watchers, refresh should be applied to each instance.
  4. Release 2.0.0: following experiment testing, release with the discrete option turned ON by default, as that is closest to current behaviour.

It's not clear yet whether 2 and 3 would be implemented at the same time or sequentially. Simplest/safest implementation can be determined once work begins on 2.

References