Summary:
Right now we have two ways to access the public api we have `require('ivy')`
and `vim.ivy. Each way has a different api that will cause some confusion.
Now both apis are the same so anyone that wants to integrate with ivy can do so
without having to figure out what one they need to use.
Test Plan:
The unit tests cover most of the work, I have also been using this locally for
quite some time now with now issues.
Summary:
Now when using ivy.nvim you will need to call the `setup` function. This will
need to register any backends you want to use. This is an example config, this
can be put into a plugin in `~/.config/nvim/plugin/ivy.lua` for example.
```lua
require('ivy').setup {
backends = {
"ivy.backends.buffers",
"ivy.backends.files",
},
}
```
If you are using Lazy you can use the `config` directly to call the setup
function.
```lua
return {
"AdeAttwood/ivy.nvim",
build = "cargo build --release",
config = {
backends = {
"ivy.backends.buffers",
"ivy.backends.files",
}
}
}
```
The `setup` function can only be called once, if its called a second time any
backends or config will not be used. The module does expose the
`register_backend` function, this can be used to load backends before or after
the setup function is called.
```lua
require('ivy').register_backend("ivy.backends.files")
```
As well as the `register_backend` the core `run`function is exposed. With this
exposed we should be able to build anything we want.
```lua
vim.ivy.run(
"Title",
function(input)
return {
{ content = "One" },
{ content = "Two" },
{ content = "Three" },
}
end,
function(result) vim.cmd("edit " .. result) end
)
```
Test Plan:
Not much to test in this one, it has been tested locally on my config that does
not use any plugin managers, also a sandbox Lazy env using `NVIM_APPNAME`
NVIM_APPNAME
Summary:
Split out the register backend function from being a private function. A
backend is a table that will define all of the attributes for a run function.
The attributes are as follows:
- **command** The name of the command that will be registered as a vim user command.
- **items** The callback function that will be passed to the run function that will gather the items for selection
- **callback** The callback function run when an item is selected
The following are optional:
- **keymap** The string passed to `nvim_set_keymap`, this will always be registered in normal mode
- **description** The text description that will be used in the user command
- **name** The name of the backend, this will fallback to the command if its not set
It will also allow to register a backend in a couple of different ways:
- With a backend module table
- With a backend module name
- With a backend module name and override options
This will look for for a lua module `ivy.backends.files`. The module will be
required and registered as a backend.
```lua
register_backend "ivy.backends.files"
```
This will do the same with the module string however, before the backend is
registered the keymap will be overridden
```lua
register_backend({ "ivy.backends.file", { keymap = "<C-p>" } })
```
Test Plan:
CI / Manual testing locally
Now when you paste and you are in an ivy buffer the paste will be added
to the prompt not into the completion window. You can use your usual
paste key binding I.E. <SHIFT>+<INSERT> <CTRL>+<SHIFT>+<V>
Ref: #11
`rg` will now be used over `ag` if it is available. This is because `rg`
is a faster alternative reduces lag when searching larger codebases.
`ag` is also now conditionally loaded if the command is available.
We now have a concept of a 'backend' this is the same as the current
sorters and finders but with added info like the keymap so they can all
be registered as one. This will allow us to split our backends into
modues so we can better maintain then.
The API for `window.set_items` took to many variable types. It would
take a table in multiple different formats and a string. Now it will
only take a table in a single format and a string. It will convert the
string into the table format by splitting it on new lines.
The table format is an array of tables that must have a `content` key
that will be the text that is displayed in the completion window. The
table can have any other data that is ignored.
```lua
local items = {
{ content = "Item one" },
{ content = "Item two" }
}
```
The `set_items` function will only display the `content` key in the
completion window, it will not do any sorting or filtering, that must be
done before passing the data to the `set_items` function.
