feature request: smart lazy-loading

[mrcjkb]

Hey 👋

I'd love to try out your plugin. I gave it a go, but noticed two things that keep me from using it at this time:

• It forces me to call a setup function for the plugin to be usable.
• Relies on lazy.nvim for lazy loading.

See also:

• https://github.com/nvim-neorocks/nvim-best-practices?tab=readme-ov-file#zap-initialization
• https://github.com/nvim-neorocks/nvim-best-practices?tab=readme-ov-file#sleeping_bed-lazy-loading

If you're open to it and you believe it's feasible, I'd be happy to open a PR 😄

[dmtrKovalenko]

Thanks for your input, and I would love to implement this. Though I think we have legitimate reason to do this because fff.nvim is required to run whole file system scan at setup, discover git repo and query statuses and so more.

In our case it would make more sense to run setup function at “VeryLazy” to have file index prepared by the time user opens picker.

But if you’d like to contribute the actual lazy loading I’d be happy to merge it

[mrcjkb]

Thanks for the quick response.

I suppose the indexing is started in the plugin script, via require('fff.main')?
lazy.nvim's VeryLazy event is just an autocommand that's scheduled after UIEnter.
This would be equivalent, but it works with all package managers:

if vim.g.fff_loaded then
  return
end
vim.g.fff_loaded = true

-- defer indexing until after UIEnter, so as to not block the UI.

local init = vim.schedule_wrap(function()
  if vim.v.exiting ~= vim.NIL then
     return
  end
  require('fff.main')
end)
 
if vim.v.vim_did_enter == 1 then
  init()
else
  vim.api.nvim_create_autocmd("UIEnter", {
    group = vim.api.nvim_create_augroup('fff.main', {}),
    once = true,
    nested = true,
    callback = init,
  })
end

I'll look into opening a PR soon then 😄

[dmtrKovalenko]

would it be possible to keep the setup Api avialable? I really like the way opts are passed via lazy than the way rustaceanvim is doing that for example

Thanks for your contribution!

[mrcjkb]

would it be possible to keep the setup Api avialable? I really like the way opts are passed via lazy than the way rustaceanvim is doing that for example

Thanks for your contribution!

Yes, I can keep the API. I would just suggest to separate configuration and initialization.
Here's an example in the rustowl plugin that supports both setup and vim.g configuration.
The reason I don't provide a setup API in rustaceanvim is because I don't want people cargo culting it but using it for both configuration and initialization.

[mrcjkb]

I just noticed the lazy.nvim readme example suggests:

  keys = {
    {
      "ff", -- try it if you didn't it is a banger keybinding for a picker
      function()
        require("fff").find_files() -- or find_in_git_root() if you only want git files
      end,
      desc = "Open file picker",
    },
  }

This example prevents setup from being called until the user types ff.
So indexing (which I assume is started in fuzzy.init_db and/or fuzzy.init_file_picker?) is deferred until then, too.

Is this intended? If that's the case, then I would implement it in such a way that initialization is deferred to when the respective Lua functions are called.

[dmtrKovalenko]

Yeah I think we should support both, I made the default example doing lazy loading on open but if someone works on a very large repo I think it make sense to do the setup on UiEnter

[mrcjkb]

Which would you prefer to be the default behaviour?

[dmtrKovalenko]

I don't know I like the way lazy nvim allows to configure it, while probably it makes more sense to run the sync in the background but for people who might want to rarely open fff should be banned should be able to lazy load the stuff and avoid running the watcher in the background

[dmtrKovalenko]

While thinking about this it probably makes sense to default to lazy load on first open because spawning a background thread is very implicit and most users better to learn about it and take action about loading us on UIEnter than us doing this without their consent

[mrcjkb]

In that case I would suggest something along the following:

• Introduce an internal idempotent ensure_initialized function that returns immediately if already initialized.
• Add a lazy_sync config option that defaults to true.
• In the plugin/ script, check if lazy_sync = false. If so, initialize on deferred UIEnter, otherwise do nothing.
• Call ensure_initialized at the API endpoints.