francisco.lopes added a comment.
In https://reviews.llvm.org/D38048#887960, @ilya-biryukov wrote:
> Another case where this might be bad is overloaded functions. I may choose
> one overload in completion, but `signatureHelp` will initially point into a
> different one.
Hi, I'd just like to c
francisco.lopes added a comment.
In https://reviews.llvm.org/D38048#889176, @ilya-biryukov wrote:
> @francisco.lopes, thanks for sharing your experience, I definitely like the
> final UX you achieved, we should aim for something similar in clangd.
> It also looks like @rwols's idea of how thin
francisco.lopes added a comment.
In https://reviews.llvm.org/D38048#889568, @rwols wrote:
> Since we're throwing around gifs for fun here's how signatureHelp looks in
> practice for Sublime Text
Very cool!
https://reviews.llvm.org/D38048
___
cfe
francisco.lopes added a comment.
Sorting got hardcoded? libclang has it optional. If hardcoded it becomes a
performance problem, since some clients may wish to order it themselves with
private heuristics.
Repository:
rL LLVM
https://reviews.llvm.org/D39738
___
francisco.lopes added a comment.
I'm still in the process of construction a general jsonrpc client and didn't
start consuming clangd yet. But, I do have previous experience with libclang,
and I don't know whether clangd will be able to return completion results at
global scope (not necessarily
francisco.lopes added a comment.
OK. I do agree serialization, etc, is a stumbling block on delivering large
results fast. I just wanted to warn on this because I've just seen ycmd devs
went through this, where sorting was one of the bottlenecks, like, to
`std::sort` 43k results instead of simp
francisco.lopes added a comment.
I'm waiting for this to land as well, it's crucial for coding windows code with
libclang assistance on a linux machine.
https://reviews.llvm.org/D21113
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://
