ycm-core / YouCompleteMe

A code-completion engine for Vim
http://ycm-core.github.io/YouCompleteMe/
GNU General Public License v3.0
25.45k stars 2.81k forks source link

field suggestions for struct types without prefix not appearing anymore #3586

Closed valentin-krasontovitsch closed 4 years ago

valentin-krasontovitsch commented 4 years ago

Issue Prelude

Thank you for adhering to this process! It ensures your issue is resolved quickly and that neither your nor our time is needlessly wasted.

Issue Details

I recently updated my go version to 1.13 and started using modules. this prompted me to update ycm, since something seemed broken (completion didn't quite work anymore). after not being able to get completion to work as i was used to, i resorted to trying a clean and newest setup, without fixing the problem.

Include steps to reproduce here.

set nocompatible              " be iMproved, required
syntax on
filetype off                  " required
set rtp+=~/.vim/bundle/Vundle.vim/
call vundle#begin()

Plugin 'VundleVim/Vundle.vim'

Plugin 'Valloric/YouCompleteMe'
Plugin 'airblade/vim-gitgutter'
Plugin 'fatih/vim-go'

call vundle#end()            " required
filetype plugin indent on    " required

set splitbelow

main.go

package main

import "fmt"

type wee struct {
        something string
        rain string
}

func main() {
        hello := wee{*}
        fmt.Println(hello)
}

I expected the suggested completions to be precisely the fields of the defined struct type

I got a bunch of generic completion suggestions from the global namespace, like for instance

Include description of the observed behaviour, including actual output, screenshots, etc.

see screenshot here:

image

Diagnostic data

Output of vim --version

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 29 2020 16:06:12)
macOS version
Included patches: 1-172
Compiled by valkra@val-imac.local
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       -tcl
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
-balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            +netbeans_intg     +termresponse
-browse            -gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     +perl              +title
+cindent           +job               +persistent_undo   -toolbar
-clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           -python            +visual
+comments          +linebreak         +python3           +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        -lua               +ruby              +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con        +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       -X11
+digraphs          +mouse             -sound             -xfontset
-dnd               -mouseshape        +spell             -xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        -mouse_gpm         +statusline        -xsmp
+eval              -mouse_jsbterm     -sun_workshop      -xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
 f-b for $VIMRUNTIME: "/usr/local/share/vim/vim82"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -fstack-protector -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/libksba/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/libksba/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/openssl/lib  -L/usr/local/lib -o vim        -lncurses  -liconv -framework AppKit   -mmacosx-version-min=10.12 -fstack-protector-strong -L/usr/local/lib  -L/usr/local/Cellar/perl/5.26.1/lib/perl5/5.26.1/darwin-thread-multi-2level/CORE -lperl -lm -lutil -lc  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation  -lruby.2.3.0 -lgmp -lobjc -L/Users/valkra/.rvm/rubies/ruby-2.3.0/lib

Output of YcmDebugInfo

Printing YouCompleteMe debug information...
-- Client logfile: /var/folders/l1/3bxz7mdn0c79_gzvjvs0h6b00000gn/T/ycm_wpj5kol5.log
-- Server Python interpreter: /usr/local/opt/python/bin/python3.7
-- Server Python version: 3.7.6
-- Server has Clang support compiled in: False
-- Clang version: None
-- No extra configuration file found
-- Go completer debug information:
--   gopls running
--   gopls process ID: 85431
--   gopls executable: ['/Users/valkra/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/go/src/golang.org/x/tools/cmd/gopls/gopls', '-logfile', '/var/folders/l1/3bxz7mdn0c79_gzvjvs0h6b00000gn/T/gopls_stderrxi_x_3_d.log']
--   gopls logfiles:
--     /var/folders/l1/3bxz7mdn0c79_gzvjvs0h6b00000gn/T/gopls_stderrxi_x_3_d.log
--   gopls Server State: Initialized
--   gopls Project Directory: /Users/valkra/go/src/gitlab.mgmlab.net/golang/ngsqcrest
--   gopls Settings: {
--   "fuzzyMatching": false,
--   "hoverKind": "Structured"
-- }
-- Server running at: http://127.0.0.1:58834
-- Server process ID: 85428
-- Server logfiles:
--   /var/folders/l1/3bxz7mdn0c79_gzvjvs0h6b00000gn/T/ycmd_58834_stdout_dgt5g046.log
--   /var/folders/l1/3bxz7mdn0c79_gzvjvs0h6b00000gn/T/ycmd_58834_stderr_7ca8p4vc.log

Contents of YCM, ycmd and completion engine logfiles

gist with logs for ycm, ycmd, and gopls

OS version, distribution, etc.

macos high sierra 10.13.6

valentin-krasontovitsch commented 4 years ago

@puremourning hey ben, sorry about posting an incomplete issue prematurely - i've completed it all now, hopefully as required.

would you mind reopening the issue please?

puremourning commented 4 years ago

Of course ! Thanks.

bstaletic commented 4 years ago

Considering that vim-go also does completion and also uses gopls, this issue could easily be a conflict.

valentin-krasontovitsch commented 4 years ago

Thanks a lot! I’m still confused about who does what - gonna try and reproduce without gopls.

Does the expected behavior I describe sounds familiar though, in the sense of being a feature of ycm? Is what I expect even understandable?

On Fri, 31 Jan 2020 at 21:47, Boris Staletic notifications@github.com wrote:

Considering that vim-go also does completion and also uses gopls, this issue could easily be a conflict.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ycm-core/YouCompleteMe/issues/3586?email_source=notifications&email_token=ADZR2BN4LHR6PQKQ4CZI6R3RASE6FA5CNFSM4KOHI77KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKP6RHI#issuecomment-580905117, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZR2BKOHKEOEX3JAQ7NT2LRASE6FANCNFSM4KOHI77A .

bstaletic commented 4 years ago

There's a ton of overlap between YCM and vim-go. We're talking about completion and both plugins do it. I have no idea how vim-go works, but YCM assumes that it owns the completion menu and :h 'completefunc'. Even if there's no actual conflict between plugins, it's possible that gopls just isn't smart enough to give you the expected completions.

puremourning commented 4 years ago

Yeah vim-go has a philosophy of doing everything including completion so it’s not compatible with other completion systems like YCM.

Tbh I’m not even sure YCM would trigger semantic completion at that point in the file.

Can you please try without vim-go and gitgutter so the case is actually minimal?

valentin-krasontovitsch commented 4 years ago

There's a ton of overlap between YCM and vim-go. We're talking about completion and both plugins do it.

Yeah vim-go has a philosophy of doing everything including completion

Hmm I see - I really don't know precisely who is doing what, and after some quick test I just assumed that it was YCM. I'm going to try to investigate more, and in particular figure out how to see completion results with vim-go.

In the meantime, a trial without vim-go and gitgutter (removed from vimrc and deleted from bundle category) gave the same result.

Tbh I’m not even sure YCM would trigger semantic completion at that point in the file.

I see - I don't know if it's difficult to describe in a language agnostic way, but let me try:

I have a (struct) type defined, and in the same scope, I'm initiating a variable of said type, and once I'm syntactically in the unique place for setting fields that are part of the type, without entering any prefix, I would like to autocomplete to the fields of the struct type. does that make sense?

Trying to find other examples, I see that you usually have some symbol that would trigger semantic completion in such a context, like a period. Is it possibly as simple as allowing semantic completion at an empty prefix / without a trigger prefix? hope that makes sense... I sadly understand very little of how completion works under the hood, so I apologize for any confusion

valentin-krasontovitsch commented 4 years ago

ya OK after reading a bit on how to toggle completion with vim-go (turns out it's ctrl-x ctrl-o) it seems like the behaviour i was experiencing was indeed due to vim-go. hmm. there I indeed get, well, not only the struct fields, but the struct fields come as first suggestions, with the general stuff below...

I guess i'm gonna close this, thank you for the help and support!

bstaletic commented 4 years ago

Trying to find other examples, I see that you usually have some symbol that would trigger semantic completion in such a context, like a period. Is it possibly as simple as allowing semantic completion at an empty prefix / without a trigger prefix? hope that makes sense... I sadly understand very little of how completion works under the hood, so I apologize for any confusion

YouCompleteMe does allow configuring this behaviour. You can use <C-Space> to force semantic completion and you can also configure g:ycm_semantic_triggers.

valentin-krasontovitsch commented 4 years ago

Thank you for the pointers! I was using Ctrl-Space to trigger completion, and your comments means that what I was getting was semantic completion.

the value of g:ycm_semantic_triggers is just {} for me in a go file.

hmm I'm gonna have to dive a bit deeper and figure out how to get a behaviour that I would like... thanks again!

puremourning commented 4 years ago

I can confirm the behaviour you see regarding completion.

I tried in VScode too and it behaves the way you expect. I suspect this difference is because vscode-go uses gocode by default and we use gopls.

SO I found these instructions which said to set "go.useLanguageServer": true,

Setting that, I get the same behaviour in vscode. So this is a gopls limitation, nothing YCM can do about that.

FWIW I get the same result with master of gopls.

valentin-krasontovitsch commented 4 years ago

oohh thanks a lot for testing and confirming that!

so basically one could say that if one desired the described behaviour, one should revert to using gocode instead of gopls, or investigate whether some changes can be made to gopls to get the desired behaviour? perhaps upstream at gopls, this is a feature rather than a bug...

or could one just pipe together / fix the settings to use both gopls and gocode, or godef and go doc where appropriate? would prefer to have something "working out of the box", of course, for my personal preference of "working" ; )

puremourning commented 4 years ago

I'm not sure what exactly you're asking, but YCM uses gopls. We're not going back to gocode.

So yes, try asking the gopls people.

valentin-krasontovitsch commented 4 years ago

I assumed that you could perhaps "choose" the completion command/engine for go completion using some option - based on your comment, that assumption was obviously wrong : D

gonna direct my attention to gopls then. thanks again for the support, I really appreciate it!