This is an archive of the discontinued LLVM Phabricator instance.

[clangd] UI for completion items that would trigger include insertion.
ClosedPublic

Authored by ioeric on Jun 14 2018, 2:59 AM.

Details

Summary

For completion items that would trigger include insertions (i.e. index symbols
that are not #included yet), add a visual indicator "+" before the completion
label. The inserted headers will appear in the completion detail.

Open to suggestions for better visual indicators; "+" was picked because it
seems cleaner than a few other candidates I've tried (*, #, @ ...).

The displayed header would be like a/b/c.h (without quote) or <vector> for system
headers. I didn't add quotation or "#include" because they can take up limited
space and do not provide additional information after users know what the
headers are. I think a header alone should be obvious for users to infer that
this is an include header..

To align indentation, also prepend ' ' to labels of candidates that would not
trigger include insertions (only for completions where index results are
possible).

Vim:

vscode:


Diff Detail

Event Timeline

ioeric created this revision.Jun 14 2018, 2:59 AM
ioeric edited the summary of this revision. (Show Details)Jun 14 2018, 3:03 AM

Ooh, bikeshed first!

clangd/CodeComplete.cpp
313

I think we should avoid tokens that occur commonly in C++ (possibly with the exception of # which is used for this purpose. We should also avoid doublewide chars because of alignment (even assuming a monospace font is risky...)

Ideas:

  • something like "external link" icon on wikipedia - but no such thing in unicode :-(🔗(U+1F517 link) looks truly terrible in at least some fonts
  • variant on plus like ⊕ (U+2295 circled plus) - can't find one I like a lot
  • some kind of arrow like ☇ (U+2607 lightning) or ⇱ (U+21F1 north west arrow to corner) or ⮣ (upwards triangle-headed arrow with long head rightwards)
  • variant on hash like ﹟(U+FE5F small number sign)
  • something unrelated but "special" like ※ (U+203B reference mark)

I'm not really happy with any of these :-(

ioeric updated this revision to Diff 151357.Jun 14 2018, 8:22 AM
  • s/+/•/ and make the icon an code completion option to avoid hardcodes in multiple places.
clangd/CodeComplete.cpp
313

Thanks for the suggestions!

After playing around with different options, we decided to go with which is simple and also aligns well in vim and vscode. We tried to avoid symbols that are meaningful/complicated because they tend to add noise when users are used to the existence of the icon, and they appear less elegant when there are a whole list of indicators in the completion results.

sammccall added inline comments.Jun 14 2018, 9:09 AM
clangd/CodeComplete.cpp
191

Hmm, I'm not sure this should be conditional.
Especially in editors that render [icon]label, inconsistently having a space or not for no obvious reason seems disorienting to users.

And it adds some complexity (especially in conjunction with bundling...)

301

nit: .hasValue() would be clearer than static_cast

313

this is going to be slightly tricky with bundling, where we take the CompletionItem for an arbitrary item, and recompute the label as Name + "(...)".

Note that if we're unconditionally adding the padding character, we can just grab it out of the old CompletionItem.label :-) Yes it's a hack, but otherwise we need to pass this information around or factor quite differently.

clangd/Headers.cpp
74–75

we don't need Expected here anymore?

clangd/Headers.h
52–53

why the change from empty string here? does this anticipate adding the path to the detail/doc unconditionally in a future patch?

This is quite a hard signature to understand and describe. At first glance it seems we can just split function into bool shouldAddInclude() and calculateIncludePath(), they won't overlap?

87–94

this signature is scary :-)

One option is to separate:

  • bool shouldInsert(Declaring, Inserted) (probably just log errors and return false)
  • string spell(Inserted)
  • TextEdit insert(Spelled)

another is a struct, but I think making the flow a little more explicit at the callsite might be clearer.

Oops, forgot to link to the bundling patch: D47957
We should expect some conflicts one way or the other.

ioeric updated this revision to Diff 151492.Jun 15 2018, 5:33 AM
ioeric marked 6 inline comments as done.
  • Addressed review comments.
  • Merged with orgin/master

Thanks for the review!

clangd/CodeComplete.cpp
191

Sure. I wasn't sure about this and wanted get your opinion before fixing tests.

sammccall accepted this revision.Jun 15 2018, 6:08 AM
sammccall added inline comments.
clangd/CodeComplete.cpp
301

This is fine for now, but can you add a FIXME to consider what to show if there's no include to be inserted, and for sema results? There's some value in showing the header consistently I think.

302

can we add the \n for now even if detail is empty?
That way the editors that "inline" the detail into the same line as the label won't show it (if we patch YCM to truncate like VSCode does).
The inconsistency (sometimes showing a return type and sometimes a header) seems surprising.

313

string(IncludeInsertionIndicator.size(), ' ')?

335–341

again, need to account for the length of the indicator

clangd/CodeComplete.h
70

if you want this to be part of the doc comment, move it to the bottom?

I think the intent was that this comment apply to all following members. So keeping the line as // and adding the new member above it would also make sense

This revision is now accepted and ready to land.Jun 15 2018, 6:08 AM
sammccall added inline comments.Jun 15 2018, 6:17 AM
clangd/CodeComplete.cpp
313

oops, I made the same mistake - #bytes in the indicator != width of the indicator.

maybe making this customizable is too much hassle

ioeric updated this revision to Diff 151496.Jun 15 2018, 6:33 AM
ioeric marked 6 inline comments as done.
  • addressed review comments.
ioeric added inline comments.Jun 15 2018, 6:35 AM
clangd/CodeComplete.h
70

Ohh, didn't know this was intentional. Done.

ioeric updated this revision to Diff 151497.Jun 15 2018, 6:35 AM
  • fix typo and clang-format
ioeric updated this revision to Diff 151498.Jun 15 2018, 6:38 AM
  • clang-format again...
This revision was automatically updated to reflect the committed changes.