forked from nvim-neo-tree/neo-tree.nvim
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Labels
enhancement
New feature or request
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Did you check 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
andstate
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.
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
The text was updated successfully, but these errors were encountered: