SmiteshP / nvim-navbuddy

A simple popup display that provides breadcrumbs feature using LSP server
Apache License 2.0
770 stars 30 forks source link

Option to skip types/filter #4

Open JoseConseco opened 1 year ago

JoseConseco commented 1 year ago

Hi, this is great plugin. I wish for 2 features: 1 option to use only selected types - e.g. in my case I would like to show only: Classes, methods, funcions (hide everything else) 2 option to skip jumping to highlighted entry during navigation (it is bit distracting right now Imo, when whole background buffer changes, when navigating through navbuddy entries, to the one I want to open). Great plugin.

SmiteshP commented 1 year ago

1 option to use only selected types - e.g. in my case I would like to show only: Classes, methods, funcions (hide everything else)

I am not inclined to do this as I feel this will add lot of complexity to plugin. If you feel you need this after using navbuddy in lua, I assure you won't feel the need for other languages. Lua lsp is a bit of an outlier and outputs a lot of documentSymbols that you wouldn't really want to see (or even should be considered documentSymbol). But still let me see what can be done, if it doesn't introduce too much complexity, I will add this.

2 option to skip jumping to highlighted entry during navigation (it is bit distracting right now Imo, when whole background buffer changes, when navigating through navbuddy entries, to the one I want to open).

Yep, understandable. I will add an option to disable this behavior in setup function.

JoseConseco commented 1 year ago

Thanks for fast reply. About filter, here is example code in python: image 99% of time I want to navigate to class, method or function - and all these local variables are just polluting the view. Maybe u could copy solution from aerial ? I found he is filtering entries with this: https://github.com/stevearc/aerial.nvim/blob/master/lua/aerial/backends/lsp/callbacks.lua#L45

which uses get_filter_kind_map defined in config: https://github.com/stevearc/aerial.nvim/blob/master/lua/aerial/config.lua#L497 Which basically seem to return config table wit filter kind elements. But maybe I'm missing something and it is not as straight forward

SmiteshP commented 1 year ago

If the filter were to be implemented, what should happen in the following case? User does not want to see a Class but wants to see Methods, so should the class be filtered out completely? If so then there will be no way to go to the methods because (in navbuddy atleast) to move to a node you have to go through its parent. This isn't specific to Class and Method, in general what should be done when upper level node is not to be shown but it has children which should be shown? Should we just remove the upper node with all its children regardless?

JoseConseco commented 1 year ago

Well, I like what aerial is doing - it is just showing 'flattened' version of tree like so: image The nesting is gone, but you still get access to all methods. I'm not sure how other outliners are handling this, but aerial way seems fine. But can see this getting confusing - where in example above, we got multiple execute() methods from different classes, all bunched up, and hard to distinguish.

On the other hand VSCode is removing inner nodes, if outer is disabled...

SmiteshP commented 1 year ago

Checkout the latest commit, added some source_buffer options to disable following and highlighting.

One idea I have for filtering is that I will just let the user provide a function, that takes in the current node (as determined by the navbuddy logic) and should give back a node in return. Navbuddy will start with this returned node in focus. And since each node has all pointers to parent, siblings and children, the user can run their algorithm to prune/flatten or modify the tree as they see fit. What do you think? This way someone could implement the simplistic filter of removing node out right, or flatten some branches of tree, or have some ridiculous filter like nodes with line count < 5 should not be shown. Basically it will be very powerful way to change usage of the plugin, but would require some work from end user's part.

JoseConseco commented 1 year ago

I just updated navbuddy and disabled follow_node , but buffer is still moving... My config

{
    "SmiteshP/nvim-navbuddy",
    dependencies = { "neovim/nvim-lspconfig", "SmiteshP/nvim-navic", "MunifTanjim/nui.nvim" },
    config = function()
      require("nvim-navbuddy").setup {
        lsp = {
            auto_attach = true,  -- If set to true, you don't need to manually use attach function
            preference = nil  -- list of lsp server names in order of preference
        },
        source_buffer = {
            follow_node = false,   -- Keep the current node in focus on the source buffer
            highlight = false      -- Highlight the currently focused node
        }
      }
    end,
  },   

Filtering by using hook function sound even better than I imagined. I hope u will show at least one or two examples how to use it.

SmiteshP commented 1 year ago

Can you check now? I had missed updating the setup function. Thats why is wasn't working for you.

Filtering by using hook function sound even better than I imagined. I hope u will show at least one or two examples how to use it.

Yeah will provide some examples to show how it can be used. However I put this feature little lower in priority, right now will focus on bug fixes and implementing some other simpler features first.

JoseConseco commented 1 year ago

Works ok great. I guess I/you could close this and open new issue with filter handler?

SmiteshP commented 1 year ago

Its fine, lets keep this open since the discussion is here.

litoj commented 1 year ago

I was also thinking about a filter, but in a sense of filtering by name, like fzf. Though as I think about it longer, that's more for a plugin like fzf-lua. I originally wanted this to find a function definition, but that can be done just by finding a reference with basic search. For traversing references there is already a builtin method, so it probably wouldn't have added much aside of nicer node operations available. But I thought it may be to some use posting it anyway.