[clangd-dev] Completion list spam and macros

[Sam McCall via clangd-dev]

On Mon, Jun 11, 2018 at 3:32 PM Marc-André Laperle <
marc-andre.laperle at ericsson.com> wrote:

> Hi Sam!
> I think completing macros is useful so I would say A would not be good. I
> think B sounds good for the short/medium term.
>
Agreed on both counts here. I actually landed a patch for B as it seemed
like such a clear win. If it's causing problems for anyone happy to revert.
(One possibility is windows devs: apparently API calls like CreateFile are
macros that point to the A/W string variants)

I’d like to eventually come up with a proposal of what to truncate, because
> I see results that are every unlikely to match the user intention. For
> example, not showing strtod and CLONE_CHILD_SETTID. But I don’t know enough
> about how this is implemented to make a concrete proposal.
>
I noticed this too, can you try https://reviews.llvm.org/D47950 and see how
it feels? I think this is the right fix for that problem.


>
> Cheers,
> Marc-André
> ------------------------------
> *From:* clangd-dev <clangd-dev-bounces at lists.llvm.org> on behalf of Sam
> McCall via clangd-dev <clangd-dev at lists.llvm.org>
> *Sent:* Friday, June 8, 2018 6:21:58 AM
> *To:* clangd-dev at lists.llvm.org
> *Subject:* [clangd-dev] Completion list spam and macros
>
> So code completion has lots of irrelevant results :-)
>
> Macros seem to be the worst offenders. We're doing a better job of
> downranking them, but it still means that the result list is *always* long:
>   https://i.imgur.com/gRZl0PZ.png
> We currently don't index macros and I'm scared that doing so would make
> this problem worse.
>
> What do people think about these ideas (not alternatives, we could try
> several):
> A) not completing macros at all, ever
> B) completing macros only for case-insensitive prefix matches (not fuzzy)
> C) tightening the word segmentation aspects of fuzzy matching (for all
> symbols) so this stuff doesn't match
> D) tightening the case-matching aspects of fuzzy matching (for all
> symbols) so this stuff doesn't match
> E) trying to identify the boundary between goodish results and bad
> results, and truncating the list there? (This will require disabling
> client-side filtering)
> F) ignoring this problem as long as good results aren't being buried under
> the bad ones?
>
> (I'll send a patch shortly for B which seems like an easy win to me,
> please try it out and we can revert if it's terrible)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20180611/7fccb660/attachment.html>