Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DRAFT: pysan3 TODOs #1

Open
1 task done
pysan3 opened this issue Jan 30, 2024 · 0 comments
Open
1 task done

DRAFT: pysan3 TODOs #1

pysan3 opened this issue Jan 30, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@pysan3
Copy link
Owner

pysan3 commented Jan 30, 2024

Did you check the docs?

  • I have read all the docs.

Is your feature request related to a problem? Please describe.

Things I'd like to do to improve the plugin.
I haven't started anything yet!

1. Rich Type Annotations

I see some type annotations added to the codebase recently, which is amazing.

I'd like to scan thru the codebase to define the fields for the context and state variable, which is used and passed everywhere, and many fields are added along the way. (Use ---@class, ---@field.)
Also, add annotation and doc for the default.lua to give a better configuration experience. I see some complaints that neo-tree's config options are too complicated.

2. Add Type Check Action

Ref: mrcjkb/lua-typecheck-action#34

After 1. is done, we can check for type errors with GH actions for each PR, which makes it way easier to detect potential bugs.

3. Organize General APIs

Although neo-tree has a very extensible system with external sources, it is very unclear what the external modules should and shouldn't handle by themselves.
We should make a distinction between public and private API and we should add docs for at least the public facing functions.

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.

5. Cache System

The current implementation (eg filesystem) will gather file info after source.navigate and then render the whole content from top to bottom.
I want to experiment if using uv.new_fs_event and a coroutine system (eg nvim-nio) might make it possible to pre-calculate the file tree in the background and drastically improve the rendering speed after :Neotree foo bar is called.

6. Pathlib.nvim

I am currently experimenting with a new way to manage path object in lua with pathlib.nvim. I believe this library improves the overall performance regarding to path management, and should decrease the maintenance burden of dealing with path strings.
Neo-tree currently has not small amount of Windows path related issues, which should be fixed right away.

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).

Describe the solution you'd like.

N/A

Describe alternatives you've considered.

No response

Additional Context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant