-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Implement argument completion/hints #234
Comments
+1 from me, I recently switched and I miss this a lot. |
Agreed, something like this needs to be added (and will). I've talked about this in issue #36. An even better system would be having something like what's present in jedi-vim (which works only with Python code) where the parameter types are placed above the current line. See the very bottom of this screenshot: AFAIK this is a massive hack enabled by heavy abuse of Vim's conceal feature, but if it ends up working the way I envision it, then I'm willing to hack my way to this functionality. If that does not end up working well, I'll be going with what clang_complete does by leveraging UltiSnips. |
Woah, that would be awesome. |
Cool. |
My opinion is that those plugins are sure good for code snippets, but not so well targeted for parameters. One issue with UltiSnips for example is that if you mistakenly traverse to the last parameter without filling a previous one, it's game over, you can't go back in the parameter list because it's not based on special matches (e.g. |
Also, that jedi-vim pic of yours is very appropriate since clang_complete currently has issues with inputting default parameters ( |
:+1 I enabled jedi-vim just for this feature. |
Any news about the jedi like feature? I know that @Valloric want to do a Client Server architecture with YouCompleteMe so I imagine that he is preoccupied with something else at the moment, but I'd love to see something like that in YouCompleteMe 👍 |
Yeah, i'd love that too! |
@vheon it seems like the client server architecture is already in good enough shape into master :) |
This would be a really great feature. |
This is indeed a feature I am missing from clang_complete. In the meantime, what would improve the situation a bit at least for me, would be to include all overloads of a function in the dropdown list, so that we can at least see there are some. Using the preview window for that is really ugly. |
Hey, is this something that is still worked on? |
@PlasmaHH implementation for argument completion to work like clang_complete would probably need to list overloads in popup, instead of the way it's implemented now. |
For anyone interested in a behavior just like clang_complete's parameter completion using http://youtu.be/hCI-EuptQv8 It's just the same simple but fast parameter completion approach. Right now it's just a patch over the original YCM's ClangCompleter, if I turn it into something more modular I'll try a pull-request but for now it serves as a preview. Since I'll keep using it I'll make fixes if I find dirty corners. Also the preview windows instead of just showing overloads, since now they "all" show up in the popup, it's also supposed to show brief comments with the accompanying prototype. But so far, even trying to enable all libclang flags to get these brief comments, I was unable to make them show up here in my machine. If anyone can help with extracting brief comments (if it's working in libclang anyway) I would appreciate. |
Am 12.03.2014 21:38, schrieb Francisco Lopes:
|
@florian-wagner check the new link, I have made some updates. |
Looks awesome. This should be merged with mainline :) |
Looks great! |
I am using jedi-vim together with YCM... In order to prevent conflicts, I disable most of jedi-vim that is related to completion: " jedi-vim {
let g:jedi#auto_vim_configuration = 0
let g:jedi#popup_on_dot = 0
let g:jedi#popup_select_first = 0
let g:jedi#completions_enabled = 0
let g:jedi#completions_command = ""
let g:jedi#show_call_signatures = "1"
let g:jedi#goto_assignments_command = "<leader>pa"
let g:jedi#goto_definitions_command = "<leader>pd"
let g:jedi#documentation_command = "<leader>pk"
let g:jedi#usages_command = "<leader>pu"
let g:jedi#rename_command = "<leader>pr"
" } |
@blayz3r That actually doesn't seem like a bad idea. The quick and dirty solution is to add The problem with that is that it assumes that a function call looks like Right now that assumption holds, but with ycm-core/ycmd#1245, YCM won't be able to make that assumption and we actually need to respect the trigger characters. |
Back with a better patch, though it would still fail if the trigger is something insane like diff --git a/ycmd/completers/completer_utils.py b/ycmd/completers/completer_utils.py
index 1e1a86bc..d8709b33 100644
--- a/ycmd/completers/completer_utils.py
+++ b/ycmd/completers/completer_utils.py
@@ -66,6 +66,12 @@ class PreparedTriggers( object ):
self._filetype_to_prepared_triggers = final_triggers
+ def GetTriggerCharactersForFiletype( self, filetype ):
+ trigger_regex_set = self._filetype_to_prepared_triggers[ filetype ]
+ return [ trigger.pattern.lstrip( '\\' ) for trigger in
+ self._filetype_to_prepared_triggers[ filetype ] ]
+
+
def SetServerSemanticTriggers( self, server_trigger_characters ):
self._server_trigger_map = {
','.join( self._filetype_set ): server_trigger_characters
diff --git a/ycmd/completers/language_server/language_server_completer.py b/ycmd/completers/language_server/language_server_completer.py
index 87071427..0f4ba889 100644
--- a/ycmd/completers/language_server/language_server_completer.py
+++ b/ycmd/completers/language_server/language_server_completer.py
@@ -1058,6 +1058,20 @@ class LanguageServerCompleter( Completer ):
response = self.GetConnection().GetResponse( request_id,
msg,
REQUEST_TIMEOUT_COMPLETION )
+ result = response[ 'result' ]
+ filetype = self._CurrentFiletype( request_data[ 'filetypes' ] )
+ trigger_characters = (
+ self.signature_triggers.GetTriggerCharactersForFiletype(
+ filetype ) )
+ for sig in result[ 'signatures' ]:
+ sig_label = sig[ 'label' ]
+ indices = []
+ for trigger in trigger_characters:
+ index = sig_label.find( trigger )
+ if index != -1:
+ indices.append( index )
+ sig_label = sig_label[ min( indices ) : ]
+ sig[ 'label' ] = sig_label
return response[ 'result' ]
|
Just curious how this is going |
work in progress. you can use it (it's totally stable) using my signature-help branch of YCM. I use it every day, but I'm willing to tolerate some jankiness. The hardest thing to get right is the popup placement and that's where the most work is required. |
@puremourning thanks for the update, I'll take it for a spin. One thing I wasn't clear on: Does Vim allow the signature to have syntax highlighting? |
You mean in the popup ? In theory yes (the popup is a buffer), but tbh I don't see how that would mix well with the PMenu highlight groups, and without that there would be no contrast. I'm completely against using borders for this, so that sort of rules it out. But I suppose it is something worth trying (feel free to play with python/ycm/signature_help.py:UpdateSignatureHelp) |
Great thanks |
Great, when will it get merged ? |
When it is ready. And when we have the time. Testing and feedback welcome. |
It is convenience to include it in the master and make it disabled by default, and could be enabled manually. I believe this is much easier for users to test, and you can collect more feedbacks. Rather than leaving it in other branches. (no body knows there is a branch). |
There's a pull request where Ben is working on the feature. To merge the PR locally do:
The pull request (#3412) referenced this thread. |
No. This is excruciatingly risky and we won't risk the thousands of users that don't want to test unstable stuff. |
it's not so hard:
|
Even if it is disabled by default ? |
Yes. |
That's fair, you are the author (Everything is up to you). |
Took it for a spin and it looks promising, only comment is that having the function name repeated in the signature threw me off a bit I believe there is a patch here. Just my 2 cents. I am curious if having the name in the signature helps or hurts the popup placement issue |
I assume you're talking about python ? If so having the function name there makes it consitent with all of the language servers i've tested, which i think is better because it's even more jarring when it looks different in different languages. |
@puremourning yep python, ok cool. Thanks for all your work on this BTW |
Just in case anyone is just blindly copy/pasting the commands: after |
|
When I run
|
Try again now - I pushed some updates just now. |
awesome !! |
Been using this and it is working way better than I expected. Thanks everyone who worked on this and for taking the time to get it right. |
Thanks for your kind words 😊. wouldn’t have been possible without Incredible work from @brammool and @bstaletic And not to mention all the language server authors. |
clang_complete completion mechanism (+ supertab) is much nicer than this:
This video (at time 2m30s) illustrates how this parameter completion works.
And this is a GIF from a fork that patches YCM to provide this:
I guess this behavior turns the extra preview window popup completely unnecessary, and hence, discarding it provides yet one more feature: less interface cluttering. So it's both cleaner and more powerful.
I'm willing to switch to YCM, but still, without this, I feel it doesn't obsoletes clang_complete. It's the single thing that I very miss.
This is the clang_complete/supertab config for that:
http://stackoverflow.com/a/13548812
Usage of conceal is explained at clang_complete docs.
Regards.
The text was updated successfully, but these errors were encountered: