FEATURE: Option for `follow_current_file` to follow into hidden files

[mehalter]

Did you check the docs?

• [X] I have read all the docs.

Is your feature request related to a problem? Please describe.

Sometimes I'm working in projects with folders that are hidden becaues they are in gitignore. Folders such as virtual environments with the dependencies of the project. With language servers and the go to definition feature, sometimes I do find myself jumping into those dependency folders without browsing directly to them. If I have follow_current_file enabled and have neo-tree opten, it does'nt follow me anymore into hidden folders. I don't always want to see those folders so it's good they are hidden by default, but it would be great to have an option to allow enable visibility of hidden files only if I am currently editing a hidden file. That way I can then browse around the filesystem at that place.

Describe the solution you'd like.

I think the default behavior can be the expected behavior, but I think having another option similar to leave_dirs_open to further configure it's behavior. Maybe something like follow_into_hidden or something like that.

Describe alternatives you've considered.

I'm not sure of many alternatives. The only thing I can think of is being able to make a custom event_handler but I'm not sure if there is an event for the follow_current_file getting triggered since this isn't triggered directly from browsing within neo-tree, but by navigation outside of neo-tree.

Additional Context

No response

[cseickel]

Showing just the path to a hidden file that is currently focused would get pretty complicated, but I can see automatically toggling the "show hidden" state if the current file is in a hidden folder.

Toggling it back off again when the focus leaves might also get complicated. So I would have a a one way action that just turns on show hidden files but does not attempt to figure out if it should be turned off again. Leave that to the user.

The best way to implement this might be in a user defined event. The hardest part would be determining if a given file would be considered hidden or not.

It's not a change that I would work on personally because for me, I can just toggle hidden manually if I cared, but really I just rarely feel the need to see the tree for a file that I got to with "go to definition". I only use the tree to open, add, and delete files. I don't usually leave it open as a reference to where I am.

[mehalter]

Yeah I think best would just be just toggling filtered visibility. Definitely not showing just the current path just because it can end up being a bit not useful. Thanks for the ideas! This can be left open just in case someone wants to implement it or if I get some time to take a stab at it!

If I were to try to make an autocommand for this are there API points to get the necessary details? Basically the things that would be needed are:

• an event that happens when the file changes and follow_current_file is triggered
• an API to check if a node is currently visible or not

With that information it should be easy to just check if the current node is visible, toggle visibility, and then change it in the next event if necessary.

Thanks again!

[cseickel]

The follow current file logic is triggered by the VIM_BUFFER_ENTER event (a constant that points to the `"vim_buffer_enter" string.)

Figuring out if a file would be hidden is difficult and there is no api to help you. This is handled along the way as the filesystem is being scanned, and then the hidden files are filtered out just before being sent to the Nui tree, and that intermediate collection of items that might be rendered is just dropped. It might require altering the internal logic to either extract out the hidden logic to a reusable utility or storing the filtered nodes in a separate collection that can be looked up.

[mehalter]

Interesting. Thanks for the further information! This will be super useful if anyone decides to pick up trying to implement this.

Thanks for building and maintaining such a great plugin!

[johnend]

I kind of feel that this would be pretty useful, given the amount of dotfiles people are spitting out, and likely managing with something like stow, it makes sense to be able to follow hidden files. Especially in that use case. However, it is kind of moot if you know your dotfiles well enough. Just chiming in because I feel like this would be useful, albeit maybe not critical, feature. Neotree is great, and it's making the move from VSCode a bunch easier :smile: