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.
- Update the provided `minimum_score` in `sorter::Option::new` to match
what was being used in `sort_strings`
- Use the `minimum_score` value instead of a hardcoded number
This seems like functionality that was either intended and not added, or
added and then part removed. Either way the performance impact is
minimal and it's a nice idea.
- For completeness, but also for additional performance when there are
extremely large numbers of results, use `par_sort_unstable_by()` for
sorting the results. For most sane result sets this will not represent
a significant speedup (for the Kubernetes benchmark it's around 1%)
but as the set to be sorted grows the impact would be larger.
- Use `into_par_iter()` before setting out to calculate scores and then
filter by them
This represents a more efficient parallelism approach, with no mutex
or global state at top level.
ivy_files(kubernetes) time: [4.5800 ms 4.6121 ms 4.6467 ms]
change: [-55.056% -54.570% -54.133%] (p = 0.00 < 0.05)
Performance has improved.
ivy_match(file.lua) time: [1.1514 µs 1.1599 µs 1.1694 µs]
change: [+0.4116% +2.0753% +3.6710%] (p = 0.01 < 0.05)
Change within noise threshold.
The relevant processes are so fast, mutexes and mutex locks are so
expensive, and iterators so efficient, that it's actually faster to run
single-threaded across all the data than to spin up a bunch of threads
and have them basically spinlock waiting for the global mutex involved
either directly or in a channel.
ivy_files(kubernetes) time: [10.209 ms 10.245 ms 10.286 ms]
change: [-36.781% -36.178% -35.601%] (p = 0.00 < 0.05)
Performance has improved.
ivy_match(file.lua) time: [1.1626 µs 1.1668 µs 1.1709 µs]
change: [+0.2131% +1.5409% +2.9109%] (p = 0.02 < 0.05)
Change within noise threshold.
- Use an async (i.e. unlimited buffer) MPSC channel instead of an
Arc<Mutex<Vec>> for storing the scored matches in Sorter
- Use Arc<Matcher> instead of Arc<Mutex<Matcher>> for the matcher, as
it's not mutated and appears to be threadsafe.
This cuts average iteration time (on the benchmarked machine) from
25.98ms to 16.08ms for the ivy_files benchmark.
Passes values by reference when sorting to reduce memory copying. The
main saving on this is preventing copying of the large vector of files
getting passed into the `sort` function and then copying each item in
the vector in the for. This results in about a 27% performance gain
reducing the full benchmark of the kubernetes benchmark by 7.89 sec
Before
| Name | Total | Average | Min | Max |
| ---------------------------- | ------------- | ------------- | ------------- | ------------- |
| ivy_match(file.lua) 1000000x | 02.351614 (s) | 00.000002 (s) | 00.000002 (s) | 00.000042 (s) |
| ivy_files(kubernetes) 100x | 32.704256 (s) | 00.327043 (s) | 00.289397 (s) | 00.344413 (s) |
After
| Name | Total | Average | Min | Max |
| ---------------------------- | ------------- | ------------- | ------------- | ------------- |
| ivy_match(file.lua) 1000000x | 02.353386 (s) | 00.000002 (s) | 00.000002 (s) | 00.000049 (s) |
| ivy_files(kubernetes) 100x | 24.809576 (s) | 00.248096 (s) | 00.203167 (s) | 00.270263 (s) |
Now you can use `before` `before_each` `after` and `after_each`. Each of
the hooks will run in the context of the test file.
`before` This will run once before all the tests
`before_each` This will run before each of the test functions
`after` Will run once after all the test functions
`after_each` Will run after each one of the test functions
Multiple functions can be defined for each hook by calling the
respective function again.
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.
