Provide file-picker navigation

[paholg]

We provide the following new keybindings while in a picker:

• C-e - Change picker root to one directory in, based on selection
• C-a - Change picker root to one directory out

These can be especially useful when combined with the command
file_picker_in_current_buffer_directory when navigating library
files.

That is, with this change the following flow is enabled:

1. Perform a goto_defition on a symbol defined in an external library.
2. Perform file_picker_in_current_buffer_directory, opening a picker
   in the external library.
3. Browse the external library with C-e and C-a, which is not
   possible without this change.

To accomplish this, we need access to a FilePickerConfig not just
when building the picker, but also later, so we add an associated
Item::Config type, which is simply () for everything except
PathBuf.

To make it easier to follow what is going on when navigating the
picker, we set the status bar to the picker's root directory on change.
If #8155 is merged, we can use that instead of changing the status bar.

[pickfire]

Where does these keys comes from? What's the prior art? Why l and o and not i and o or something else?

[paholg]

The prior art is emacs's helm-mode, which uses ctrl-l for a similar purpose, and I somewhat arbitrarily picked ctrl-o because it was nearby and not taken.

I would be happy to change these commands to something more intuitive. Do you think ctrl-o to "move out" and ctrl-i to "move in" would be the best?

[paholg]

Ah, we cannot use ctrl-i as the terminal sends that as tab, which is already bound.

Instead, I have opted for ctrl-e and ctrl-a as these already have meaning for going forward and backward, though I'm happy to change to something else.

[paholg]

I find this commit necessary for using helix, as there's no real way to navigate external libraries otherwise. I imagine others would find it useful as well, so would definitely appreciate a review.

[thomasaarholt]

I just tested this PR, and the functionality in it seems useful and works as advertised. It seems a little strange to navigate up and down directories while in a fuzzy file picker, but I think that is mainly due to it being a new concept to me.

I think that this functionality can happily coexist next to a file explorer ala #5768, that is, even if we had a file explorer in helix today, this PR would still be desirable.

[kirawi]

As I mentioned in Matrix, there was some talk a while ago about a basic file explorer:

A filepicker with depth 1 that shows directories and if you select a directory it changes directories to that picker. Add a key to go to go up a directory and make the location of the picker persist across closing/opening it and you got yourself so.ething close to a filetree without the need for a new ui component

It might be worth pivoting this PR towards something like that. But AFAIK this isn't a solid plan and you might want to wait for input from the maintainers on this.

[paholg]

That's interesting. Honestly, for me, this implementation is more useful; I still want to see everything when navigating up and down directories.

But if adding that functionality would help get this reviewed, I'd be happy to take a stab at it.

[pascalkuthe]

closing this one as stale. I don't think we will go forward with these bindings. They could be added as alternatives when we have remappable component key maps available but they may also be a bit niche for core and better suited for a scribtable config or a plugin. Thank you for contributing!