Install docs on plugin load; partial matching for restrict_sources

[hc-nolan]

This plugin contains two commits that add minor enhancements. Both of these changes are non-breaking. If you'd like any alterations feel free to let me know.

Also, note that the majority of line changes to telescope.lua in #ca1e5d6 are just whitespace shenanigans. The lines that were actually changed were lines 75-97.

Install ensure_installed docs on plugin load

Previously, ensure_installed was only checked during the call to apidocs_open(). Now, if the user sets this value in the plugin config, the docs can be automatically installed as soon as the plugin loads. This is showcased in the added example to the README, which also sets lazy = false so that the plugin always loads as soon as Neovim is opened:

return {
  {
    -- "emmanueltouzery/apidocs.nvim",
    lazy = false,
    ...
    config = function()
      local opts = {
        ensure_installed = { "python~3.13", "lua~5.4", "rust", "ansible", "go" },
        ...
      }
      require("apidocs").setup(opts)
    end,
    ...
  }
}

Partial matching for restrict_sources

Added partial string matching for restrict_sources. Previously, the exact directory name had to be entered, e.g. python~3.13 rather than just python. With the new approach, if restrict_sources contains a value python, any directories starting with python will be considered valid. The motivation for this is demonstrated in the README example - we can now automatically restrict the sources for the language of the current file, and we won't have issues if the language docs have the version in their name:

...
keys = {
  {
    "<leader>aps",
	function()
	  local lang = vim.bo.filetype
	  require("apidocs").apidocs_search({ restrict_sources = { lang } })
	end,
	desc = "Apidocs: Search, restricted to current file language"			
  },
},
...

[emmanueltouzery]

thank you for the PR! it would probably have been better to have two PRs, one for each feature though.

When it comes to the partial matching, maybe it could be made more robust to avoid false positives (quite unlikely though), but also to make it more explicit. So if you ask for python, we would accept the plain python (so == "python"), or python~.* (so :match("^" .. source .. "~").

When it comes to ensure_installed, actually I quite like it as it is, that it installs on first use. I see that lazy=true or something could prevent the installation, but not everyone is using lazy (I'm not for instance). It seems to me installing on first use is better than installing at neovim startup in all cases, because when you set up your config on a new computer, imagine the mess if all plugins start aggressively setting themselves up at startup all at the same time. And especially apidocs, which can freeze neovim for multiple minutes.
So i thought it's actually quite elegant to do it only when you explicitely ask to use the plugin? I'm not sure when would one really prefer it at neovim startup?

[hc-nolan]

it would probably have been better to have two PRs, one for each feature though.

Sorry about that; I can refactor and open separate PRs if you like.

maybe it could be made more robust to avoid false positives

Sure, that'll be super easy to change

I see that lazy=true or something could prevent the installation, but not everyone is using lazy (I'm not for instance).

Good point - I can refactor it so that it must be explicitly enabled with a boolean field value like install_at_startup. This would keep the default behaviour the way you have it currently regardless of what package manager is being used.

I'm not sure when would one really prefer it at neovim startup?

I guess this is just a matter of personal preference. For me, the approach of doing the download and parsing when the plugin is called is counterintuitive, because if I'm calling :ApidocsSearch then I want to search immediately, and needing to wait potentially a long time for new languages to be downloaded and parsed severely disrupts the workflow. I would rather just get everything downloaded and parsed as soon as it's declared in ensure_installed, and then never have to worry about my flow being disrupted when I'm actually using the plugin.

However I will note that it is not my intention to modify the current behaviour, but rather just to give the user the option of doing it how they like.

[emmanueltouzery]

i wouldn't want too much code to be added to the plugin for this install_at_startup idea. maybe this would work, just export the function to install the sources. And then the user can call it in their setup if they like. This would probably mean almost zero change to the plugin (although i'm not sure from the top of my head right now), and would offer the feature.

at this point it's probably not worth splitting the PRs unless it's very easy for you. but modifying both features might require some history rewriting acrobatics for you now :)

[hc-nolan]

I like the idea of exporting the function for the user to call; I'll see about facilitating that.

And since these commits are rather simple it won't be too much trouble; I have already split out the partial matching. So, I'll close this and open a new PR with the partial matching and make a subsequent one after with the other changes.