Allow the end user to use internal utils and libivy.

[arnevm123]

Problem to solve

I was playing around with the plugin and tried to make a recent files backend.
Some issues that I found while doing this were that I had to reimplement some basic functionality form the utils (file_action for this one).
I also did not have the ability to search, it would be handy to have access to the libivy API (eg. ivy_match).

Proposal

Exposing (part of) the utils and libivy API to the user.
I understand that this would mean that these need to be documented, so I see why this would be something to do with caution.

Further details

I played around with it locally, and I just exposed utils and libivy (same as run and register backend) then I could just create a backend file in my local config and require this file.
Then I can copy paste a backend from the source code to my local nvim config.

Then I can call ivy.register_backend(require("local.backends.ag")) after calling the setup function, and it works just like the internal backends.

I think exposing these API's will make it really easy for users to implement personal commands.
Eg. recent files is just 90% copy pasting of buffers and then just changing getting buffers to getting recent files.

A lot of functionality can easily be ported over from looking at Telescope (that's how I found the oldfiles)).

And then these user made commands can be kept in the wiki section.

Not sure what your thoughts on this would be.
If anything is not clear, feel free to ask 😄

[AdeAttwood]

This makes complete sense, it's actually where some of the backend ideas come from in the first place. I created a Taskfile runner with ivy with the run function. After that, I want a better abstraction around the run function. I think it's a good core abstraction, however not that nice to write easy to read backends.

https://github.com/AdeAttwood/Dotfiles/blob/4354948d8851cec3c57d332485e98f9238a0fe36/site-modules/core/files/vim/plugin/taskfile.lua#L12

Right now I feel this is blocked by some inconstancy in the public APIs. We have different functions exposed in the require('ivy') and vim.ivy, I think they should be the same thing. If we move over to using vim.keymap.set then we can pass in the lua function directly, then we will not need to expose the hole controller.

I think we can get away with this, what do you think

local controller = require "ivy.controller"
local libivy = require "ivy.libivy"
local utils = require "ivy.utils"
local register_backend = require "ivy.register_backend"

ivy.utils = utils

ivy.match = libivy.ivy_match

ivy.run = controller.run
ivy.register_backend = register_backend

Maybe we want to export each of the util function to give us more flexibility and prevent us from exposing random util functions publicly.

[arnevm123]

Yep, that was what I did locally (well I exposed the whole libivy library, but that's not needed I guess)!

[AdeAttwood]

@arnevm123 sorry about this, forgot to say this has been done in ded926a. There are on docs on it yet so will leave this open for a bit but, we can now create our own backends via a consistent API.