You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😄
The text was updated successfully, but these errors were encountered:
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.
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
@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.
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 😄
The text was updated successfully, but these errors were encountered: