kyazdani42 / nvim-tree.lua

A file explorer tree for neovim written in lua

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[TRACKING] issue followup for refactoring, rewrites and features planned.

kyazdani42 opened this issue · comments

Hi everyone !
I'm currently doing small refactoring iterations of the plugin. Here is a list of the refactoring and features/rewrite i want to achieve in the next few months. Theses lists will be completed incrementally.

  • move library code into dedicated actions (ongoing, almost finished)
  • explorer rewrite, using watchers (followup -> multiple projects) (ongoing)

next steps:
simplify the grouping code and the filtering code
cleanup explorer/reload and DRY the code because there are lots of repetition
add watchers in folders and remove the vim events bindings for reloading the tree (as an option, it might be unstable)
make the explorer manage itself (move lib.Tree into explorer) -> feasible now
create a core module to manage the explorers and implement projects UI

  • view rewrite (buffer should be destroyed whenever the window is closed) (ongoing, missing small cleanup and api overview)
  • initialization rewrite (done)
  • decouple git module to update with an fs_watcher + rewrite it's exposed api. (check the cost of doing a pipeline application from state modification to rendering, such as explore->git->render)
  • renderer refactoring
  • move code from config to modules, and use setup for configuring icons and such (ongoing, almost done !)
  • Readme cleanup & improvements
  • Help cleanup & improvements

my humble advice: document your code + ordinary code comments

I was gonna raise an issue about hanging, but since the code is being refactored, I would just describe my issue here briefly.

It seems that nvimtree always read git info when refreshing the tree even with git.enable = false, which causes vim to hang a very long time or forever if I press R for a few times. Please make git an optional requirement, or better, make it stop hanging when reading git statuses.

Nice plugin, BTW.

Is this intended to be a in-place rewrite (i.e. users won't have to do anything, the code will be in the same repo and the plugin will be updated once the rewrite is done)?

@yifeikong are you sure ? All git calls are protected by a config check. The slowdown might com from the full tree refresh. With the new version it should dramatically reduce the refresh time because of the reload being scoped to a folder only.

@kirillbobyrev I'm not sure yet, and although i've started rewriting it, i'm a bit concerned about this rewrite taking too long. I have a 20% working version, but the main improvements i wanted to do are written already, so i might just port the code to the existing repository.

I'll keep you guys informed when i can, but i've been really tired lately because of work. I hope i'll be better after some holidays :)

@yifeikong are you sure ? All git calls are protected by a config check. The slowdown might com from the full tree refresh. With the new version it should dramatically reduce the refresh time because of the reload being scoped to a folder only.

@kirillbobyrev I'm not sure yet, and although i've started rewriting it, i'm a bit concerned about this rewrite taking too long. I have a 20% working version, but the main improvements i wanted to do are written already, so i might just port the code to the existing repository.

I'll keep you guys informed when i can, but i've been really tired lately because of work. I hope i'll be better after some holidays :)

Take your time. The current plugin works and does the job good enough.

No need to rush anything.

Thanks for your work.

Hey just want to come by and say thank you :) Nice plugin XD and please take your time XD

Eagerly awaiting! This plugin is already very cool, but a refactor will make it much better, thanks for the effort you are putting into this!

Just a tip from a bug a found: don't initialize configuration-dependent values in immutable variables like in the renderer.

These immutable values are set automatically when require("nvim-tree") is called and any configuration setup after that is ignored (like setting vim.g.* variables or even the actual setup call).

My use case for plugins is like this: I use pcall(require, ...) to check for a plugin's existence, fallback gracefully if it doesn't, otherwise I setup a bunch of other stuff, that may or may not depend on the plugin's own code, which I need to require to be available. So, require'ing a plugin shouldn't initialize immutable config values.

I'm not sure if I should open an issue for this since the rewrite is a good chance for a fix and fixing it in the current code base would require a big refactoring.

Also, from a programming point of view, this trend in lua plugins to think the common case is require("plugin").setup(...) is very wrong in my opinion. Importing libraries/modules, in general, should be an idempotent operation with very limited side effects (ideally none at all) and it should simply expose the library's API to the client.

commented

Awesome plugin!, If I can contribute to rewrite, reply me, I really want to help in this rewrite

@13k i realized this issue with global vim variables, that's why i started to work on the setup a while ago....

Also the setup thing is controversial for some people, but given how to plugin managers initialize the plugins, it actually makes a lot of sense and allows for a clean interface between the plugin developers and the users. It also enables the plugin being initialized lazily.
I agree their might be some other better way, but i didn't find one and i'm happy enough with those setup functions, and i think most people are. Sometimes you need to compromise a bit, specially regarding "conventions".

@lopi-py Any help is appreciated, i'll use this issue to track the ongoing refactoring that must be done in a week or two, i still have to maintain the issues and i have a lot of them unread, which takes quite a lot of time ^^

I love your plugin, so wanted to first of all say a big thanks and really appreciate your work. I hope the rewrite will come 💪

I was about to post a bug about how :bd with NvimTree showing, crashes entire nvim session. Dunno if there is a workaound or hotfix for this? Let me. know how/where i can find some logs or anythign to send you way.

Again, thanks a lot for this nvim plugin - its sooo cool i really like it! 🙏

@kraegpoeth which buffer do you delete ? It might be because of the auto_close option, set it to false in the setup might fix this.

ezoic increase your site revenue