feat: add api.tree.toggle_enable_filters

[DeH4er]

Hi there. Thanks for the amazing project.

I often find that I need to access hidden files but I keep forgetting keybindings for particular filters. I wish to have one goto keybinding to make it easier to see all files.

I'm unsure about the naming of some vars and functions. But overall, I hope it's a good contribution to the project

[alex-courtis]

Concept and change looks good.

Let's get some consistency in user and API naming. Perhaps Toggle All Filters Disabled and api.tree.toggle_disable_all_filter()

[DeH4er]

What do you think about Toggle Filters Disabled and api.tree.toggle_filters_disabled? PR is updated to reflect these names

[gegoune]

I would prefer enabled = true.

[DeH4er]

Actually, I see that the convention is enable. Will update PR

...
      hijack_directories = {
        enable = true,
        auto_open = true,
      },
      update_focused_file = {
        enable = false,
        update_root = false,
        ignore_list = {},
      },
      system_open = {
        cmd = "",
        args = {},
      },
      git = {
        enable = true,
        show_on_dirs = true,
        show_on_open_dirs = true,
        disable_for_dirs = {},
        timeout = 400,
        cygwin_support = false,
      },
...

[alex-courtis]

Works nicely except for the live filter case.

I naturally tried that case when testing and was surprised when it didn't apply. Can we please add that? I imagine users will be similarly surprised.

[alex-courtis]

Suggested change

	Enable / disable filters.
	Enable / disable all filters including live filter.

[alex-courtis]

I'm not quite sure about the , mapping, I'm always nervous about overriding "core" vim keys.

@gegoune should we change it to something like T?

[gegoune]

I'm not quite sure about the , mapping, I'm always nervous about overriding "core" vim keys.

@gegoune should we change it to something like T?

Not overriding existing mappings is a good thing for sure. I see two options:

1. map it to something free, I don;t really care what to be honest as there is a way to change the default
2. don't add new mappings going forward. We could even look into removing majority of existing mappings from api.config.mappings.default_on_attach providing only bare minimum. But that's radical, maybe too radical.

BTW, T is an existing vim key :h T.

[alex-courtis]

2. don't add new mappings going forward.

I'm inclined to agree. Each default mapping added is potentially a user's mapping clobbered.

Sorry @DeH4er - please remove the default mapping.

We could even look into removing majority of existing mappings from api.config.mappings.default_on_attach providing only bare minimum. But that's radical, maybe too radical.

That would break people, however we could add a very trimmed down api.config.mappings.minimal_on_attach

[DeH4er]

I updated the PR with all your feedback.

Since you touched on a topic of keybindings, currently it's hard to get a sense of what's possible.

1. The help panel is hidden under "g?" keybinding by default, and only when nvim-tree updated its way to change keybindings, I discovered that there's a help panel (I was smashing ? and since it did nothing, I just assumed there's no help panel).
2. As a user, you think everything useful (or even possible) is in this panel.

So I think the ideal solution would be to:

1. Make it clear that g? is a default help panel keybinding. Show "g? - help" somewhere in nvim-tree panel or make it visible in readme.
2. Show every possible API command in this help panel, even if it has no keybinding + keybinding if there's one
3. Since there are lots of commands, it would be great to group them

This way, you can have minimal keybinding config and it will be extremely easy to copy-paste api function to your on_attach without reading :h nvim-tree

[alex-courtis]

Works beautifully, many thanks!