Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Implement type/call hierarchy handling #4221

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

bstaletic
Copy link
Collaborator

@bstaletic bstaletic commented Feb 11, 2024

PR Prelude

Thank you for working on YCM! :)

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your PR:

  • I have read and understood YCM's CONTRIBUTING document.
  • I have read and understood YCM's CODE_OF_CONDUCT document.
  • I have included tests for the changes in my PR. If not, I have included a
    rationale for why I haven't.
  • I understand my PR may be closed if it becomes obvious I didn't
    actually perform all of these steps.

Why this change is necessary and useful

This is the client side pull request related to ycm-core/ycmd#1733

Again, tests and documentations are missing. Documentation is the easy part, but tests would be dreadful...

popup look

I have not paid much attention to the look of the popup.
The look is slightly off - for deep hierarchies the location of references in the file (foo.cpp:8 for example) becomes misaligned.
The context is is not right aligned either.

Basically, it's functional but ugly. If someone would be up for it, please send patches my way.

How to use this thing?

The only publicly available function here is youcompleteme#hierarchy#StartRequest( kind ). It takes 'call' or 'type' as the argyment. From there, YCM will fire a "prepare hierarchy" request and then open a popup with the results.

While the popup is open, the following keys are used:

  • <Tab> to resolve a hierarchy item in the "subtypes" / "incoming" direction.
  • <S-Tab> to resolve a hierarchy item in the "supertypes"/"outgoing" direction.
  • <Up>/<Down> to select items in the popup.
  • <CR> to jump to the selected item and close the popup.
  • <Esc> to close the popup without jumping.

Maybe we want more key bindings here? <C-n>/<C-p> and j/k come to mind...

Oh yes, there's also <plug>(YCMCallHierarchy) and <plug>(YCMTypeHierarchy) that just call youcompletem#hierarchy#StartRequest(). Users should be using these, instead of directly calling the function.


This change is Reviewable

This makes the popup disappear if you keep typing or enter inser mode or
move the cursor etc.

I found it jarring that previously it would just move the cursor behind
the popup and such until you hit escape. Makes the popup more "modal"
but without actually stopping you from continueing.

Also:

- Use simliar up/down keys as the symbol finder (c-p, c-k, c-n, c-j
  etc.)
- SetupFoo -> SetUpFoo because the verb is "To set up" (rather than the
  noun "a setup".
- purge barbaric 80+ character lines
We try to be a bit consistent with the finder poppup, but
implementation-wise this is simpler. The idea is that there are 3
columns, each having 1/3 of the popup width. We fix the width of the
popup (like we do for the finder) and set the tabstop to 1/3 of the
internal width (core_width).

Then when displaying text, we truncate "columnns" according to that
tabstop (to avoid mess). To do this, we pass structured data from the
python layer to vimscript and construct the line text there. This will
also help later when we add in the syntax highlight (text properties)
like we have for the finder popup.
This basically involves moving the properties mapping to its own place,
and creating text properties to overlap the various parts of the popup
columns. Style matches, and feels correct.

Fiddly part is that we have to (for some reason) set cursorline every
time we move the cursor, but ain't nobody gonna be able to explain why,
and why that only necessary after launching the finder popup window
once. Some wierd vim bug is my guess.
This makes the columns seem less broken, particularly for leading
whitespace. This is particularly problematic due to our use of tabstop:
if the leading whitespace was a tab, it would go nuts.

It would still go nuts for any other literal tab in the description.
Perhaps we should fix that too.
@bstaletic bstaletic force-pushed the hierarchies branch 3 times, most recently from 7e16c1f to 9d8d267 Compare May 17, 2024 04:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants