helix
helix copied to clipboard
Expand the picker UI
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:
- Move the picker prompt to the bottom, reusing the original prompt and also display the picker name to the left.
- Also move the match counter to the right of the original prompt.
- Move the list to the left of the window, took 1/3 or 1/4 space of the window.
- 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.
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?
#361 possibly relevant.
#1066 relevant.
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
)
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
#9647 relevant