ilya-biryukov added a comment. > 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`. https://reviews.llvm.org/D35894 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
