Summary:
Now the users configuration and the default configuration is separated. This
will make it easier to setup ivy with some defaults. Right now we only have the
backends configurable however, it looks like we will be making other components
of ivy configurable.
To use this you can now call `ivy.setup` with no parameters and you will get
the default config. You can also call it with a partial config and if the
option is not found in the users config it will fallback to the users config
value.
Test Plan:
Manual testing and with unit tests in CI
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
Summary:
Right now we are using a custom test runner. This move the suite over to
busted, this will make things much more maintainable going forward. The two
main reasons for moving are.
1) The custom runner as some bugs, when running assertions we are not getting
the correct results.
2) All of the busted mocking features. We can use spy and mock, this will allow
us to remove the nvim_mock. This file is not amazing and confuses the lsp
often.
Test Plan:
CI
Summary:
Fixes an issue where you could not open files that were already open with ivy.
If the file path contains a square brackets and that file is already loaded
into a buffer, ivy will throw an error when trying to open it via "files" or
"buffers".
This is an issue with the file escaping before we try and cal `buffer` passing
in the file path to go to the buffer rather than open a new buffer.
This is common with JS frameworks like next js for parameters in file based
routing.
Test Plan:
Test have been added for this change. I have also added tests for the dollar
that was previously handled.
Move some of the iteration in to loa and access the values by the index
to reduce the number of loops we need todo to get items into teh results
buffer.
Currently the flow is:
1) Filter and sort the candidates in rust
2) Convert to a string and pass to lua
3) Split the string and add them as lines in a buffer in lua
Now the flow is:
1) Filter and sort the candidates in rust
2) Loop over an iterator in lua
3) Pass each item to lua as a pointer by the index
This removes quite a bit of the work that is needed to get the data into
lua as a table. We are first removing the loop that will join the
results vector into one string. Then we will remove the copy of this
string into lua. We will then finally remove the loop to split the
string and create a table from it in lua. All of this ends up in a 12%
speed up.
Output for `./scripts/bench 0.x`
Benchmark 1: HEAD
Time (mean ± σ): 2.667 s ± 0.065 s [User: 8.537 s, System: 1.420 s]
Range (min … max): 2.588 s … 2.767 s 10 runs
Benchmark 2: 0.x
Time (mean ± σ): 2.337 s ± 0.150 s [User: 9.564 s, System: 1.648 s]
Range (min … max): 2.161 s … 2.529 s 10 runs
Summary
HEAD ran
1.14 ± 0.08 times faster than 0.x
-------------------------------------
The percentage difference is -12.00%
-------------------------------------
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
Now we are useing the package.searchpath to find the libivyrs.so or
libivyrs.dylib. This is so it will load the correct library or the OS
you are on. This fixes the issues with loading the library on macOS.
Ref: #57
`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.
Now when trying to open files and buffers it will use the `buffer`
command when there is an existing buffer with the same name. This will
allow us to open non file buffers like terminals and log buffers.
By using the `bufnr` function to get the existing buffers, it will also
work for buffers that have been renamed with `title` command
Ref: #31
When reading the output of a command we are now reading the stream line
by line and building the table of results. This will save us a loop of
the results later, if we returned a string we need to split the string
before adding each line to the completion buffer because nvim only
supports replacing one line at a time.
This makes the terminal go really funkie and sometimes crash when
printing the error messages to the current process stdout where nvim is
running.
Now the error output is sent to the `popen` output and displayed in the
ivy completion buffer without messing with the current process io.
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.
Now when you delete a word in a promp it will work more like how it
works in bash. If the text dose not end in a letter then the last word
and all of the tailing special characters will be deleted. If the text
dose end in a letter then only the last word will be deleted leaving the
special characters that are before the last word.
Examples:
| Before | After |
| -------------------| ----------- |
| `some word` | `some ` |
| `some word` | `some ` |
| `some word ` | `some ` |
This was causing an issue an invalid regex. Now we are escapeing the
text to make it a valid regex.
There is also a small improvement where we no longer try and highlight
matched words if the "text" is empty.
Ref: #26
Now you can open the currently selected item in a vertical split or a
horizontal split. The completion callback must support the current
actions.
There is also a bit of testing in here. The vim mock has been refactored
and split out so we can use it multiple tests.
When you complete a completion the completion window is no longer
activated after the callback is run. This was causing issues with the
incorrect window being active after the completion.
This will lead the way for more actions other then edit, that will be
comming soon.
Fixes-issue: #8
This adds dot files into the finder. We are adding the overrides to the
`ignore` package, that can be used later to add custom ignore
directories that can be passed in as settings.
We are also adding a new `ivy_cwd` function to libivy to get the current
directory due to the limitations of lua.
Fixes-issue: #16
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.
Now the prompt will act like the default bash readline with emacs key
bindings, clear and delete word.
You can now also move left and right in the prompt to insert chars in
the middle of the prompt rather than having to delete your search term
and start again.
This will allow you to get the buffer the user was on when they invoked
an ivy command. This buffer is called the `origin` and you can access it
with `vim.ivy.origin()`.
Large projects can take a long time for the initial scan. This adds some
loading text until the initial selection has completed.
This will also now schedule the work to collect and sort the candidates
to ensure the UI is rendered before with work begins and creates a
hanging user experience.
