Expand the picker UI

[NNBnh]

Moved from #1075, recap:

The picker is contained inside a box in the center of the window which block the almost whole view of the buffer in the back and also make the preview a bit small. We should expand the picker to the whole window, not just the file picker but also the other picker as well:

from this:

to this:

> dir/1.py     ┃ 1 │ print("Hello, World!")█
  dir/2.py     ┃ 2 │
  README.md    ┃ 3 │
               ┃ 4 │
               ┃ 5 │
               ┃ 6 │
               ┃ 7 │
               ┃ 8 │
░ NOR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1:23 ░
file picker:▁                               [3/3]

by:

1. Move the picker prompt to the bottom, reusing the original prompt and also display the picker name to the left.
2. Also move the match counter to the right of the original prompt.
3. Move the list to the left of the window, took 1/3 or 1/4 space of the window.
4. Move the whole preview to the remains space (we could add the line number to the preview too).

Navigate the picker should be the same (using UP, DOWN and ENTER).

=== Read more about tree widget idea ===

I has suggested to follow Sudormrfbin's idea:

It would be better to have a tree widget component which can properly handle the structure and associated keybinds, and plus it can be reused for a file tree (#200).

  ./           ┃ 1 │ print("Hello, World!")█
  ├╴foo/       ┃ 2 │
> │ ├╴1.py     ┃ 3 │
  │ └╴2.py     ┃ 4 │
  ├╴bar/       ┃ 5 │
  └╴README.md  ┃ 6 │
               ┃ 7 │
               ┃ 8 │
░ NOR ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1:23 ░
file picker:▁                               [3/3]

Navigate the picker should be the same (using UP, DOWN and ENTER), if the pointer focus on a directory (e.g: dir/) user can press ENTER to expand/fold it back. The user could keep the picker on the screen all the time, this should close #200.

But as Archseer said:

We have to track multiple tree levels and there's different sets of behavior depending on if you're expanding a directory or opening a file.

I'd like to keep the default interface simple and clutter free and discourage using a file tree; helix is not vscode and it's best to pair it with a terminal file manager like nnn if a file tree hierarchy is desired.

Therefore the tree widget system will be an idea for future plugin.

[dannasessha]

I really like the idea of having a clear, navigable, sortable, configurable and robust file picker.

The preview window (though resizing sounds like a good idea) with syntax highlighting is so killer, it calls out to me to be more useful, like being able to confidently navigate around a project or codebase, or indeed, any group of files I might want to edit.

The closer helix comes to this, the less a user would have to modify the core client (perhaps with a plugin) to obtain this potentially useful functionality. I also don't see a downside: I imagine a typical user won't find a more robust filepicker troublesome. However, I understand the desire to keep the default interface simple, as is made clear in the quote from Archseer above.

Is there any aspect to the group of goals I mentioned above that are desirable, and could be useful to guide further development of the file picker?

[dannasessha]

#361 possibly relevant.

[dannasessha]

#1066 relevant.

[adsick]

sounds good to me too, except for I'd also like to be able to navigate files using hjkl (and search them simply by forward slash)

[glyh]

I think we'd better have different styles for pickers. e.g. Sublime's Ctrl+p, the original one and quickfix list. All of them are pickers, but just have different ways to render. We may refer to Telescope.nvim

[woojiq]

#9647 relevant