File explorer and tree helper

[cdacheng]

Add a explorer wdiget that display file under the current dir with tree style or list style. Add two shortcuts, Ctrl-e and Ctrl-E to toggle file explorer. features [ctrl]-jk/tab/arrow keys to switch selected item f key to fitler items b to back to parent dir z to fold current level items ? / keys to search items rd/rf to delete files/dirs but you must type YES to confirm. mf/md to create file/dir

There are four explore style: embed + tree:

embed + list:

overlay + tree:

overlay + list:

[archseer]

This looks great!

Could you render the tree with ASCII like this:

exa --tree --level=2 rust/rust-ansi-parse
rust/rust-ansi-parse
├── bin
│  └── parse-ansi-codes.rs
├── Cargo.lock
├── Cargo.toml
├── README.md
├── src
│  ├── cursor.rs
│  ├── lib.rs
│  └── style.rs
├── target
│  └── debug
└── test

Could we also make the item in the explorer generic via an interface or something? I wanted to use the same component to display a variable tree in the debugger (for example the "Local" pane here: https://emacs-lsp.github.io/dap-mode/screenshots/Swift.png or her https://code.visualstudio.com/assets/docs/editor/debugging/debug-session.png)

[Relwi]

I have a question for my knowledge, I know nothing about rust or how works helix, but why implement this feature into helix instead a plugin like does vim or neovim?

[archseer]

We currently don't have a plugin system available yet.

[NNBnh]

This maybe could close #1163

[matoous]

Could we also make the item in the explorer generic via an interface or something?

Could be used also for LSP document symbols. And I also liked the tree-like view of workspace diagnostics in nvim/trouble https://github.com/folke/trouble.nvim (before I fully switched to helix).

[pickfire]

I wanted to do something like this later on like doom emacs space space so the feature might intersect with this a bit (but didn't work on it yet). More like the list view you have shown, but with a design like our current file picker picker without a separate set of keys, just search and press, maybe you can give that a try and see.

EDIT: I guess I will push that ahead of time, maybe I will try to get it done by this weekend so no more procrastinating for me, then we can compare.

[cherryramatisdev]

I'm really excited for this feature to come out 😄

[Guillaume-Savaton-ESEO]

I have just tried it and it works very well. These are the only problems that I've had so far:

• The tree view does not support the mouse or the arrow keys: you need to use J and K to move down or up.
• With the "onelight" theme, the selected entry in the tree view has black text on a black background.
• The tree view pane hides the gutter that contains the error markers.

[pickfire]

One issue with this design is that it does not interact with last picker which user can then use space ', and even if it does, the keys are too different to group it with other pickers.

[sudormrfbin]

Personally I think having 4 different ways of showing the file tree is a bit too much (at least to be included by default), and that we should stick with one view that is the most useful (we will also end up with less code to maintain). I would recommend the overlayed tree version over the others since:

1. It's obvious the file explorer has focus since it takes up the whole screen.
2. More space for file preview.
3. Terminal file managers usually have the list view (the only one with a tree view by default that I can think of is broot), so we could offer the alternative within the editor.
4. I would consider a tree view to be more useful in a programming context than a directory-by-directory listing.

Also I feel unsure about having potentially destructive commands like renaming and deleting files included with the file tree, especially since they're bound to two character keys which are easy to type accidentally.

[cdacheng]

This looks great!

Could you render the tree with ASCII like this:

exa --tree --level=2 rust/rust-ansi-parse
rust/rust-ansi-parse
├── bin
│  └── parse-ansi-codes.rs
├── Cargo.lock
├── Cargo.toml
├── README.md
├── src
│  ├── cursor.rs
│  ├── lib.rs
│  └── style.rs
├── target
│  └── debug
└── test

Could we also make the item in the explorer generic via an interface or something? I wanted to use the same component to display a variable tree in the debugger (for example the "Local" pane here: https://emacs-lsp.github.io/dap-mode/screenshots/Swift.png or her https://code.visualstudio.com/assets/docs/editor/debugging/debug-session.png)

I'll have a try, but maybe need a few day.

[pickfire]

Sorry that I didn't do this earlier but here is a draft https://github.com/helix-editor/helix/pull/2412

[cdacheng]

I have just tried it and it works very well. These are the only problems that I've had so far:

* The tree view does not support the mouse or the arrow keys: you need to use J and K to move down or up.

* With the "onelight" theme, the selected entry in the tree view has black text on a black background.

* The tree view pane hides the gutter that contains the error markers.

I have added arrow keys support and hides the gutter also is fixed. I only custom solarized light theme, other themes will be fixed when I'm free @

[cdacheng]

This looks great!

Could you render the tree with ASCII like this:

exa --tree --level=2 rust/rust-ansi-parse
rust/rust-ansi-parse
├── bin
│  └── parse-ansi-codes.rs
├── Cargo.lock
├── Cargo.toml
├── README.md
├── src
│  ├── cursor.rs
│  ├── lib.rs
│  └── style.rs
├── target
│  └── debug
└── test

Could we also make the item in the explorer generic via an interface or something? I wanted to use the same component to display a variable tree in the debugger (for example the "Local" pane here: https://emacs-lsp.github.io/dap-mode/screenshots/Swift.png or her https://code.visualstudio.com/assets/docs/editor/debugging/debug-session.png)

I have optimized render and extracted the tree helper code in helix-term/src/ui/tree.rs and it's alreay for review. @archseer

[cdacheng]

I wanted to do something like this later on like doom emacs space space so the feature might intersect with this a bit (but didn't work on it yet). More like the list view you have shown, but with a design like our current file picker picker without a separate set of keys, just search and press, maybe you can give that a try and see.

EDIT: I guess I will push that ahead of time, maybe I will try to get it done by this weekend so no more procrastinating for me, then we can compare.

I've never used Emacs. I have added filter to explorer. Is it similar to what you said?

[cdacheng]

Personally I think having 4 different ways of showing the file tree is a bit too much (at least to be included by default), and that we should stick with one view that is the most useful (we will also end up with less code to maintain). I would recommend the overlayed tree version over the others since:

1. It's obvious the file explorer has focus since it takes up the whole screen.

2. More space for file preview.

3. Terminal file managers usually have the list view (the only one with a tree view by default that I can think of is broot), so we could offer the alternative within the editor.

4. I would consider a tree view to be more useful in a programming context than a directory-by-directory listing.

Also I feel unsure about having potentially destructive commands like renaming and deleting files included with the file tree, especially since they're bound to two character keys which are easy to type accidentally.

There should be no more than 30 extra lines of code to support for 4 ways of showing the file tree. I has potentially delete files/dir commands with rd/rf keys but you must type YES to confirm.

[pickfire]

I've never used Emacs. I have added filter to explorer. Is it similar to what you said?

No, I didn't try but I believe the idea is different, the one I suggested is more similar to file picker. Also, the find file in doom emacs is probably slightly different from the one in emacs, a bit tweaked I would say. The benefit is that you can move between files and directory quickly.

• as soon as you type, you started searching
• when you press enter on a file, you open the file
• when you typed something but the file does not exist, when you type enter, you create the file
• when you press enter on a directory, you open the directory (and start searching again)
• when you press backspace, you go one directory above

But I believe the one you suggested is more of control based, where you used a totally separated set of controls, that do provide more options and more flexible, but usually it's not needed I think, nice to have but I usually don't go learn how to use a file tree because it have a totally separate set of keys and I keep forgetting them since I rarely use it.

[pickfire]

You type <Tab> or directly instead of enter. -- continuing from find file pull request

That's why I don't do file tree, it's not straightforward to use, at least I can't just press keys and it works without reading the docs or remembering it, each file tree explorer, (ranger, hunter, vim netex, ...) they all have very different keys, and I don't see any one that I can just use without thinking much, maybe hunter is on the easy side for me.

I think we need the keys to be reviewed and done so that users are able to use it without reading at the docs or checking issues before we merge.

[andreytkachenko]

Please add an option to disable previewer window

[andreytkachenko]

No mouse interaction:

• focus loose on mouse click outside
• select folder/file
• expand/collapse
• scroll long list up/down

[andreytkachenko]

Consider add file type icons before names

[the-mikedavis]

Filetype icons are not a good fit for a core feature because they need a patched font. https://github.com/helix-editor/helix/pull/2211#issuecomment-1106015472

[heliostatic]

I love this PR -- is there anything else that would be useful from a testing or feedback perspective?

[Termina94]

I love this, thought I'd prefer the sidebar but the overlay is actually really nice.

It seems strange at first getting use to an almost disposable, bring it up and then close it, kind of usage but it works quite well

I have a couple of notes/questions:

1. I couldn't find a way of clearing the filter other than closing and opening a new instance, is that the expected usage?
2. When performing a search, I couldn't find a way of getting to the next file without having to press enter after search (opening the first files match) and then re-opening the explorer and cycling with n. Am I missing something?

Minor issues as they can be avoided by closing the explorer after use and using filter instead of search but all in all, a great addition!

[pickfire]

Going back to keys, without looking more than space e to start file explorer (and not using other interactive tree explorer)

• l unexpectedly scroll right over the left tree, it surprised me quite a bit, not sure what I expected but not this
• I went up one directory with <enter> on .. and now I am stuck with opening the parent directory every time I do space e
• I want to find helix among hundreds of directory within rust directory, I did / and it found nothing because it was searching the other directory, not the parent directory
• I give up and type gg (not because I want to go to the top but because good game), then I try searching again with /, to my surprise it found helix now, maybe because I started searching from parent directory? So I guess it search one layer
• I tried < >, did not work, H L, did not work, J K, did not work, enter ctrl-enter alt-enter shift-enter ctrl-shift-enter space I can't get into the directory the same way it worked for .., no idea why
• I guess I am really stuck with the parent directory being the default when I use space e, at least it can go into the file with extra layers I don't want to see (parent directory with all the extra files)
• tab alt-tab surprisingly works as up and down, I feel like that key is kinda wasted doing that

Maybe I should go read instructions next time, but at least still want to keep fresh and see how this goes without reading instructions.

[johalun]

Hey! Thanks for creating this! One of the few things that's still keeping me using Emacs. How do I test this? ~~I checked out the PR as a branch and built hx from that but I can't figure out how to open the file explorer... Ctrl-[e,E] does nothing.~~

Edit: Never mind I got it working. Redid the process and now space+e will open as overlay. How do I instead open it as a window on the left side?

[johalun]

Ok, I have been trying this for a bit now and it's awesome! I like how easy it is to switch to and from the embedded tree explorer. Hope to see this merged soon! My wish list for nice to have future features is

• Key to expand all folders under current folder 1 level. For example 'x'.
• Same as above but recursive expansion, for example 'X'.
• Remember what folders are expanded so they open up expanded if a higher lever folder is collapsed and expanded (even across hx restart).
• Filter includes files currently hidden due to folder being collapsed.
• Config option to launch helix with tree explorer open.
• Indicator for unsaved files, possibly git status indicator.

I don't know why but I feel like TAB should expand. Must be some software I used prior to this...

[Trivernis]

I've noticed some things that I'd like to be added/changed:

1. The currently opened file should be highlighted in embedded mode. Currently the entry that was selected last is highlighted.
2. Scrolling with page up/down
3. Maybe bind expanding/collapsing of folders to since is already used for selecting entries and space seems the most intuitive to me.

[codri]

Have been playing with the pull request above. Pulled the latest changes into it and did some mods.

Issues(or at least things that I consider issues) with the current version:

1. I haven't seen a way for the explorer to automatically show the file that was opened via fuzzy search
2. When changing the working folder via :cd command the explorer doesn't display the new folder
3. There doesn't seem to be a way to highlight the current line, something like cursorline
4. The toggle shortcut + e doesn't work on the embedded version
5. Cannot create/update/delete/move files from the explorer
6. Floating window that shows the contents of the folder before opening, is a bit intrusive

Issues with my modifications

1. Hardcoded icons: these should probably be moved into the theme
2. Hardcoded colors: also moved into the theme
3. Folder icons doesn't change for the opened folders
4. There is no way to configure the visibility of the icons(don't show them if not wanted)
5. Doesn't have arrows for opened and closed folders
6. Messy code

I'm planning to fix these issues. But this is more a comment to show what's possible with this functionality.

In general helix could benefit from a tighter integration with nerdfonts. For example showing icons in fuzzy search windows, like symbol navigation and LSP windows. Of course making it optional when the font doesn't support additional glyphs.

[lazytanuki]

1. Hardcoded icons: these should probably be moved into the theme

2. Hardcoded colors: also moved into the theme

3. Folder icons doesn't change for the opened folders

4. There is no way to configure the visibility of the icons(don't show them if not wanted)

5. Doesn't have arrows for opened and closed folders

6. Messy code

I actually opened a proposal PR for this (#2869). Basically, the idea is to have a proper and sane optional icon support that will be available throughout the whole editor. While this looks great, I think we should first wait for this PR to get merged before adding in icons, so that we can make it not only about the file explorer.