File explorer and tree helper

[cossonleo]

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.

[cossonleo]

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 #2412

[cossonleo]

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 @

[cossonleo]

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

[gilice]

Can we get a status update on this?
Is it waiting for reviews, or is it not complete yet?

Would like to help out by starting to test this PR by daily driving with it (rebased onto master so that I can test if it works with other new features on master as well), but I'm having trouble rebasing it as the PR branch is a bit staled, and I'm not familiar with the Helix codebase enough to be able to resolve the conflicts.

Would be nice if the PR can be rebased. Thanks a lot! Sorry if this sounds pushy.
@xJonathanLEI do you have your tree-included branch up somewhere? I checked your fork but it doesn't seem to be there.

[archseer]

Have you read the thread? The PR needs to be rebased, PR reviewed and tested.

[jhonalino]

I've been using helix as my daily for the past couple months and super excited for this! thank you so much for implementing this!

[aguilera51284]

this is the change that is needed to use professionally, since in large projects there are thousands of folders, excited about this change

[well1791]

This line is already there

`G`                | Move to last item

better merge it with the other available option

Suggested change

	| `ge` | Move to last item |
	| `ge`, `G` | Move to last item |

[well1791]

a suggestion on usability, probably it would be good to include that the removal will prompt for confirmation

| `rf`                     | Remove the selected file with confirmation
| `rd`                     | Remove the selected dir with confirmation

I mean, probably in the future there would be an option to not require confirmation, maybe some rF and/or rD

[Diogenesoftoronto]

Looks very interesting can't wait to see this implemented.

[alphashuro]

Is there an option to pay a bounty to see this or a similar PR accomplishing it merged?

Although it's quite unfortunate that it hasn't been merged yet, we're also asking the author to just hand out their valuable time for free. Maybe we should go back to the basics and trade something of value in exchange for the value we're getting

[d4hines]

I've rebased this with master cossonfork#2

@cossonleo, would you update your branch?

[kirawi]

If the PR author is inactive, then you are free to continue in a separate PR.

[evertonse]

Guys, I, recently, forked helix and embedded @cossonleo tree-explorer code into the most recent helix master commit.
It's compiling and it’s working on my end.
Should I do something about this? I’ve never asked for pull request or merge request, but if anybody wants to try just clone and compile it normally from https://github.com/evertonse/helix-tree-explorer

[ayoub-benali]

then please open a pull request in helix, at least the feature could be tested again and the code reviewed

[wongjiahau]

This was the missing feature that was keeping me from switching to Helix, so thanks very much @cossonleo 🙌

The only behaviour missing for me is the equivalent of :NERDTreeFind in (neo)vim:

:NERDTreeFind [<path>]                                           *:NERDTreeFind*
    Without the optional argument, find and reveal the file for the active
    buffer in the NERDTree window.  With the <path> argument, find and
    reveal the specified path.

I personally think this would be a more useful behaviour for the E binding. In a large codebase recursively opening all directories in the explorer (i.e. the current behaviour of E) isn't really practical. Whereas being able to re-open the explorer focused on the current buffer is something I find much more useful (e.g. if I wanted to see adjacent files).

Thanks again, this is awesome 🙏

I implemented this feature in d9d4daa, the PR is #5768.

[workingj]

this PR could be closed like #5566 i think,
both are succeeded by #5768 File explorer and tree helper (v3)

[archseer]

Replaced by #5768