Youcompleteme: Implement argument completion/hints

[oblitum]

int foo(int a, int b, int c);
void bar(int a, int b);

bar(foo(1, 2, 3), 42);
// bar<ctrl-space> + selection brings bar's prototype into preview window:
// int bar(int a, int b);
// foo<ctrl-space> + selection brings foo's prototype into preview window, destroying previous bar completion context.
// now to fill out the remaining bar parameters after the first one, I must recall them.

clang_complete completion mechanism (+ supertab) is much nicer than this:

int foo(int a, int b, int c);
void bar(int a, int b);

bar(foo(1, 2, 3), 42);
// bar<tab> + selection *inserts* bar's call into code with traversable parameters:
// bar(<#int a#>, <#int b#>)
// foo<tab> + selection *inserts* foo's call into code with traversable parameters:
// bar(foo(<#int a#>, <#int b#>, <#int c#>), <#int b#>)
// to cycle between parameters you just go to normal mode and press tab. Then, you can just start typing to automatically enter insert mode, overwriting the selected one.
// this way, you never lose completion context for nested completions.
// there's an option to hide the characters used to surround the parameters using VIM's conceal feature, so <# and #> may not even clutter the view.

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:

set conceallevel=2
set concealcursor=vin
let g:clang_snippets=1
let g:clang_conceal_snippets=1
let g:clang_snippets_engine='clang_complete'

" Complete options (disable preview scratch window, longest removed to aways show menu)
set completeopt=menu,menuone

" Limit popup menu height
set pumheight=20

" SuperTab completion fall-back 
let g:SuperTabDefaultCompletionType='<c-x><c-u><c-p>'

http://stackoverflow.com/a/13548812

Usage of conceal is explained at clang_complete docs.

Regards.

[skogler]

+1 from me, I recently switched and I miss this a lot.

[Valloric]

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.

[meh]

Woah, that would be awesome.

[oblitum]

Cool.
Just a note, at the time I could not get UltiSnips nor SnipMate to work seamlessly as their own let g:clang_snippets_engine='clang_complete'. Their snippets engine is predictable, aways works the same, and also, personally I like the ability of cycling parameters in normal mode. I guess this simple <#, #> solution turns it more error proof than integration with other plugins. I'm not sure what can be benefited from UltiSnips/SnipMate when libclang is able to provide parameters and parameters info through CXTranslationUnit_IncludeBriefCommentsInCodeCompletion which can be leveraged in a custom crafted solution.

[oblitum]

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. <# and #>), reaching the last one is its way of assuming the ending of the filling process. So you're left to go back, select and replace the text manually.

[oblitum]

Also, that jedi-vim pic of yours is very appropriate since clang_complete currently has issues with inputting default parameters (tuple=None).

[zhaocai]

:+1 I enabled jedi-vim just for this feature.

[vheon]

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 :+1:

[RobertBuhren]

Yeah, i'd love that too!

[oblitum]

@vheon it seems like the client server architecture is already in good enough shape into master :)

[vheon]

@oblitum yeah, I notice it :) I keep waiting and I'm curious about how @Valloric will deal with this feature, although I'm not sure it will come soon.

[jsholmes]

This would be a really great feature.

[PlasmaHH]

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.

[senft]

Hey, is this something that is still worked on?

[oblitum]

@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.

[oblitum]

For anyone interested in a behavior just like clang_complete's parameter completion using g:clang_snippets_engine='clang_complete' I started a preliminary work under oblitum/YouCompleteMe/tree/clang_complete-params. The behavior can be viewed in this video:

http://youtu.be/hCI-EuptQv8
https://docs.google.com/file/d/0B0_mzHzbl3GbLUJqZW55SlRwN1k (more recent)

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.

[florian-wagner]

Am 12.03.2014 21:38, schrieb Francisco Lopes:

For anyone interested in a behavior just like clang_complete's
parameter completion using |g:clang_snippets_engine='clang_complete'|
I started a preliminary work under
oblitum/YouCompleteMe/tree/clang_complete-params
https://github.com/oblitum/YouCompleteMe/tree/clang_complete-params.
The behavior can be viewed in this video:

http://youtu.be/e7w9q99mA6I

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 make it turn 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, I have disabled the preview window in my |.vimrc| but this
branch also changes its behavior. Instead of showing overloads, since
now they all show up in the popup, it's 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 at my machine, hence I've just disabled the
preview window in my |.vimrc|.

—
Reply to this email directly or view it on GitHub
https://github.com/Valloric/YouCompleteMe/issues/234#issuecomment-37461357.

Video has been removed by the author!?

[oblitum]

@florian-wagner check the new link, I have made some updates.

[RobertBuhren]

Looks awesome. This should be merged with mainline :)

[rhlobo]

Looks great!

[rhlobo]

I am using jedi-vim together with YCM...
This way I get to use YCM and earn some extra nice features such as better argument completion (as shown in the image a few comments ago)

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"
    " }

[zyongxu]

Is the jedi-like feature abandoned or still in process?

[bbqsrc]

Any progress?

[Valloric]

This is on my TODO list, but I mostly don't have time for a large-scale feature like this. Sometimes I find some of it, but it's rare (every few months).

[danihodovic]

What is the status of this thing? Both Javascript (using Tern) and Typescript (using TSS-tools) can display function parameters when completing a function, but it still doesn't work for Python.

[oblitum]

@dani-h argument completion for javascript, etc working with YCM and Tern is unrelated to this. I use YCM and Jedi and have this, which is also unrelated, just the normal support for omnicompletion:

[danihodovic]

@oblitum oh so omnicompletion with arguments would work with Jedi installed?

Edit: nevermind you're right. thanks

[GuillaumeLeclerc]

Any progress ? :)

[senft]

@oblitum so you have YCM and jedi installed? Isn't jedi included in YCM's third_party submodules?

[oblitum]

@senft yes but afaik, the internal one is to provide support for YCM alone and not to be used/configured on its own from vimrc. To tell the truth, I didn't check this, just assumed true and it has always worked for me.

[7belrhalmia]

@Valloric any progress and you think that you will be abale to do that soon

[7belrhalmia]

@Valloric paramettre hint is the big issue in vim'a autocompletion if it solve it will be a real ide for all language

[vheon]

@7belrhalmia you should look at #1300, which is slightly different from the usual parameter completion.

[7belrhalmia]

this problem has been resolved by shugo in neocomplete he used neosnippet to create an autosnippet and inserted after completion there is example coding Go inside vim :

and that work for all languages

[vheon]

@7belrhalmia that is one approach and not a new one (Rip-Rip/clang_complete use this for example). In this and other threads there are some discussion about it. Personally I don't love this approach.

[7belrhalmia]

tell now there is no approch better than that @vheon i f you have any other approch plz tell me

[oblitum]

@7belrhalmia many approaches have been documented in the issues referred here, including that one.

I've also grown to dislike this one, formally my YCM fork for C/C++ was based on it.

[7belrhalmia]

@oblitum give me the best in your opinion that will work with Go

[vheon]

I didn't express myself in the best way, sorry: the approach that you're referring to is what I would call the "classical" approach, as I said before Rip-Rip/clang_complete use this approach since a long time ago, eclipse do it since 8 years at least (that is when I first used it the first time) and other IDE do the same. Now personally i would not love to have a parameter completion based on snippets, and the reason is that even if the snippet is done well and the names for the placeholder are significant, as soon as you start typing and the placeholder goes away you've lost information and context. Since I saw the approach proposed by @oblitum in #1300 I'm of the idea that that is a better solution for the problem.

[puremourning]

at the risk of causing a rift, i have used this approach in Xcode and like it. I think if you're comfortable with snippets (in particular Ultisnips, which integrates well with YCM), then you understand that moving around, exiting insert mode, etc. loses your context, and you go back to 1990s style text editin (^_^).

And that's what i love _most_ about @oblitum's fork is that it is not _incompatible_ with a snippet-based approach. At least not in concept. There's no reason it would be impossible to offer both (simultaneously!): Auto-expand a ( ... ) section using UltiSnips, and simultaneously offer PUM-based info suggestions per @oblitum . OK, i know this is _hard_, and switching overloads mentally is fiddly, but that's exactly what you get with Xcode.

It's also hard because it isn't obvious to me taking a look at UltiSnips how we might integrate just for the contents of (say) ( param, param, param ) but the combination of the 2 does seem like a pretty cool idea.

Now, as @oblitum says, he's tried it, so he probably knows best, so I'm just going to leave my naive idea here in case anyone is interested :)

[puremourning]

ok maybe getting UltiSnips to do it would be just a matter of calling UltiSnips_Manager.expand_anon() but "just" is a swear word in software engineering.

[7belrhalmia]

@puremourning i suggested in ultisnips reposetory but no answer :+1:

https://github.com/SirVer/ultisnips/issues/559

[7belrhalmia]

@oblitum your fork will work for Go lang

[oblitum]

@7belrhalmia no, the idea explained in #1300 is implemented for C and C++ solely.

[danihodovic]

Is there any better alternative than what @7belrhalmia suggested?

[7belrhalmia]

@dani-h if you work in python there is jedi and if you use C/C++ there is oblitum fork of youcompleteme .
But if you work in any language other than hat no there isn't . Now i work to get Ulitisnips compatible with neocompleteme , ultisnips will be better than neosnippet for that .

[danihodovic]

@7belrhalmia Nothing for Go or JS?

[oblitum]

@dani-h there's tern_for_vim for javascript, you may check my dotfiles, I have c, c++, python and javascript setup with argument hints by employing other omni-completion plugins working together with YCM.

[7belrhalmia]

yeah if you work with Go lang you have to use Vim-go , it's an excelent features for Go in vim , me i use this plugin with neocomplete and neosnnipet to get function prototype inserted .

i have this map : in my .vimrc to get tab completion :

imap neocomplete#mappings#close_popup() .
"(neosnippet_jump_or_expand)"
smap (neosnippet_jump_or_expand)

if you have any problem @dani-h just tell me i will help you

[jheroy]

@7belrhalmia how do you make neocomplete works for golang? I tried, but parameter complete not work.

[7belrhalmia]

@jheroy i assume that u have already vim-go and it works

first you have to install neosnnipet and the default snippet for neosnippet.

i have this on my .vimrc when you press tab parammetre get autocompleted
imap (neosnippet_expand_or_jump)
smap (neosnippet_expand_or_jump)
xmap (neosnippet_expand_target)
imap neocomplete#mappings#close_popup() .
"(neosnippet_jump_or_expand)"
smap (neosnippet_jump_or_expand)

[jheroy]

@7belrhalmia Thanks, but still not working. Can you share your vimrc? [email protected]

[7belrhalmia]

@jheroy

https://gist.github.com/7belrhalmia/9ac00cf134fbe90aa4f2

[7belrhalmia]

@jheroy it still there is a lots of problems with neosnippet you can use echodoc

[cyboflash]

@Valloric This is a great plugin. I've been using it for 3 years now. But it really lacks jedi-vim like completion. If it had it the plugin would just AMAZING. Is there any progress on this? I would have helped but I'm slammed with work. Is there anyone willing to help @Valloric?

[vheon]

@cyboflash do you mean something like #1300 ??

[cyboflash]

@vheon Yes. But to be sure we are taking about the same thing I mean this.

[vheon]

@cyboflash The concept is the same (kinda, for python should be basically the same) but the implementation is really different.

[cyboflash]

@vheon Oh I understand. I was simply wondering it this had already been implemented for C/C++/Objective-C in this plugin. If it has then I maybe missed the update, if not then it would be nice to this feature in the plugin. As I said before, the plugin is great. This particular feature would make it AMAZING.

[jheroy]

@7belrhalmia I found the problem, my macvim version not support v:completed_item feature. I install a new one, and it works now. Thanks!

[jheroy]

@7belrhalmia As you say, there is a lots of problem with neosnippet, so i use UltiSnips to do this, here is the code in my .vimrc:

function! MyOnCompleteDone()
    if !exists('v:completed_item') || empty(v:completed_item)
        return
    endif

    let complete_str = v:completed_item.word
    if complete_str == ''
        return
    endif
    let abbr = v:completed_item.abbr
    let startIdx = match(abbr,"(")
    let endIdx = match(abbr,")")
    if endIdx - startIdx > 1
        let argsStr = strpart(abbr, startIdx+1, endIdx - startIdx -1)
        let argsList = split(argsStr, ",")
        let snippet = "" 
        let c = 1
        for i in argsList
            if c > 1 
                let snippet = snippet. ", "
            endif
            " strip space
            let arg = substitute(i, '^\s*\(.\{-}\)\s*$', '\1', '') 
            let snippet = snippet . '${'.c.":".arg.'}'
            let c += 1
        endfor
        let snippet = snippet . ")$0"
        call UltiSnips#Anon(snippet)
    endif
endfunction
autocmd CompleteDone *.go  call MyOnCompleteDone()

To use this, make sure you vim version support v:completed_item feature.

ps: This works with neocomplete, for YouCompleteMe need replace v:completed.abbr with v:completed.menu, and init snippet with let snippet = "("

[7belrhalmia]

@jheroy good work man

[ghostec]

@jheroy I'm using macvim 7.4 and it doesn't seem to support v:completed_item. Do you know if there's any way around it?

[Shougo]

@ghostec You need Vim 7.4.774. Unfortunately, MacVim 7.4 is old version.

[jheroy]

@ghostec use brew install macvim --override-system-vim --with-lua --HEAD to install new macvim version.

[NoAnyLove]

Any progress of the parameter hint?

Currently, I'm using YouCompleteMe with jedi-vim, so I can use the parameter hint and other features like show documentation and GoTo. (The YouCompleteMe documentation preview is not as colorful as jedi-vim)

It spent me time to find out the correct configuration that won't break the jedi-vim's parameter hint. I tried the setting of @rhlobo, but it didn't work for me. The parameter hint only shows up when move the cursor out and forth. Finally I found the g:jedi#show_call_signatures_delay must set to 0, so it can work without moving the cursor.

This is my configuration for YCM and jedi-vim, wish can help someone who has the same problem.

let g:ycm_autoclose_preview_window_after_completion = 1
let g:ycm_autoclose_preview_window_after_insertion = 1
let g:ycm_use_ultisnips_completer = 1
let g:ycm_seed_identifiers_with_syntax = 1

let g:jedi#auto_initialization = 1
let g:jedi#completions_enabled = 0
let g:jedi#auto_vim_configuration = 0
let g:jedi#smart_auto_mappings = 0
let g:jedi#popup_on_dot = 0
let g:jedi#completions_command = ""
let g:jedi#show_call_signatures = "1"
let g:jedi#show_call_signatures_delay = 0

[vheon]

@NoAnyLove I don't have any updates to give you about parameters hinting, anyhow...

and GoTo

Why do you need jedi-vim for GoTo?? We support that command for pyhton.

[NoAnyLove]

@vheon, I know the GetDoc and GoTo subcommands, they works perfectly. But since I still need jedi-vim parameter hint, and it also provides the GoTo function, so I just save a little bit work to set up shortcuts for these subcommands.

[balta2ar]

Sorry if this is wrong thread to ask, but for me parameters hinting from jedi-vim is working only in vim terminal mode, but not in gvim. Is it possible to make it working in gvim as well?

[vheon]

@balta2ar if you're using jedi-vim then you should open an issue on the jedi-vim issue tracker.

[alexbyk]

Sorry if this is a wrong thread.
I miss a simple feature. When I type realloc( in C code, it would be great to see a list of arguments. How to make this work? CTRL_X CTRL_O does the job with realloc, but after typing ( all disappears. Any chances to make it work without CTRL_X + CTRL_0 and with (?

[oblitum]

@alexbyk for now there's this fork as an option: https://github.com/oblitum/YouCompleteMe. I'm still hoping to bring all that stuff in upstream.

More info about it here: http://nosubstance.me/articles/2015-01-29-better-completion-for-cpp/

[alexbyk]

@oblitum I tried you fork, and it solved a ( problem, which is good.
But now I need to type CTRL+space, without it YCM shows nothing (original version showed suggestions without CTRL+space in my config). Is that an expected behavior?

[oblitum]

@alexbyk if you have an issue you may use the fork's issue tracker. I don't suffer this problem as it's shown in the gif at the blog url.

[brglng]

I would like to propose a better approach based on @jheroy 's solution, but does not require CompleteDone, performes the snippet expansion only when ( is typed, cooperates with delimitMate, and somewhat deals with function parameters which are function pointers:

function! s:onCompleteDone()
  let abbr = v:completed_item.abbr
  let startIdx = stridx(abbr,"(")
  let endIdx = strridx(abbr,")")
  if endIdx - startIdx > 1
    let argsStr = strpart(abbr, startIdx+1, endIdx - startIdx -1)
    "let argsList = split(argsStr, ",")

    let argsList = []
    let arg = ''
    let countParen = 0
    for i in range(strlen(argsStr))
      if argsStr[i] == ',' && countParen == 0
        call add(argsList, arg)
        let arg = ''
      elseif argsStr[i] == '('
        let countParen += 1
        let arg = arg . argsStr[i]
      elseif argsStr[i] == ')'
        let countParen -= 1
        let arg = arg . argsStr[i]
      else
        let arg = arg . argsStr[i]
      endif
    endfor
    if arg != '' && countParen == 0
      call add(argsList, arg)
    endif
  else
    let argsList = []
  endif

  let snippet = '('
  let c = 1
  for i in argsList
    if c > 1
      let snippet = snippet . ", "
    endif
    " strip space
    let arg = substitute(i, '^\s*\(.\{-}\)\s*$', '\1', '')
    let snippet = snippet . '${' . c . ":" . arg . '}'
    let c += 1
  endfor
  let snippet = snippet . ')' . "$0"
  return UltiSnips#Anon(snippet)
endfunction
autocmd VimEnter * imap <expr> (
      \ pumvisible() && exists('v:completed_item') && !empty(v:completed_item) &&
      \ v:completed_item.word != '' && v:completed_item.kind == 'f' ?
      \ "\<C-R>=\<SID>onCompleteDone()\<CR>" : "<Plug>delimitMate("

[nhooyr]

@jheroy neosnippet works fine for me. What issues do you have?

[tenfyzhong]

I make a plugin for this feature, CompleteParameter. It's independent of ycm.

[puremourning]

Anyone with a string interest in this, please see and support my Vim proposal: https://groups.google.com/forum/#!searchin/vim_dev/argument$20hints%7Csort:date/vim_dev/YntCTlqdVyc/Me8uwfBpAgAJ

[skywind3000]

I come here from https://github.com/Valloric/YouCompleteMe/issues/2877 .

@puremourning I have read your RFC, it is great and I don't know how long will vim adopt that. maybe, say 2 years later ? and could we just display signature on the cmdline before that ?

If you think echo in cmdline in a background timer is dangerous, we can update cmdline only if ICursorMoved or ICursorHold happens.

https://github.com/Shougo/echodoc.vim works very well:

Echodoc has 150+ stars today, more and more people like it and use it with deoplote now.

Why are we still sitting here and arguing if it is a hack ? or waiting Bram finally introduce a second popup window after many years.

Users don't care whether it is a hack or not . At least we can have an option which is disable by default and could be enabled by users.

[puremourning]

Users don't care if it is or not a hack.

Users don’t have to build it, test it, maintain it or support it.

Why are we still sitting here and arguing if it is a hack ?

Who is arguing? Hack or not, it’s a pretty horrible UX.

Either way, I’m not sure that the tone of your response is conducive to any one of us spending the time to build it.

[skywind3000]

At least I can test for this.

[puremourning]

Sorry I didn’t understand that. Test for what?

[Miszo97]

@oblitum How can I enable these snippet completion from your fork?

[oblitum]

@Miszo97 just install/use it from scratch. Please ask anything about it on its own issue tracker. Also I don't have plans to keep merging upstream's master anymore.

[DavidUser]

Some evolution at this feature implementation?
I have a problem where preview window conflicts with Ultisnips, if YCM evolve to have a argument completion like proposed this will be the best.

[bstaletic]

The update is that Bram only a day ago responded positively to that RFC, but asked for further explanations. So I can't really say that we have moved much from square one.

[MeKot]

Hello there, I know it's not a fast process, but are there any updates on the feature?

[oblitum]

Howdy. I'm unsubscribing from this issue. I don't use YCM anymore and won't be testing fixes, so, feel free to close.

[bstaletic]

@MeKot Kind of. Bram had a poll for plugin developers asking what they need. That RFC was second highest :+1:'d request. Then on VimConf Bram explained that there are three major features on their way for vimscript:

1. Text properties
   1.1. :h textprop
2. Byte compiled vimscript
   2.1. Part 1 - https://github.com/vim/vim/pull/3857
   2.2. I think it was the first highest requested thing in the poll
3. Popup windows
   3.1 Depend on text properties
   3.2. Can be used for signature help

[skywind3000]

Popup window depends on text properties.

But the text properties haven't been updated for a long time. It seems like Bram got trouble in it.

It is a bad news if Bram needs a big refactor on text properties.

[bstaletic]

Those interested in Bram's VimConf talk can check it out here, it explains Bram's vision better than I could from memory.

[skywind3000]

I have watched the video twice before and continue keeping my eyes on it.

Text property was under rapidly development since 14 Dec. 2018, vim 8.1.0579. But suddenly stopped on 14 Jan. 2019 (Vim 8.1.0743) and never get update again.

I hope everything is going well. But it appears that Bram has some trouble in text properties.

[oblitum]

Just like to point that, nothing I've suggested/requested or considered as a problem to fix here, provided gifs, videos, etc, has anything with attacking the issue by relying on necessary additional popups cluttering the code view. As some of you already know, that's a bad route in my view, even more if it's made hard coded. This issue never suggests that as a solution. Even more given that it originally mentioned "clang_complete like".

[micbou]

I renamed the issue to make it clear it's about argument hints, not about the initial suggestion.

[oblitum]

@micbou fwiw, hints (as in #1300 for example) also don't require additional popups as solution.

[bstaletic]

@oblitum
First off, @puremourning's RFC has a rationale for why we want to pursue the two popup menus approach. People discussing argument hints here should at least read the linked RFC in detail.

As for #1300 specifically, it had a bug (oblitum/YouCompleteMe#12) that got fixed in your fork, but then your still open PR did not get an update.

Finally, this is all FOSS. One can always fork YCM or use something else.

EDIT: @puremourning's RFC also explains why we think all currently possible approaches are inferior, including the one in #1300. So please, anyone wanting to debate what is the best approach, read the linked RFC.

[oblitum]

I know all about @puremourning rationale's and have discussed about it at length on #vim, other people there also dislike the idea of popups covering code up and down like in VSCode.

My notice above has nothing to do with stopping you pursuing that. I was just pointing, this issue has never been about that, nor anything I've suggested/requested. You may simply close it and open another one, or whatever, "solve" this one when you get that merged in vim and implemented here, but surely then I'd not consider it as solved at all myself, it would just deliver another thing unasked for.

By the way, fwiw, NeoVim floating windows seems around the corner, and can be tried with coc.nvim, it's much more general idea than additional extra hard-coded popup (for those that appreciate it).

[bstaletic]

Thanks for that neovim/coc.nvim link. Bram's planned popup windows (not popup menu) should be no different than neovim's floating windows. So I don't see why coc.nvim's approach is any better than what we have planned.

[micbou]

I was just pointing, this issue has never been about that, nor anything I've suggested/requested. You may simply close it and open another one, or whatever, "solve" this one when you get that merged in vim and implemented here, but surely then I'd not consider it as solved at all myself, it would just deliver another thing unasked for.

What's the issue supposed to be about then? Argument completion through snippets? I thought that you changed your mind about it and preferred the approach described in PR #1300. By the way, the "covering code up and down" argument can also be made against that solution since it relies on the completion menu which is covering code.

[skywind3000]

@bstaletic , the development of floating window in neovim is totally out of control. it began on Apri. 2017 and last almost two years now, still in WIP status.

Floating window was scheduled to release with neovim 0.6.0. I believe that the development of floating window has become a hot potato.

NeoVim was created in early 2014, after five years NeoVim is still 0.3.x. Maybe we still need another five years for NeoVim 0.6.0.

Sadly said we can't use NeoVim's floating window before 2024.

[oblitum]

@skywind3000 are you following recent developments closely at all? I was also concerned and I've talked to main author of the pull a week back and he stated good parts have already been merged, and that it's targeted for 0.4.0, not 0.6.0. It's first time I'm learning of any plans for 0.6.0.

@micbou the issue was originally asking "clang_complete like", which is a complete different approach involving snippets, when I diverged, I've created #1300, which is about multiplexing the already available popup. Having popup up and down plus vim patches is another thing, which I don't think is the same as having one popup, simply because two is more than one. The argument still applies, and have always applied, for one alone, yes, but it's 100% stronger for two.

[oblitum]

@bstaletic

So I don't see why coc.nvim's approach is any better than what we have planned.

I didn't say it's better: "(for those that appreciate it)". I said it's more general because I thought the proposed vim patch was simply about an extra popup, and not more general floating windows.

[micbou]

the issue was originally asking "clang_complete like", which is a complete different approach involving snippets, when I diverged, I've created #1300, which is about multiplexing the already available popup.

It's still about argument completion so I don't see the problem in changing the topic of the issue to something broader. It doesn't mean that we will never implement argument completion through snippets.

[bfredl]

As a heads-up, Neovim merged the initial floating window support. Sorry about the time.

[bstaletic]

@bfredl Thanks for the heads-up. I've taken a look at neovim/neovim#6619 and, since it's an absurdly long PR, I was expecting the usual :help files to tell me what's the API. To be honest, I saw nothing useful in either doc/ui.txt or doc/window.txt.

So my questions are "how are floating windows supposed to be used?" and "have I missed the important bits and if not, will the documentation be written?"

[bfredl]

@bstaletic the docs will be in api.txt, but we need to run a command to generate them from the api sources. I will do that today, as well as add an intro text with useful hints (like how to setup buffer, change background color, and so forth).

[maximevince]

Issue from 2013, and still no viable solution, or am I missing something?
What is the proposed way to go?

[puremourning]

Issue from 2013, and still no viable solution, or am I missing something?

Yeah, we've been sitting around doing nothing for a few years, mostly so that users would come here and point out how lazy and we are. Thanks, we almost forgot about it.

But seriously, if you read the trail, and the history, we are waiting for the Vim feature that will allow us to build this feature in YCM. Read my RFC, for example for some background.

[maximevince]

I was not pointing out how lazy you are, at all. Excuse me if I was giving you this impression.
I honestly think this is a fantastic project and I really looking forward to this feature.

I just found it very hard to find a clear direction that this is going.

But thanks for the reply, I'll read your RFC and wait for the Vim feature.

[gpahlevanzadeh]

I need to complete paranthses, (python coding). How can I do it?

[oblitum]

fwiw, I'm using neovim master/nightly now, and moved to coc.nvim for a while, and it's providing arguments tips/docs on floating windows, so for anyone interested in alternatives: float window support with coc.nvim. It can be made to work as #1300, "multiplexing"/alternating completion popup and signatureHelp window (which is better for hints because of highlighting support) or with two popups, floating window up and completion popup down, through options, "preferShownAbove", completions can also be expanded into snippets carrying placeholders, like in the description of this issue, so it's 3 in 1. Should be on next NeoVim release.

[puremourning]

For anyone following this issue, work has begun based on: https://github.com/vim/vim/issues/4063

Couple of prototype tests:

[puremourning]

One more with current argument

[puremourning]

For the record I also have snippets working, though there are some frustrating limitations and it isn't really a priority for me as I don't particularly like them as an approach to completion.

[oblitum]

tip: consider aligning signatureHelp window to code when possible like in this implementation.

[puremourning]

Well placement of the pop up is certainly the trickiest part and will require some iterations.

[bstaletic]

If there is enough horizontal space, it is aligned with the first character that triggers signature help request, like ( in a function call. If there is not enough space, move the popup to the left. After watching your demo, I think, as a user, I would prefer it anchored to a single spot until the whole function call is completed.

[puremourning]

I’m personally not a fan of the either-or aproach to complettion/hints. Thanks I guess the truth is ther it is probably subjective and we need to decide how much we are willing to support in terms of optionality. I’m thinking at least initially take it or leave it, but maybe in time we can change based on user feedback.

[puremourning]

For example I think a higher priority change would be to re place the preview window with a Popup to prevent the window scrolling and autocmd issues.

[skywind3000]

Another choice , stick the popup preview window do the top-right corner.

[bstaletic]

@skywind3000
That sounds visually far away from the code one is typing, so you'd have to "chase" two things with your eyes. That said, I haven't seen how that would actually look.

[puremourning]

That said, I haven't seen how that would actually look

Try fiddling with this: https://github.com/puremourning/YouCompleteMe/blob/signature-help/python/ycm/signature_help.py#L155

e.g.

 {
    'line': 1,
    'col': vim.options[ 'columns' ] - 3,
}

If you have vim with this patch, it should put it in the very top-right (the -3 is needed!)

[oblitum]

@bstaletic on coc.nvim I have the (default) option to leave the signature help open at the top. So even though it still realigns with cursor, it feels more like the sticky behavior you say. In any case I surely prefer the highlighted parameter close to where I'll fill it. Initially my original suggestion was it to be always precisely aligned by truncating window contents, but I guess in the end coc.nvim did the best because having the contents is more relevant. Here's another example.

[puremourning]

Some more demos:

• Fixed popup location (I think my preference):

• Sliding popup:

And languages:

• Java (above)

• Go:

• Python (WIP):

[blayz3r]

Is there an option to remove the function name in the signature and have it look more like https://github.com/davidhalter/jedi-vim. Maybe just my own preference.

[bstaletic]

@blayz3r That actually doesn't seem like a bad idea.

The quick and dirty solution is to add sig_label = sig_label[ sig_label.find( '(' ) : ] below this line.

The problem with that is that it assumes that a function call looks like foo(bar), but what about lisp's (+ 2 3) or some weird language with foo[bar] (assuming that such a thing exists)?

Right now that assumption holds, but with Valloric/ycmd#1245, YCM won't be able to make that assumption and we actually need to respect the trigger characters.

[bstaletic]

Back with a better patch, though it would still fail if the trigger is something insane like (( or ... This is because we store triggers as regexes and my patch only strips leading escape characters.

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' ]

[blayz3r]

Just curious how this is going

[puremourning]

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.

[blayz3r]

@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?

[puremourning]

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)

[blayz3r]

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

[skywind3000]

Great, when will it get merged ?

[puremourning]

When it is ready. And when we have the time. Testing and feedback welcome.

[skywind3000]

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).

[bstaletic]

There's a pull request where Ben is working on the feature. To merge the PR locally do:

• cd YouCompleteMe
• git fetch origin +refs/pull/3412/merge:sig_help
• git checkout sig_help
• cd third_party/ycmd
• git fetch origin +refs/pull/1255/merge:sig_help
• git checkout sig_help

The pull request (#3412) referenced this thread.

[puremourning]

It is convenience to include it in the master and make it disabled by default, and could be enabled manually.

No. This is excruciatingly risky and we won't risk the thousands of users that don't want to test unstable stuff.

[puremourning]

it's not so hard:

cd /path/to/YCM
git remote add pm https://github.com/puremourning/YouCompleteMe
git fetch pm
git checkout signature-help
git submodule sync --recursive
git submodule update --init --recursive
./install.py --clangd-completer <usual stuff>

[skywind3000]

No. This is excruciatingly risky and we won't risk the thousands of users that don't want to test unstable stuff.

Even if it is disabled by default ?

[puremourning]

Yes.

[skywind3000]

That's fair, you are the author (Everything is up to you).

[blayz3r]

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

[puremourning]

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.

[blayz3r]

@puremourning yep python, ok cool.

Thanks for all your work on this BTW

[miallo]

it's not so hard:

cd /path/to/YCM
git remote add pm https://github.com/puremourning/YouCompleteMe
git checkout signature-help
git submodule sync --recursive
git submodule update --init --recursive
./install.py --clangd-completer <usual stuff>

Just in case anyone is just blindly copy/pasting the commands: after git remote add... you need to run git pull pm ;)

[puremourning]

git fetch pm actually.

[ghost]

it's not so hard:

cd /path/to/YCM
git remote add pm https://github.com/puremourning/YouCompleteMe
git fetch pm
git checkout signature-help
git submodule sync --recursive
git submodule update --init --recursive
./install.py --clangd-completer <usual stuff>

When I run git submodule update --init --recursive (after running sync), I get

error: Server does not allow request for unadvertised object 31d3137f9a9c1ea01f0e1b588e4dc4912adf0244
Fetched in submodule path 'third_party/ycmd', but it did not contain 31d3137f9a9c1ea01f0e1b588e4dc4912adf0244. Direct fetching of that commit failed.

[puremourning]

Try again now - I pushed some updates just now.

[skywind3000]

awesome !!

[blayz3r]

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.

[puremourning]

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.