[RFC] Improve call signatures setup

[blueyed]

Came up with it while looking at #651.

TODO:

• with mode 1, it will trigger indenting when adding : after %i: - likely due to the concealed text being used (addressed in WIP: use b:_jedi_callsig_orig to get original line contents Vimjas/vim-python-pep8-indent#98):

               (value, ..., sep, end, file, flush)                                
  print('sig %i: %r' % (signatures,))                                             
  

• doc

[blueyed]

Well, this got huge

• undo and resetting should be working properly/better.
• timers support
• call signatures in normal mode
  Via new/experimental setting g:jedi#show_call_signatures_modes (not yet documented).
  To configure signatures in normal and insert mode, use 'ni'. The default is 'i' (insert mode only).
  It can be set through jedi#configure_call_signatures(), e.g. to have them in normal mode only:
  :call jedi#configure_call_signatures(1, 'n')

[davidhalter]

I will have to test this. But be aware that I'm also trying to release a new Jedi version and that has a slightly higher priority. Expect a delay of like 1-2 months.

[blueyed]

@davidhalter
Yeah.
I am test-driving this myself currently, and hope others might do so already (I've pinged some issues).

It is really sweet, since I can use 1 instead of 2 again, and I am really liking the overlay in normal mode!

The heart of it seems to be 80caf43, which uses undojoin and restoring of the previous lines literally instead of by replacing them back. AFAICS it is not possible to change those lines, except for some <c-o> magic etc..

I don't like too wait for too long merging this though - while I can see and appreciate the Jedi work you are doing, you should just use this jedi-vim branch while working on it, and report any issues here.. :)

(I really feel like we should have (fixed) tests for this (sadly all PRs are red currently in general). Don't feel too bad about it though - eventually I'll probably fix the current tests)

[davidhalter]

while I can see and appreciate the Jedi work you are doing, you should just use this jedi-vim branch while working on it, and report any issues here.. :)

You're probably right. My overall laziness is just getting ahead of me.

[davidhalter]

I'm now using it locally. Before I've had so many issues with Jedi that it would not have made sense to destabilize one more thing :)

[davidhalter]

My first impression is that it works really well except for that one strange case, I never seem able to reproduce. Sometimes the call signature won't disappear.

Do you have no issues at all?

[blueyed]

@davidhalter
Sorry, I was not using this branch currently.. apparently I got used to it not working properly in Neovim, and therefore did not miss it.. ;)
Will use it now again (and have it rebased on master).

What settings are you using?
Are you changing g:jedi#show_call_signatures_modes / g:jedi#show_call_signatures_delay?
I assume you're using Vim with timers?
Are they staying when removing insert mode?

[davidhalter]

I'm using pretty much the basic settings (at least concerning call signatures) and have otherwise not modified much.

I assume you're using Vim with timers?

What are timers?

[blueyed]

The timer feature, which this is based on (:echo has('timers')).

[davidhalter]

:echo has('timers')
0

[blueyed]

That's an old Vim then.. and different code paths that I am using.
Try to figure out the pattern when they do not go away, i.e. is is when you're moving to another line in insert mode, leaving insert mode, etc.

[davidhalter]

I'm on it. It's pretty weird. It looks like happens within tuples in function calls.

[blueyed]

@davidhalter
Pushed some fixes, should work better.

For one, I had problems with lazy-loading on InsertEnter: the completion would show up, but then it was removed again.. (since deoplete appeared to call jedi-vim's omnifunc, which then cleared the signatures again).

[davidhalter]

I was just able to reproduce the error but now it's gone again thanks to your changes. I'm testing.

[davidhalter]

I have had issues, but it wasn't as bad anymore. Apart from that I think your PR also indirectly uncovered a VIM issue :/

Vim: Caught deadly signal SEGV
*** Error in `vim': corrupted double-linked list: 0x0000562d7e4f1d00 ***
                                                                        Segmentation fault (core dumped)

[blueyed]

Thanks for trying it already!
I have found some issues myself, and will update it later.

[blueyed]

Pushed some fixups from my local changes, but it's still WIP.

The only issue I've seen recently was that conceallevel was not set under some circumstances.

[davidhalter]

Hmm it's strange. My VIM 7.4 still sometimes fails with segmentation faults. This is obviously not your fault. It's something the VIM maintainers should care about. However it's probably still not a good idea to merge this, until this issue is resolved.

I cannot exactly reproduce it, but it looks like it happens when both completion and call signatures are active. It has probably to do with the undo stuff.

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:44:48)
Included patches: 1-1689
Extra patches: 8.0.0056