This is a basic example of a remappable command specific to a single
Component. It could be remapped like so:
```toml
[keys.buffer-picker]
C-d = "close_buffer_in_buffer_picker"
```
This has some rough edges:
* Can we namespace the commands so they don't all have to be very long
and specific about which component they work for?
* How can we make this work for generics?
* We can't define commands that operate on a `Picker<_>` for
example. This example only works because we're using a
`Picker<BufferMeta>`.
* For Pickers and Menus we could use a `Vec<Box<dyn Item>>` and drop
the generics but that would lose static dispatch.
* Could we separate the part that needs generics into a different
struct and have the functions operate on that?
Previously we only split key tries by editor Mode. This commit changes
that to allow other "domain"s like Component IDs. We'll use the
Component IDs later so that a Component like a Picker can look up
keybindings for itself.
The naming is a bit of a placeholder. The hashmap could just use
`&'static str` and we could add a From for Mode. But I'd like the key to
have some sort of formal name to it.
Call as bytes before slicing, that way you can take bytes that aren't
aligned to chars. Should technically also be slightly faster since you
don't have to check alignment...
Merges the code for the Picker and FilePicker into a single Picker that
can show a file preview if a preview callback is provided. This change
was mainly made to facilitate refactoring out a simple skeleton of a
picker that does not do any filtering to be reused in a normal Picker
and a DynamicPicker (see #5714; in particular [mikes-comment] and
[gokuls-comment]).
The crux of the issue is that a picker maintains a list of predefined
options (eg. list of files in the directory) and (re-)filters them every
time the picker prompt changes, while a dynamic picker (eg. interactive
global search, #4687) recalculates the full list of options on every
prompt change. Using a filtering picker to drive a dynamic picker hence
does duplicate work of filtering thousands of matches for no reason. It
could also cause problems like interfering with the regex pattern in the
global search.
I tried to directly extract a PickerBase to be reused in Picker and
FilePicker and DynamicPicker, but the problem is that DynamicPicker is
actually a DynamicFilePicker (i.e. it can preview file contents) which
means we would need PickerBase, Picker, FilePicker, DynamicPicker and
DynamicFilePicker and then another way of sharing the previewing code
between a FilePicker and a DynamicFilePicker. By merging Picker and
FilePicker into Picker, we only need PickerBase, Picker and
DynamicPicker.
[gokuls-comment]: https://github.com/helix-editor/helix/issues/5714#issuecomment-1410949578
[mikes-comment]: https://github.com/helix-editor/helix/issues/5714#issuecomment-1407451963
Resolves issue #6888 by adding a command to join all selections and yank
them to the specified register. The typed command takes an argument as
the separator to use when joining the selections.
* Fix next/prev tree-sitter inconsistency
Before there where different results going to next or previous due to
sorting not dealing with multiple captures that start/end at the same
pos. I chose to prefer longer matches.
* Revert unnecessary change
* runtime config made clearer
* following Unix FHS
* we probably want to install Helix as a regular user without sudo access
* suggestions adopted from @the-mikedavis
* attempted to synthesise comments given
* capitalisation of second header
* required changes hopefully made
* we should have a match now
* Linux windows dir match
