cooldown before repopulating the cache

[teto]

seems like rocks.nvim fetches several manifests on each startup. Now I am sometimes on a laptop with limited battery/connectivity and I think it's too much. Even on desktop.

There is a related setting: {lazy?} (boolean) Whether to query luarocks.org lazily. but I think it might be worth introducing some complexity to avoid the current dilemna between "wasteful" or "too late".

One proposition is to rename the vague lazy setting to something more precise, e.g., plugin_listing_cache_strategy and accept a string instead of a boolean (or enum or integer) to be able to:

• disable it ? not sure why someone would want that, to reduce the risks of non-significant failures maybe. like in Luarocks fails to resolve manifest #329
• keep the "lazy" (maybe rename it to "on-demand" ?)
• "on-startup" (the current lazy=false)
• some way to set a timeout after which the cache should be asked again.

I also wondered if there was already a command to refresh the cache ? Maybe it's not important as it's just used for autocompletion and we can try installing a plugin not present in the cached manifest ?

[mrcjkb]

some way to set a timeout after which the cache should be asked again.

We could do what rocks does, which is:

• store the cached manifest locally
• query luarocks.org for the date the manifest was last modified with a HEAD request
• Compare timestamps and update as needed.

But this should be implemented in luarocks, not rocks.nvim.