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

Lazy init hindered? #415

Closed
ttytm opened this issue Apr 1, 2023 · 8 comments
Closed

Lazy init hindered? #415

ttytm opened this issue Apr 1, 2023 · 8 comments

Comments

@ttytm
Copy link
Contributor

ttytm commented Apr 1, 2023

Doesn't the current solution of calling the setup if the user didn't already initiated the plugin make it hardly possible to lazy load the plugin?

Why not go the common way to require the user to call setup() for a plugin to be initiated.

@Iron-E
Copy link
Collaborator

Iron-E commented Apr 1, 2023

This will be how it is done in v2; it has to be done this way to preserve backwards compatibility with earlier versions of this plugin. If you want to see how I get around it, see my config (I think packer can do it too with opt = true)

@Iron-E
Copy link
Collaborator

Iron-E commented Apr 1, 2023

See #394

@Iron-E Iron-E closed this as not planned Won't fix, can't repro, duplicate, stale Apr 1, 2023
@ttytm
Copy link
Contributor Author

ttytm commented Apr 2, 2023

Thanks for the info I had check this issue. It wasn't clear from it that calling setup will be required and auto setup will be removed.

@Iron-E
Copy link
Collaborator

Iron-E commented Apr 2, 2023

Thanks for the info I had check this issue. It wasn't clear from it that calling setup will be required and auto setup will be removed.

I'll update the text to be more clear

@ttytm
Copy link
Contributor Author

ttytm commented Apr 2, 2023

And thanks alot for the share of the code! Gave me the missing hint to make it work for the way my config is organized. The tabline was still flashing when entering on a dashboard with my attempts before, despite the showtabline setting 🙏.

@romgrk
Copy link
Owner

romgrk commented Apr 2, 2023

Why not go the common way to require the user to call setup() for a plugin to be initiated.

I actually don't like forcing users to call setup. It's bad UX, this plugin should work with as less hassle as possible for the user. They've already installed us in their config, why wouldn't they want to enable us? Package managers already have the logic to enable on command, I'd leave the problem to them. Also we're a bufferline plugin, we kinda need to be displayed asap, lazy loading doesn't make much sense for us.

@ttytm
Copy link
Contributor Author

ttytm commented Apr 2, 2023

I can only speak for my config. On a dashboard buffer I hide the bufferline. And when I launch a neovim instance (not on netrw) it starts on a dashboard, which is a bit troublesome atm with barbar.

With lazy.nvim calling the default setup() is as easy as adding config = true next to the repo. I prefer the convention not having setup() called for me and consider it better UX(at least for neovim users :P) to leave that choice to them.

@Iron-E
Copy link
Collaborator

Iron-E commented Apr 2, 2023

I also delay loading, until the second buflisted buffer opens, which sometimes doesn't happen for short editing sessions. Calling setup twice can make init take longer too.

If you'd prefer to keep it though, I can leave it unticked on the breaking change todo list. I'm alright with that too, it has it's upsides as well

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

No branches or pull requests

3 participants