File explorer and tree helper (v3)

[wongjiahau]

This is the successor of #2377 and #5566, which implemented focus current file (as per #2377 (comment)).

480p.mov

[clo4]

This is great! I have some feedback on it, just as a user, not maintainer of the project. :)

• explorer feels like a strange name for it. IMO a better name would be file-tree since that's what it is. We already have a file-picker after all :^)

• I like that it can be floating or docked to the left!

  • Having an option to dock on the right, instead of just the left, would be excellent
  • My gut says that this may be easier for people who's culture uses RTL as the normal script direction, and there are also arguments to be made for ergonomics too because it doesn't move your text around when toggling.

• Calling the positions "embed" and "overlay" feels weird to me. Definitely not what I'd guess the setting values would be. I'd go for "left", "right" and "overlay" (or even "popup") to make it more explicit.

• It may be easier to read if, and look nicer, if the tree mode had a space between the line and file name. This would give the file name a bit of breathing room.

• The last item in the tree should use └ instead of ├ to indicate that the following item is not part of the same subtree.
  

• Because the CWD path is displayed, the view can scroll left and right when using h/l on file names, which feels strange

The rest of my thoughts are on the UX. I tried to write it up but couldn't quite word it right. Will think about it some more.

[cd-a]

Working really well already, great work!

What would be the best way to handle opening files when working in multiple splits?

In the file tree I used in neovim when you had more than one split open, and pressed open file in the tree it would overlay an A and B over the splits and then it would open where you selected.

[cd-a]

When I press space E to open explorer and focus the current file, the file that's highlighted sits at the top of the explorer.

I would suggest that it the active file is centered in the middle, so you can see the context above. Context above is arguably more important due to the containing directory structure.

In the video in the top post it looks like it's working, but on latest commit not for me.

[LeoniePhiline]

This is very cool! Thank you for opening a new PR with these changes.

Keybindings

Expand / collapse folders

(currently Enter)

I would find it more natural to

• open / expand folders in the tree with l / Right and
• close them with h / Left

(= open / close "doors" for directory vertical movement), since j and k are used for up and down (directory lateral movement).

Scrolling

(currently h / l)

For pure non-movement scrolling in the tree, which is probably rare, combinations with z (known for View mode) should be found. Also holding Shift with h/j/k/l and holding Shift with Left/Up/Down/Right could be used for scrolling.

However, z for view mode is helix lore, while holding Shift is not.

Folding current level

(currently z)

For folding the current level: Alt h / Alt Left, as z is needed for non-movement scrolling and known for View mode.

[clo4]

Perhaps it would be best to make an RFC-style doc with a proposed interaction model, so we can all have a discussion about the UX outside of a code-review context? Once there's something fully spec'd out, I'm sure it'll be much easier to implement without as much code churn -- sounds a lot easier than dealing with all the feedback in a PR 😅

(edit: let me know if this exists already!)

[marcesquerra]

Perhaps it would be best to make an RFC-style doc with a proposed interaction model, so we can all have a discussion about the UX outside of a code-review context? Once there's something fully spec'd out, I'm sure it'll be much easier to implement without as much code churn -- sounds a lot easier than dealing with all the feedback in a PR 😅

(edit: let me know if this exists already!)

Or, alternatively, have something that works merged (an MVP) and iterate over the result in future PRs instead of implementing (or designing) the perfect solution upfront?

[wongjiahau]

Calling the positions "embed" and "overlay" feels weird to me. Definitely not what I'd guess the setting values would be. I'd go for "left", "right" and "overlay" (or even "popup") to make it more explicit.

Implemented explorer.position right, and embed is renamed as left, via c446c39:

Screen.Recording.2023-02-06.at.10.15.29.PM.mov

[wongjiahau]

@clo4

explorer feels like a strange name for it. IMO a better name would be file-tree since that's what it is. We already have a file-picker after all :^)

I thought it was strange at first until I realized @cossonleo actually built another view for the explorer besides the default tree-view, which is "list", which behaves like Vim's built-in file explorer, :Explore.

It can be configured via :set explorer.style list.

[wongjiahau]

Replying to #5768 (comment):

Yes, I will reconfigure the keymaps by borrowing inspiration from nvim-tree.lua and/or coc-explorer, which I find more natural than the existing keymaps.

[sempruijs]

i-am-too-long.mp4

When you create a new file and the path is longer than the width of the window, it does not scroll. I think it should, so you can see how your file is going to be called. Also, maybe the path should start where .git is located and only show the absolute path if none of the parent folders contains a .git folder.

[wongjiahau]

@sempruijs If I’m not mistaken that’s the issue with the Prompt component. If you type a command longer than the terminal width, you should experience the same issue.

[sempruijs]

Thank you @wongjiahau

What if there was a shortcut to hide/show hidden files? . seems good to me

[quantonganh]

I would like to propose a minor adjustment: when the bufferline feature is enabled, it would be preferable for the open buffers to align with the left side of the editor pane:

(It's worth noting that this workaround uses broot)

This contrasts with the current alignment to the explorer pane:

[xiaoma20082008]

@wongjiahau 大兄弟，行百里者半九十，千万别弃坑啊。 有这个特性，我就能彻底摆脱neovim了~

This pr has update more than half a year，new idea was added again and again

[pascalkuthe]

This is an international project, keep comments on the issue tracker and PRs in English so everyone can understand them

[tmpm697]

any chance for it to be on higher priority to be released?

[univerz]

any chance for it to be on higher priority to be released?

@wongjiahau works on his own editor these days, this PR is probably up for grabs (v4!).

[wongjiahau]

Dear community and maintainers,

I have decided to let go of this PR.

This PR was an attempt to add a built-in file explorer to the editor, a feature that many of you have requested and supported.

However, after receiving feedback from the project team, I realized that my PR is not aligned with their project’s goals and visions.

They don’t think that the editor needs a file explorer and they think that my implementation is not fast enough to handle a folder with a large number of files, although I think that that is an edge case.

I apologize for any inconvenience or disappointment that this may cause you.

I want to thank you all for your time and effort in reviewing my PR and giving me constructive feedback.

I learned a lot from your comments and suggestions and I appreciate your guidance and support.

I also want to thank @pascalkuthe for showing me how to implement it using a faster algorithm and data structure.

However, I did not receive enough help or guidance from the project team when I encountered some technical difficulties or conflicts that I could not resolve.

I also did not agree with Helix’s architecture, where different components are built differently from ground-up, instead of using the same buffer component underneath, like how Emacs and Vim did it. This causes a tremendous amount of logical duplication, for example, cursor movements in the file explorer were implemented “again”, though said movements were already implemented in the Editor component.

I have no time to guess the requirements of the project team or make changes that I no longer believe in.

Therefore, I have decided to work on my own editor instead, where I can implement the features that I want and follow the design principles that I prefer.

I will not reply to any inquiries of my editor in this PR, the purpose of this PR should remain as it is, to discuss Helix’s file explorer.

If anyone would like to continue this PR, please email me, and I will grant you maintainer access to the repo so that you don’t have to create another PR.

I hope you understand my decision and respect my choice.

It was an interesting and challenging experience to contribute to this project and I’m grateful for the opportunity.

I wish you all the best.

Regards,
Jia Hau

[Abdillah]

Thanks @wongjiahau, the community would built or learn upon your work.
I'm still learning about this PR changes and the expectation. When the puzzle come together I might try to take this on.

[TheRealLorenz]

Hi everyone, I'm actually willing to pick this up. I'm applying suggested changes at the moment. What keybindings should be the default ones?

[TheRealLorenz]

Furthermore, this PR has been a little hard to understand lately. I think we should establish a todo list.

This is what stood out to me:

• Decide on what keymaps to use.
• Make preview panel toggleable.
• Unfocus selected item on explorer unfocus.
• Make a command helper popup.
• Change directory icon (? in my sistem looks like this: " ").
• Optimize.
• Document everything.

I need as much feedback as possible! I truly want this feature to be merged.

[wongjiahau]

@TheRealLorenz I have granted you maintainer access. Thanks for being willing to pick it up!

[TheRealLorenz]

Update

After having a kind discussion with @pascalkuthe (also thanks to @gabydd and @kirawi), we came to the conclusion that this feature would be better if implemented with plugins, which are still WIP.

A file tree explorer is a big feature and there's a lot of people who wouldn't benefit from it, including the maintainers, who would be "forced" to maintain it. This is precisely where plugins come into play, because they delegate maintenance to plugin authors and they are "opt-in" based.

I'm looking forward to reimplement a file tree explorer when the plugins ecosystem will be ready, sto stay tuned!

In the meantime using terminal multiplexers (i.e. tmux, zellij) in compination with TUI file managers (i.e. nnn, broot, lf) is the best alternative.

[pascalkuthe]

Discussion on matrix: https://matrix.to/#/!glLuldscRKMQxGWgjZ:matrix.org/$Bzc07HEizCKBD_Rp1nTt9FYfnyuYlxzIO5UQSQhJ7Ek?via=matrix.org&via=envs.net&via=tchncs.de

I am locking this PR as requested.

[archseer]

I also did not agree with Helix’s architecture, where different components are built differently from ground-up, instead of using the same buffer component underneath, like how Emacs and Vim did it.

To clarify: for the file picker this is my preference too (I've mentioned vim-dirvish a couple times). There is actually a demo using Steel that works this way (https://github.com/mattwparas/helix-config/blob/master/cogs/file-tree.scm) but it's not ready to be used yet.