Recursively expand a single directory node

[mikehaertl]

I'm missing an API method to expand a single directory node recursively. This would often be helpful when I only want to view a certain subtree of my project but don't want to expand everything.

I've seen api.tree.expand_all (expands all nodes) and api.node.open.edit (expands only first level). Maybe the latter could be improved with an options arg like api.node.open.edit({recursive = true}).

[alex-courtis]

That is a good use case.

I'm not quite understanding the nuance: E expand_all on a folder will expand all that folder's folders recursively.

Are you after something different?

[mikehaertl]

Actually I remember now: I got confused by the docs:

api.tree.expand_all({keep_buffers})
Expand all nodes in the tree.

I think there are in fact two quite different behaviors combined here:

• Expand the subtree of the current node if it's a folder
• Expand the full tree if not on a folder node

TBH I wonder if this shouldn't rather be 2 API calls:

• api.tree.expand_all() always expand all nodes in the full tree, no matter where the cursor is
• api.node.navigate.expand_all() only operate on the node where the cursor is:
  • if on a folder node: expand all folders below
  • if not on a folder: expand all folders below the parent folder

And then we could also have api.node.navigate.collapse_all() which would operate on the current node only (in contrast to api.tree.collapse_all().

Does that make sense?

[mikehaertl]

Oh, you're right. I think it was actually a recursive close for a single node that I was missing as W closes all nodes and <CR>/<BS> are not recursive.

In the end I somehow got confused and thought it was expand, so I avoided using E at all, which works perfectly fine.

Sorry for the noise. And not sure if the recursive close is something worth adding - or if I'm missing yet another existing feature.

[alex-courtis]

Sorry for the noise.

No need to apologise at all.

And not sure if the recursive close is something worth adding - or if I'm missing yet another existing feature.

Take a look at :help nvim-tree.api.tree.collapse_all() with keep_buffers set.

[mikehaertl]

Take a look at :help nvim-tree.api.tree.collapse_all() with keep_buffers set.

Thanks, but that's not quite what I meant. Say you have two main directories A and B, each with a subtree of some depth.

• You expand both node's subtrees with E
• You have no file opened from both subtrees
• You decide you want to collapse B recursively but not A

AFAIK you can't do that right now:

• :NvimTreeCollapseKeepBuffers will close both because you have no file opened
• <CR> or <BS> on B are not recursive. I.e. if you open B again it will still have the full subtree expanded.

So basically what's missing is really the inverse of E for a single node.

[alex-courtis]

api.tree.expand_all({keep_buffers})          *nvim-tree.api.tree.expand_all()*
    Expand all nodes in the tree.

This is incorrect doc; keep_buffers does not exist. Updated.

Summary

E expand_all

• folder: recursively expand the contents of that folder
• other: recursively expand the entire tree excluding actions.expand_all.exclude

<CR> edit

• folder: expand or collapse the folder with the subfolders expanded / collapsed
• other: open the file

W collapse_all

• collapse all the folders in the tree

[alex-courtis]

if you open B again it will still have the full subtree expanded.

That was the nuance I was missing.

How about something like:

api.tree.collapse_all({opts})              *nvim-tree.api.tree.collapse_all()*
    Collapse the tree.

    Parameters: ~
      • {opts} (table) optional parameters with boolean defaults

    Options: ~
      • {keep_buffers} (boolean) do not collapse nodes with open buffers
      • {subtree}      (boolean) only collapse the current node's root folder

The name and wording of {subtree} is poor; I'd appreciate a better idea.

[mikehaertl]

Ok for me. Maybe node instead of subtree?

Actually I therefore still think splitting this (and expand_all()) up into 2 methods would be even clearer as one operates on the entire tree and the other on a node. So api.tree.xyz() and api.node.xyz() would feel natural to me.

But whichever you choose should be fine.

[alex-courtis]

So api.tree.xyz() and api.node.xyz() would feel natural to me.

That could work.

#2119