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

add a jedi#show_call_signatures mode for displaying under the function, but in the buffer #903

Closed
towc opened this issue Jan 26, 2019 · 5 comments

Comments

@towc
Copy link

towc commented Jan 26, 2019

Issue

The only mode for showing call signatures in the buffer does it before your cursor, and I hate it when the thing I'm editing moves around as I edit it.
If the signature is longer than the line (which is common when working with frameworks, or small terminals), vim will make the line I'm editing go down quite a bit, and it's really disrupting.
This can also be fixed by disabling line wrapping in vim itself, but that will affect other parts of most people's workflow

image

My suggestion is to add a mode for getting the signature to be displayed just below the cursor, or as a list, so it can be used similarly to autocompletion functionality

@towc
Copy link
Author

towc commented Jan 26, 2019

as a less relevant side-note, and possibly a side-issue (that I'm personally not worried about), is that ale linting gets confused by this display method (as shown by the red arrow in the sign column)

@blueyed
Copy link
Collaborator

blueyed commented Jan 27, 2019

There is g:jedi#show_call_signatures = 2 to display it in the command line.
With Neovim it could also use its virtual text feature (#891), but that would display it at the end of the current line (which would be fine/great for editing the end of a line, of course).

@towc
Copy link
Author

towc commented Jan 27, 2019

the command line is very far from the function usually :/ It's still a possibilty, but this would be very nice to have either way

@davidhalter
Copy link
Owner

IMO this is just one more case that we have to support and will likely just not properly test, I'm against this for maintenance reasons.

Sorry at @towc, but I really feel like this is such a big hack already and making it even bigger makes it just worse. If we can ever properly write to the screen I'm all yours.

@blueyed
Copy link
Collaborator

blueyed commented Feb 19, 2019

btw: #652

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants