Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add view.filter option #108

Merged
merged 1 commit into from
Dec 27, 2024
Merged

Conversation

epheien
Copy link

@epheien epheien commented Dec 27, 2024

Because outline.nvim defaults to ignoring nobuflisted buffers, an option hook needs to be added for user customization.

After adding following options and 'epheien/outline-treesitter-provider.nvim' dependency, outline.nvim can support help (vimdoc) filetype.

{
  view = {
    filter = function(buf)
      local ft = vim.bo[buf].filetype
      if ft == 'qf' then return false end
      return vim.bo[buf].buflisted or ft == 'help'
    end,
  },
}

refer #34

Xnip2024-12-27_09-23-54

Copy link
Owner

@hedyhli hedyhli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure adding support for vimdoc warrants a new configuration option to let the user customize the kinds of buffer to be filtered. It's better to make the default filter more lax, such as removing the check for buflisted altogether or special case for the help filetype. See: #76 (comment)

Copy link
Owner

@hedyhli hedyhli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@hedyhli hedyhli merged commit f656ef1 into hedyhli:main Dec 27, 2024
@epheien
Copy link
Author

epheien commented Dec 27, 2024

Removing the check for buflisted altogether or special case for the help filetype is simple.

But view.filter has an additional function, that is, when entering the buffer that is explicitly ignored, the outline will not clear the content.

And if there are some unlisted buffers that need to be supported in the future, the code needs to be modified each time.

@epheien
Copy link
Author

epheien commented Dec 27, 2024

Thanks!

Did you merge wrong PR? I just updated another PR #109.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants