Add support of auto folded directories

[ABckh]

Added support of auto collapsed directories, for example when directory has only one directory inside we should display it as dir1/dir2 (#6935 ). Please feel free to propose better solutions, as I am new in Rust

Demo:
https://streamable.com/seo3n9

Release Notes:

• Added support for auto-collapsing directories.

[maxbrunsfeld]

Great work @ABckh . Thanks for adding tests and that demo video. I left some suggestions on the implementation.

[maxbrunsfeld]

Let's call these commands "Fold/Unfold Directory" instead of "Fold/Unfold The Children".

[maxbrunsfeld]

I think we should only add a single piece of state here: unfolded_dir_ids - which are the set of directories that have been explicitly unfolded. It could be structured similarly to expanded_dir_ids (in a hash map keyed by WorktreeId, or perhaps a simple HashSet<ProjectEntryId>.

I think we can remove the String (for the folded paths). I'll explain more below.

[maxbrunsfeld]

Rather than storing the folded paths explicitly as strings, I think we could use the existing path field that's on an Entry, and if we noticed that the entrie's descendant directories should be folded, we can render multiple components of the path (instead of just the filename).

So in this loop, could we simply omit entries for directories that are folded, so that the visible_worktree_entries vector would look like this:

[
    Entry {
        path: "src",
        // ...
    },
    // The entries for the singleton directories `dir1` and `dir2` are omitted,
    // because we decided to fold those single-child directories.
    Entry {
        path: "src/dir1/dir2/TheFile.java",
        // ...
    },
]

Then, when processing these entries in for_each_visible_entry, we could notice that the entry for TheFile.java has some folded descendants, because its path differs from its predecessor's path by more than one path component. When we detect that, we could render all of the additional path components (dir1/dir2/TheFile.java), not just the filename (TheFile.java).

With this approach, we don't need to store as much redundant state. Does that make sense?

[ABckh]

It does, this approach looks better. I will try to implement it, thank you!

[ABckh]

Rather than storing the folded paths explicitly as strings, I think we could use the existing path field that's on an Entry, and if we noticed that the entrie's descendant directories should be folded, we can render multiple components of the path (instead of just the filename).

So in this loop, could we simply omit entries for directories that are folded, so that the visible_worktree_entries vector would look like this:

[
    Entry {
        path: "src",
        // ...
    },
    // The entries for the singleton directories `dir1` and `dir2` are omitted,
    // because we decided to fold those single-child directories.
    Entry {
        path: "src/dir1/dir2/TheFile.java",
        // ...
    },
]

Then, when processing these entries in for_each_visible_entry, we could notice that the entry for TheFile.java has some folded descendants, because its path differs from its predecessor's path by more than one path component. When we detect that, we could render all of the additional path components (dir1/dir2/TheFile.java), not just the filename (TheFile.java).

With this approach, we don't need to store as much redundant state. Does that make sense?

Hi @maxbrunsfeld ,
I've returned to work on the PR and I have a question about the implementation. I've managed to achieve this structure for visible_worktree_entries:

[
     Entry {
         path: "src",
         // ...
     },
     // The entries for the singleton directories `dir1` and `dir2` are omitted,
     // because we decided to fold those single-child directories.
     Entry {
         path: "src/dir1/dir2/TheFile.java",
         // ...
     },
 ]

However, I didn't fully understand how you want them to be rendered properly. So what I did is I took the parent entry from visible_worktree_entries and calculated the difference, then I changed the filename and depth of a child based on that difference. From what I understood, this might not be the way you want it to be rendered. Could you please clarify?

[maxbrunsfeld]

Yeah, that sounds good to me. I just didn't think we need to maintain additional state for the paths of collapsed directories. It looks like there is still that state on the branch. Are you talking about changes that you haven't pushed up yet?

[ABckh]

Yes, I have not pushed it yet, still facing issues with some corner cases. Thank you for clarification!

[SomeoneToIgnore]

A few notes related to the UX, based on a real Java project (https://github.com/vaadin/flow/)

Here, flow-test-generic has the action, but it does nothing — I would expect it either to be absent, or actually folding/unfolding the directories below it, even though there's no direct children that can be folded.

Here .github directory has nothing foldable in the entire tree, but it has the menu item for some reason.

• when I unfold the hierarchy of files with the dir collapsed

it does close the new unfolded directories, and I have to make an extra click to open the back:

that does not seem right to me, as the original, folded view did show those directories as "open".

[jansol]

How does this interact with paths that only have an empty directory at the end? Particularly if you have say, foo/bar and foo/baz and both bar and baz are empty.

[ABckh]

How does this interact with paths that only have an empty directory at the end? Particularly if you have say, foo/bar and foo/baz and both bar and baz are empty.

it would not fold them as foo has 2 children, and bar and baz has no children. Checked in vscode, the behaviour is the same:

And what is the expected behaviour?

[jansol]

I don't really have experience with such functionality so no good references. Not folding seems reasonable there.

And I assume foo/bar/baz/xyz/zy where zy is empty would get folded?

[ABckh]

I don't really have experience with such functionality so no good references. Not folding seems reasonable there.

And I assume foo/bar/baz/xyz/zy where zy is empty would get folded?

Yep, it does not matter if the last dir has children or not

[xerc]

I don't really have experience with such functionality so no good references. Not folding seems reasonable there.
And I assume foo/bar/baz/xyz/zy where zy is empty would get folded?

Yep, it does not matter if the last dir has children or not

do you consider a empty-directory icon or hide the open-directory chevron?

[maxbrunsfeld]

Thank you for making that refactoring @ABckh. Looks good.