3. Window Management Server / Client System

[pysan3]

4. Window Management Server / Client System

In order to tackle this issue, I'd like to implement a window (buffer) manager, that manages the creation of windows to display neo-tree sources. Clients will borrow a window from the manager.
i.e. Source asks for an empty buffer id -> Source renders its content to that buffer (in the background) -> Asks the manager to render -> Manager (maybe creates and) switches window's current_buf to the source's buffer.

This hopefully will eliminate flickering when switching sources which is the core problem in many of the remaining issues.

• TODO: list related issues here.

7. Named Sessions

Related to 4. source may set a name of the current window. The same name could be referenced in a different tab to display the exact same buffer in multiple places.
Additionally we might be able to cache and restore the state of the buffer across different neovim instances (like which node is expanded as well).

[cseickel]

I think I already addressed the flickering issues and did add the concept of "acquiring" a window from a central authority that is able to reuse windows as needed without the flickering of recreating them:

neo-tree.nvim/lua/neo-tree/ui/renderer.lua

Line 948 in c2a9e81

M.acquire_window = function(state)

The issue you linked to is something else entirely. That involves re-designing the state management system to not be defined by location, which is your next point about named sessions:

Related to 4. source may set a name of the current window. The same name could be referenced in a different tab to display the exact same buffer in multiple places.

I think it is a great idea but it may create a lot of unexpected bugs so be prepared for a long haul on this one.

Additionally we might be able to cache and restore the state of the buffer across different neovim instances (like which node is expanded as well).

All of that is already in the state object, so there's nothing to do here except for saving the state object in a way that can be shared. If you just serialize it to disk in a temp file, you can not only share it across instances but also maintain your session across restarts.

[pysan3]

I think I already addressed the flickering issues and did add the concept of "acquiring" a window from a central authority that is able to reuse windows as needed without the flickering of recreating them:

neo-tree.nvim/lua/neo-tree/ui/renderer.lua

Line 948 in c2a9e81

M.acquire_window = function(state)

The issue you linked to is something else entirely. That involves re-designing the state management system to not be defined by location, which is your next point about named sessions:

I guess I'm not up to date with the codebase now. I'll look into it later.

Related to 4. source may set a name of the current window. The same name could be referenced in a different tab to display the exact same buffer in multiple places.

I think it is a great idea but it may create a lot of unexpected bugs so be prepared for a long haul on this one.

True. I numbered it to 7. so I'll work on it at last. (pathlib.nvim is 6).

Additionally we might be able to cache and restore the state of the buffer across different neovim instances (like which node is expanded as well).

All of that is already in the state object, so there's nothing to do here except for saving the state object in a way that can be shared. If you just serialize it to disk in a temp file, you can not only share it across instances but also maintain your session across restarts.

I think state has too many things involved that (de/)serializing it is very difficult. (ie I can't serialize sort_function), so I wanted to make some kind of a stripped down version of state that will be able to be saved to the disk. I dunno how :P

[cseickel]

I think state has too many things involved that (de/)serializing it is very difficult. (ie I can't serialize sort_function), so I wanted to make some kind of a stripped down version of state that will be able to be saved to the disk. I dunno how :P

That's true. I now realize that it was a mistake to combine config with runtime state the way tha I did. They should be clearly delineated, which would make this task much simpler. At this point, I would probably move all runtime state into a sub-table of state so that it can be easily serialized for this purpose. If I were starting fresh I might make the state be:

local state = {
  config = { renderers = {...}, commands = { ... }, ... },
  global_config = { default_source = "filesystem", window = { ... },
  runtime = { winid = 1, bufid = 23, explicitly_opened_folders = { ... } },
}

but it would way less of a breaking change if we left all of the config where it is and just segregate out the runtime config.