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:
This is so we don't need the GITHUB_TOKEN that can not be added in forgejo. I
am giving it a go and the `GITHUB_` prefix is reserved for secrets. There are
also issues with the action in a forgejo environment due to the API not
resolving to github.
This now should work on both platforms. So we can maintain github compatibility
for any pull requests that may come that way.
Test Plan:
Run the CI on github and forgejo, this will need to be a manual process to
validate this works.
Pull Request: #2
Summary:
Add windows support by checking `dll` instead of `so` or `dylib` on windows in `libivy.lua`
Author: @ShaolunWang
Imported From: https://github.com/AdeAttwood/ivy.nvim/pull/90
Test Plan: None provided provided by the author.
Differential Revision: https://ph.baln.co.uk/D7
Summary:
This is just a little script that will run a search and print out the timings
for each of the searches that ivy will preform.
For example running
```
nvim -l ./scripts/integration.lua /path/to/repo test 2> /dev/null
```
will output
```
t 0.074737
te 0.016494
tes 0.018898
test 0.017214
```
Test Plan:
Does not really require testing, this is a little helper script for
development. If it does not work on another machine then we can cross that
bridge when we come to it.
Reviewers: AdeAttwood
Reviewed By: AdeAttwood
Differential Revision: https://ph.baln.co.uk/D2
Summary:
Right now we are only running the tests on the nightly build of nvim. I would
like to try and maintain support for a few releases. One of the goals of this
project is to be stable. This means trying our best to maintain BC, for this I
have setup running the tests on older versions of nvim.
Right now we have:
- *nightly* Make sure we support the new releases, we can hopefully fix issues
before this gets releases.
- *stable* This is the main version we support
- *v0.9.5* Maintain the old stable, some OSs like Ubuntu lack behind, would be
nice to maintain that.
Test Plan:
CI, I have done a quick run before finalizing the change
Summary:
When you are in a project that has files the user cannot read, ivy's finder
will panic will a permission denied error. This can quite easily happen when
using docker on a project, it's quite common to mount a directory into a docker
container that is run as a different user I.E. MySQL. The other example I can
think of is when you are running tests in a container, the test output may be
owned by the containers' user.
When running ivy this is an example of the kind of panic you would get.
```
thread '<unnamed>' panicked at rust/finder.rs:34:41:
called `Result::unwrap()` on an `Err` value: WithPath {
path: "/tmp/workspace/mysql/#innodb_redo", err: Io(
Custom {
kind: PermissionDenied, error: Error {
depth: 2, inner: Io {
path: Some("/tmp/workspace/mysql/#innodb_redo"),
err: Os {
code: 13,
kind: PermissionDenied,
message: "Permission denied"
}
}
}
}
)
}
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: Rust panics must be rethrown
```
Ref: #83
Test Plan:
This has been tested locally, right now we don't have any unit tests for this.
We may setup some more testing in the future. This was a little hard to
recreate with out docker and mysql.
Summary:
Now we have a setup function with some config we better tell ppl about it. This
add the setup and config options into the readme.
It also replaces the "Command" with "Backends" to make it a little easier to
understand what needs to be configured. The backend concept has only just been
exposed publicly recently. It now makes since rename this section to line up
with the config.
Test Plan:
N / A
Summary:
When we were flushing out the docs, we found some inconsistency in the naming
of checkpoint and peek. They were referring to the same thing.
This removes the word 'peek' in favor of 'checkpoint'
Test Plan:
N / A
Summary:
Now we are running the tests in neovim we get some output printed to stderr.
This is not helpful in the test output, and obfuscate errors.
This throws any unneeded output to `/dev/null` so we can focus of the tests
that have failed. It also moves over to using TAP output for a more descriptive
out put in CI.
Test Plan:
CI, running the test will validate this
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:
This runs the new tests in our existing CI. We will remove the old tests later
when we know everything runs together so we know everything works.
Test Plan:
CI
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.
Instead of doing two passes of all candidates using map then a filter,
this uses `filter_map` so we are only doing one pass for the candidates.
This alone is quite a significant improvement of ~7%
Output of `./scripts/bench 0.x`
Benchmark 1: 0.x
Time (mean ± σ): 2.373 s ± 0.138 s [User: 10.617 s, System: 1.697 s]
Range (min … max): 2.124 s … 2.577 s 10 runs
Benchmark 2: HEAD
Time (mean ± σ): 2.206 s ± 0.133 s [User: 10.061 s, System: 1.811 s]
Range (min … max): 1.940 s … 2.433 s 10 runs
Summary
HEAD ran
1.08 ± 0.09 times faster than 0.x
-------------------------------------
The percentage difference is -7.00%
-------------------------------------
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%
-------------------------------------
This will quickly benchmark your current commit against a commit you
pass in. This will output the percentage difference so you can quickly
get an idea in the performance changes in your current work
once_cell has now been merged into rust core. This removes the
lazy_static dependency and migrates over to the built in `OnceLock`.
Its always good to remove dependencies where possible, this also give us
a preference for the built in `OnceLock`
```
Benchmark 1: chore: add benchmark for `set_items`
Time (mean ± σ): 6.327 s ± 0.199 s [User: 15.316 s, System: 1.323 s]
Range (min … max): 6.087 s … 6.712 s 10 runs
Benchmark 2: refactor: remove lazy_static
Time (mean ± σ): 6.171 s ± 0.251 s [User: 15.223 s, System: 1.382 s]
Range (min … max): 5.910 s … 6.776 s 10 runs
Summary
'refactor: remove lazy_static' ran
1.03 ± 0.05 times faster than 'chore: add benchmark for `set_items`'
```
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.
