Skip to content

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

Open
1 of 9 issues completed
Open
Feature
1 of 9 issues completed
@alex-courtis

Description

@alex-courtis

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

  • 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

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions