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

[kyazdani42]

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.

• initialization rewrite
• renderer refactoring
• view rewrite (buffer should be destroyed whenever the window is closed)
• move code from config to modules, and use setup for configuring icons and such (Chore/remove remaining globals #1281)
• explorer watchers (feat(explorer): add experimental watchers #1304)
• watch git changes with watcher (feat(explorer): add experimental watchers #1304
• move library code into dedicated actions (ongoing, almost finished)
• per buffer explorer (multiple states)
• Readme cleanup & improvements (docs: lighten up readme and rework docs #1327)
• Help cleanup & improvements (docs: lighten up readme and rework docs #1327)
• refactor and tidy action mappings
• remove filesystem_watchers.enable and associated codepaths

[perkfly]

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.

[kirillbobyrev]

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

[kyazdani42]

@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 :)

[vuki656]

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

[zhongjis]

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

[SystematicError]

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!

[13k]

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.

[lopi-py]

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

[kyazdani42]

@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 ^^

[kraegpoeth]

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! 🙏

[kyazdani42]

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

[alex-courtis]

• Help cleanup & improvements (ongoing, format has been revamped)

@kyazdani42 what further changes are you looking for? #1327 looks pretty good ;)

[kyazdani42]

indeed, i've forgot to update this one :)

[alex-courtis]

Last task tracked at #457 , closing.