Page MenuHomePhabricator

[clangd] Rearrange type, returntype and parameters in hover card
ClosedPublic

Authored by kadircet on Jan 13 2020, 8:25 AM.

Details

Summary

Moves type/returntype into its own line as it is more readable in cases
where the type is long.

Also gives parameter lists a heading, Parameters: to make them stand out.

Leaves the right arrow instead of Returns: before Return Type to make
output more symmetric.

function foo

Returns: ret_type
Parameters:
- int x

vs

function foo

🡺 ret_type
Parameters:
- int x

Diff Detail

Event Timeline

kadircet created this revision.Jan 13 2020, 8:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 13 2020, 8:25 AM

Unit tests: unknown.

clang-tidy: unknown.

clang-format: unknown.

Build artifacts: diff.json, console-log.txt

sammccall accepted this revision.Jan 13 2020, 10:22 AM
sammccall added inline comments.
clang-tools-extra/clangd/Hover.cpp
535

Comment needs updating

551

consider , which would be short and symmetrical with the arrow for return type...

Too obscure?

This revision is now accepted and ready to land.Jan 13 2020, 10:22 AM
kadircet updated this revision to Diff 237888.Jan 14 2020, 2:05 AM
kadircet marked 2 inline comments as done.
  • Address comments and rebase on top of ruler patch
clang-tools-extra/clangd/Hover.cpp
551

it is a good way to make the output shorter, not sure about the symmetry though as type and returntype never show up in the same hovercard.
but I believe it is too obscure.

Unit tests: unknown.

clang-tidy: unknown.

clang-format: unknown.

Build artifacts: diff.json, console-log.txt

sammccall accepted this revision.Jan 14 2020, 2:26 AM
sammccall added inline comments.
clang-tools-extra/clangd/Hover.cpp
528–529

as discussed offline, better IMO to allow the middle section to be empty, emit both rulers, and fix it in post :-)

551

The symmetry I mean is two kinds of hover cards for functions vs values that when scanned have approximately the same layout (type information is introduced by a similar-sized symbol) but can still be distinguished.

but I believe it is too obscure.

:-( fair enough

lh123 added a subscriber: lh123.Jan 14 2020, 3:26 AM

I think the character "🡺" should be avoided, as it may not display properly in some environments.

kadircet updated this revision to Diff 238244.Jan 15 2020, 6:50 AM
kadircet marked 3 inline comments as done.
  • Rebase

I think the character "🡺" should be avoided, as it may not display properly in some environments.

I believe most of the editors should be able to display unicode characters, please let us know if you've got any concrete examples of corrupt rendering.

This revision was automatically updated to reflect the committed changes.

Unit tests: unknown.

clang-tidy: unknown.

clang-format: unknown.

Build artifacts: diff.json, console-log.txt