Thank you for contributing.

Why is this needed?

Because it's useful to know which file a function is from, but maybe I'm missing something?

I don't see why that would be useful given that directories contain only a single package and function names are within a package a unique. You can navigate to the function by selecting it and you can see the function signature in the preview window.

That's fair -- I guess I got confused because the ctrlp version of this does include the the file attributes:

Apparently also had it in my head for some reason that GoDecls acted recursively over the directory tree which I see now was incorrect.

Thanks for the quick feedback, feel free to close this.

That's an interesting point; it may make sense for the ctrlp and fzf integrations to be more consistent in their presentation.

Honestly, I'd lean more towards removing the file info from the ctrlp integration, because:GoDecls only operates on the current file and:GoDeclsDir only operates on a single directory and the file info takes up valuable screen real estate.

I'll give it some thought, but I'm interested to hear your perspective.

That makes a lot of sense; happy to refactor this PR to instead remove it from the ctrlp autoload.

Just a quick comment in support of providing additional context to the symbol names.

I often have to give up:GoDeclsDir when there are different implementations of the same symbol, for example different types implementing the same interface cannot be told apart in the results, their methods are all, for exampleString() string, and I don't know which one to select.

Another common situation is when the same symbol is present both in the actual package (say,mypkg), and in the..._test package (mypkg_test). The..._test package coexists in the same directory as the real one, and symbols with the same name across the two cannot be identified in theGoDeclsDir results. This is often the case when using generated mocks.

For example:

@bravoecho in those cases, the preview window that allows me to distinguish between the types that are implementing the methods. Are you not seeing the preview window on the right hand side?

Thank you@bhcleek for your message 🙂 Good point! I actually disabled all previews to avoid information overload. You make me realise that perhaps this is because I'm using the feature for navigating code, rather than for searching it.