Customizable filter composition logic

[gracepetryk]

When using the git_clean and no_buffer filters together, I think it would be more useful to show files that are either dirty or open in a buffer. The current behavior is to only show files that are both dirty and open in a buffer.

Can this functionality be implemented utilising API?
Not currently, the filter logic is not exposed in the public API.

Describe the solution you'd like
Exposing the various filter functions to the public api in a way that they could be composed in the custom filter would be my preferred solution. Something like this would be nice:

require('nvim-tree').setup({
  filters = {
    no_buffer = false,
    git_clean = false,
    custom = function (path)
      local filter_api = require('nvim-tree.api.filter')

      -- return true only when *both* git_clean and no_buffer would filter the path. These
      -- functions should not check the enabled/disabled state of the function so that the
      -- custom filter can have precedence while still using their result.
      return filter_api.git_clean(path) and filter_api.no_buffer(path)
    end
  }
})

Describe alternatives you've considered
I've implemented the behavior I want in my config with a couple janky runtime patches to nvim-tree's internal filter API:

local filters = require('nvim-tree.explorer.filters')
local enum = require('nvim-tree.enum')

local should_filter = filters.should_filter
local should_filter_as_reason = filters.should_filter_as_reason

filters.should_filter = function (self, path, fs_stat, status)
  if self.state.no_buffer and not self:buf(path, status.bufinfo) then
    return false
  end

  if self.state.git_clean and not self:git(path, status.project) then
    return false
  end

  return should_filter(self, path, fs_stat, status)
end

filters.should_filter_as_reason = function (self, path, fs_stat, status)
  if not should_filter(self, path, fs_stat, status) then
    return enum.FILTER_REASON.none
  end

  return should_filter_as_reason(self, path, fs_stat, status)
end

Additional context

[alex-courtis]

That's a fantastic idea, something we should have done earlier.

I like the API - we can use that to express the built in filters, allowing users to follow them as examples.

A pull request would be most gratefully appreciated, see CONTRIBUTING.md

I'm very happy to work with you, iterating on a solution.

[gracepetryk]

Hi @alex-courtis, I just opened a draft PR here: #3121. LMK what you think and if it looks good to you I'll add tests and docs!