malaperle added a comment. In https://reviews.llvm.org/D35894#829109, @ilya-biryukov wrote:
> > I think all of those would be great. Our objective is to bring basic but > > correct features that will put us close to parity with Eclipse CDT, so that > > our users can transition. In CDT only the "raw" source is shown, similar to > > this patch (except in CDT it attaches comment nodes so you get the few > > lines of comments before). I think priority wise, we would likely want to > > tackle other LSP features first before adding more things to the hover, > > (References, Open Definition, etc). > > Don't get me wrong, I'm not trying to get all of what I described in the > first CL, but I definitely think that's the experience we want from hovers > and we should lay out foundation to make it happen. > I.e. here is a meta-description of algorithm for hover that is easy to > implement and extend later: > > 1. Resolve reference under cursor. Result: `Decl` or `MacroDefinition` that > the symbol under cursor refers to (possibly a list of results). > - This part should be reused between `findDefinitions` and hovers. It's > already there, we just need to extract an interface that provides `Decl` and > `MacroDefinition` instead of their `Range`. > 2. Transform result of step 1 (`Decl` or `MacroDefinition`) into a hover > description (i.e. into a MarkedString). > - This part can be super-simple in the first commit, i.e. it may only > output a source code of declaration and a symbol kind (i.e. local variable, > parameter, class, macro, etc). That could be easily extended in the future. > > > I do find that just showing the raw code is lacking in many situations for > > example I have found myself having to figure out which namespace a symbol > > was in by hand so it's very much desirable to add more to the hover. > > Sure, even though showing source code is still fine most of the time. > I also wanted to stress that we shouldn't too much. Let's not show the body > of the function we're referring to as it may be very large and it's > irrelevant most of the time. If a user really wants to see definition, he can > jump to it using `findDefinitions`. As a user I want to be able to peek at the code without changing context, not all the time though for sure. Eclipse actually has two hovers: a "semantic" one which in Java includes the package, type, visibility, javadoc, etc, this is what you describe and the default in Java (and it should be for C++ if it existed!). And there is also a source hover which just outputs the source code of that symbols, which you enable by holding shift (the only one implemented in the case of C++). The objective is to have both in Clangd but the latter is much more low hanging. Whether of not the body of a function is large doesn't matter because clients either crop it or add scollbars to the hover (Eclipse, VS Code, Theia). https://reviews.llvm.org/D35894 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
