Youcompleteme: Enter while tabbing through completions should confirm choice

[kballenegger]

Typing enter while cycling through options using tab should confirm the choice and return focus to insert mode (such that pressing escape goes back to normal mode).

In my experience after using YCM for two days I keep fucking up two things related to this:

1. I instinctively type enter as a way of validating my choice.
2. I type escape, trying to go back to normal mode after selecting a completion, and instead end up losing my completion and remain in insert mode (usually having just typed some regular vim commands into my buffer).

Even if this is not the default (it should be IMHO), it should be a configurable option.

Thoughts?

[Valloric]

I'm not sure I understand... _Tabbing_ through the menu already confirms the choice. The currently selected item is always inserted in the buffer. No need to press enter at all.

[kballenegger]

Yes, however the focus is still on the completion menu. Ie., if, after picking a choice you press , it does not revert to normal mode, instead it removes the completion and goes back to regular insert mode.

I think that when tabbing through completions, pressing enter should:

1. Make the menu go away.
2. Keep ("confirm") the current completion.
3. Leave us in regular insert mode, so that a pressing escape goes back to normal mode.

It should not insert a newline into the buffer.

It'd solve both the problems above.

[kballenegger]

Here's a common example of what happens to me:

Imagine I'm trying to change the symbol free to cache_tree_free in this code:

free(first);
free(second);

I go on line 1, type ce and ctfr which brings up the completion which I <tab> to confirm.

My buffer now looks like this:

cache_tree_free(first);
free(second)

Now, in order to change the one below, I do this: <esc>j^.. You'd expect this to go back to normal mode, go to the beginning of the next line and repeat the change.

Instead since I haven't had a way to "confirm" my completion, YCM interprets my <esc> as a cancellation and I end up with a buffer that looks like this:

ctfrj^.(first);
free(second);

This happens to me constantly while using YCM. I've found myself using right arrows after completions to make sure I've moved past the comption and tapping <esc> like 4 times to make sure I'm _really_ in normal mode. It's very frustrating, though.

Having a way to confirm the choice (which I would map to <enter> but I'd be fine to have as a user-configurable option) would solve the problem.

[Valloric]

I can't reproduce your issue. I pasted the following lines into a buffer:

free(first);
free(second);

Then I go to the f in the first free, then do the following: ce, then ctfr, then <TAB>, then <esc>j^. I'm left with this in my buffer:

cache_tree_free(first);
cache_tree_free(second);

and I'm in normal mode.

I'm guessing this is a configuration issue on your end. Something in your vimrc maybe?

[kballenegger]

Here, I made a video of the problem:

https://www.youtube.com/watch?v=CcH2V0W4ZJo

[kballenegger]

The problem is that basically right now there is no way to confirm a selection without moving the cursor using arrow keys or typing more text.

[kballenegger]

Here's my current .vimrc by the way. I don't really have anything funky in there:

https://github.com/kballenegger/dotfiles/blob/vim-pathogen/.vimrc

[ghost]

FWIW, I can't reproduce this either

[Valloric]

Thanks for checking Chris.

Kenneth, if two people can't repro this with two separate vim confs, then I'm pretty sure it's something with your configuration/set of plugins.

[Valloric]

What version of Vim are you running BTW?

[kballenegger]

kenneth@eye:~|vim-pathogen ⇒  vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jan 11 2013 16:58:18)
MacOS X (unix) version
Included patches: 1-762
Compiled by [email protected]
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs 
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path 
+find_in_path +float +folding -footer +fork() -gettext -hangul_input +iconv 
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent 
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
+mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm +mouse_sgr -mouse_sysmouse 
+mouse_urxvt +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg 
+path_extra -perl +persistent_undo +postscript +printer +profile +python 
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent 
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
 -xterm_clipboard -xterm_save 
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X_UNIX -no-cpp-precomp  -Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.8 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1      
Linking: /usr/bin/clang   -L. -L/usr/local/lib -L/Users/kenneth/.rvm/usr/lib  -L/usr/local/lib -o vim       -lm  -lncurses -liconv -framework Cocoa     -framework Python   -lruby.1.9.1 -lobjc -L/Users/kenneth/.rvm/rubies/ruby-1.9.3-p327/lib   

[Valloric]

I'll try to find some time soon to write some workaround code for this that may help you; I'll push it to the dev branch so you can test it out. Can't promise you much since I can't repro this; it means I'll be shooting in the dark.

Probably this weekend, we'll see.

[kballenegger]

Ok I've narrowed it down to one plugin that's breaking things:

https://github.com/Townk/vim-autoclose

Autoclose is an awesome plugin that's pretty engrained in my muscle memory at this point. I'm using the latest version of the plugin, installed via a git submodule and pathogen.

[kballenegger]

That said, even if that were fixed, I would still love the ability to commit using <enter> because it's also engrained in my muscle memory from the very similar Xcode auto-completion. I keep accidentally adding newlines to my code. :(

[Valloric]

Kenneth, delimitMate does the same thing and does not break YCM (I know, because I use it).

Closing this issue because it was a configuration problem.

[kballenegger]

Awesome, thanks @Valloric, that solved the majority of my problem. Now all I gotta do is learn to not type enter.

[codemuse]

@kballenegger you can set enter to be the select key, which will make YCM almost behave like Xcode, as long as you want to select the first autocomplete option from the list at least. See also #79 and #83.

[anttikissa]

I believe this is still a valid issue. There should be a way to confirm the currently selected completion. I got frustrated when I was writing text in tabular format and I actually wanted <Tab> to indent more.

Try typing:

hello<Tab>world<Tab>he<Tab>

now suppose you want to insert an actual tab character (or an appropriate amount of spaces), instead of cycling through the alternatives. You're forced to exit the completion mode by hitting <Esc> and a, or by inserting a space and deleting it, or something like that. This is clumsy; <Enter> should suffice.

So here's my implementation for that. It maps <Enter> to <Esc> + a while completing. The only problem seems to be that if you press <Enter> and <Tab> immediately after that, it reenters the completion mode. If you wait for some time (around 0.1-0.2 milliseconds), you get the normal tab behavior. (This also seems to happen if you enter the insert mode with a when the cursor is at the end of a word, the and hit <Tab> immediately afterwards.)

https://github.com/anttisykari/YouCompleteMe/commit/98666b96010915f27a96f83967edbb5326ddfc0c