Stopping and accepting via <cr> (enter) is not possible

[fatih]

Selecting and accepting are not the same thing. We can select via this option:

ycm_key_list_select_completion

However accepting is only possible with unregular key, like esc.

I wanted to comment on this: #76 but this a common error. Basically accepting the completion via <cr> is not possible. With accepting I mean this behavior:

:h complete_CTRL-Y

When the popup menu is displayed you can use CTRL-Y to stop completion and
accept the currently selected entry. The CTRL-Y is not inserted. Typing a
space, Enter, or some other unprintable character will leave completion mode
and insert that typed character.

What everyone here wants is, that to use Enter instead of CTRL-Y. When we use Enter than a line break occurs. However we don't want a line break. We just want to stop completion and accept the selected entry. Currently only esc stop and accepts the completion.

Currently there is no settings in YCM that let us use that way. SublimeText uses Enter for accepting entries by default (and many other IDE's). Thus it's common to users that want this behavior.

There should be a setting like

ycm_key_list_accept_completion

For now I'm using a hack like this:

imap <expr> <CR> pumvisible() ? "\<c-y>" : "<Plug>delimitMateCR"

This doesn't break delimitMate's <cr> expansion and I am able to accept via <cr>. I would be happy if you could find a way to solve this problem.

[meh]

Now that is some magic, I'm gonna use it given I don't use delimitMate 👍

[fatih]

@meh I've found a way that doesn't break delimitMate too. Just updated my issue if you want to use delimitMate.

[Valloric]

People seem to have a fundamental misunderstanding of the mental model that YCM provides for selecting and accepting a completion. I'll reiterate and then I believe this horse has been beaten to death. I know I won't have anything more fruitful to add to the discussion.

What IDE's and other editors do

Let's assume you have a good IDE/editor that pops up completions as you type. So you're typing and a completion menu pops up. If you like the completions you use the <Down> arrow to select the candidate string and then press <Enter> to have that string inserted in your code.

That's how it works. Depending on the editor, other keys may be used for the above two separate actions of selecting a candidate and inserting it ("accepting it") in the code.

What YCM does

When you type, a completion menu pops up. If you like the completions, you use the <Tab> key (by default, can be changed to <Enter> or <Down> arrow or whatever) to select a completion string you want. The very act of "tabbing through" the list to select the item you want inserts the candidate string. When you tab to a different candidate, the editor code is replaced with the new candidate. There is no accept key because by the point where you have the candidate you want selected in the menu the candidate has already been inserted in the editor. There is nothing to "accept". You just keep typing, the candidate has already been inserted.

Why would you want to have an accept key? Why would you want to do two key presses to do something if the same operation can be done with just one key press?

This is the mental model of how it works. The keys can be remapped, but this is how it works. There is no accept key because it is unnecessary. I am not willing to change YCM to force the user to add unnecessary key presses just because "that's how other editors work".

There is one feature that people have mentioned wanting that is related to this and that's a key that closes the popup menu without selecting anything. Vim does not provide an easy way of doing this, but if it did, I'd add that feature.

[rgrinberg]

There is one feature that people have mentioned wanting that is related to this and that's a key that closes the popup menu without selecting anything. Vim does not provide an easy way of doing this, but if it did, I'd add that feature.

Is there really no way to do this without too much hackery? Maybe this warrants a bug report for vim?

[fatih]

You can use c-e which removes the popup.

Fatih Arslan
Sent by mobile

On 5 April 2013 Friday at 05:02, Rudi Grinberg wrote:

There is one feature that people have mentioned wanting that is related to this and that's a key that closes the popup menu without selecting anything. Vim does not provide an easy way of doing this, but if it did, I'd add that feature.

Is there really no way to do this without too much hackery? Maybe this warrants a bug report for vim?

—
Reply to this email directly or view it on GitHub (#232 (comment)).

[fatih]

Ok, then can you explain me why the popup doesn't disappear when I select (which means also accepted) an entry? The whole point here is, with accepting I make a choice. Thus the completion popup disappear. However in YCM this is not the point. After selecting and accepting, there is still the popup that doesn't disappear. Here is an screenshot of this:

The popup should disappear, but it didn't. Now I can press Esc, which will turn this into:

or I can press some other keys (like space) that creates a whitespace (which I have then remove manually):

As you see I've pressed esc or space to disappear the popup. Thus with accepting i make a choice. If you say, YCM already accepts this by selecting, then you have to make the popup disappear.

YCM only has this option:

g:ycm_autoclose_preview_window_after_completion

which is not the same. Then, in YCM way, there should be a setting like:

g:ycm_autoclose_completion_window_after_selecting

with some timeout. It still doesn't make sense, otherwise after selecting I will always a completion popup that will not disappear until I've triggered some keys.

[Valloric]

This is correct, the popup menu does not disappear after you select an item. So, after you have selected a completion candidate (and thus it was inserted in the buffer) you just continue typing. You don't worry about the popup menu closing. It will close itself when there are no completions available.

[unphased]

I really do like the "new" way of doing completion. It's quite slick.

The problem that I and many others do have, though, is some sort of mental residue and instinctive habit where we hit Enter immediately (a true reflex action) in order to make the menu (which covers up the rest of the file) disappear.

I think this might be what OP failed to specify, is that yes it's true that by tabbing or arrowing to the choice it is already in effect "accepted", it's just we still want the option to dismiss the menu without typing anything.

As such I think an option like ycm_key_list_dismiss_menu would be good to have, so we don't have to hack a map onto the key. It wouldn't necessarily affect the default workflow either, it simply changes it so that in that particular situation pressing the specified key would dismiss the window () rather than actually type it.

I actually don't understand the need for the "key that closes the popup menu without selecting anything", but this aforementioned proposed option would also cleanly accomplish that need (Hitting enter to do that though wouldnt make too much sense).

[unphased]

Oh hey. I just was able to put into words the one situation that i do often find myself in that requires "menu dismissal". That is in the situation where you have typed a variable which is a prefix of many other variables. For instance:

I have replaced whatever constructor was there (FYI, it was "Qdiwuaternion", which you can guess at how that made its way there) with "Quaternion", now I am done with the line, but I MUST NOT use the arrow keys to navigate out of the line (And I like using arrow keys to move to the next line to stay in insert mode), else it will go select a different word. Here is where I would love to hit Enter and carry on in insert mode.

[oblitum]

sorry dude, "don't leave the home keys!".

Arrows!?

I recommend anyone that think normal mode is hard to at last try turning that useless caps-lock key into something extremely useful.

[oblitum]

Personal experience, after you get used to the home keys, you'll get lazy the time you must use the arrow keys (for some stupid reason), and you'll start to wonder how others can't realize how much effort they do all the time with their full body musculature to use those pesky arrows.

[unphased]

I hear what you're saying and I do use HJKL for moving around mostly now, and I am finding myself hitting those keys in the web browser more often these days, but I have not yet committed to (nor do I forsee my wanting to) flip my Esc and Caps Lock. You see, I have Caps Lock mapped to F10, and F10 mapped to trigger many many things (by itself, next TMUX pane, With Alt/Cmd: Next TMUX window, and their shift-versions for the reverse directions): so my caps lock is getting a LOT of use out of it.

It's just that if you are editing bits of text that is in close proximity, there should be no need to exit and reenter insert mode. They are two keys that must be pressed in addition to the movement keys.

Still. I do feel like traditional keyboards are lacking a certain something for directional navigation purposes. Maybe it could work to fashion some kind of thumb-reachable d-pad joystick that is wired up to arrows.

In any case. Okay. I will try a little harder to flip between insert and normal mode.

[oblitum]

I've flipped mine, for me, it's much more fast, little finger is almost aways already over the caps-lock. Switching normal/insert is a synapse.

[unphased]

Yeah the position of Esc must be changed before it can start to flow in Vim. It's easy to hit and find but it's just too far away. I might bite the bullet and swap Esc and Caps Lock and start using Esc as my tmux switch key.

Vi was after all made for a machine whose Esc key was in the position that our Tabs are now. Either that or Caps lock. It was near there.

[oblitum]

I hope to have converted you, because I do like this, it's like empowering/extending the keyboard, because I really don't think: "oh must switch now to normal mode", it's instantaneous, I don't think this anymore, just like after learning to type or walk.

[unphased]

Yeah I mean it just makes sense. Having caps lock be switch context just makes me multitask-happy and I'm less encouraged to actually focus on getting a particular task done and just end up with way too many prompts and windows that I spread my commands over. But for vim, it actually helps to instantly go through the modes because that is how one can be super fast with it.

Edit: I just did it and I'm liking it a lot already. Esc is a good candidate for a "heavy duty" function key which is appropriate for mapping to something that switches across terminal contexts. Also the nature of switching is to repeatedly hit the key till you land on the one you want to switch to. And it is almost always just bad to hit the key accidentally. The physical position of the Esc key definitely lends itself to all these behaviors, while Esc inside of Vim is pressed so much that it should only be put next to modifier keys or Tab. Which Caps Lock is in the perfect spot for. The only shortcoming to this arrangement is that the chord Alt+Esc is much much harder to reach. So I'll have to come up with something to address that while still allowing Vim to accept the caps lock button for exiting insert mode. Which won't be hard.

Before we veer too far off topic: Seems like my solution for this issue of not being able to dismiss the YCM menu with Enter is... Use Vim properly!

[jordwalke]

Usually, when an editor uses @fatih's completion strategy, the first entry is automatically highlighted, and therefore selected when pressing a single enter key. So in practice, both paradigms only require one keyboard press to chose the entry (Either a single Enter or a single Tab). In practice, I don't see a huge advantage one way or the other, so why not just chose the one that so many other popular editors adopt (@fatih's suggestion)? The other benefit is that it doesn't collide with the popular mental model of snippets, which usually use <Tab> for not only expansion, but also jumping between snippet placeholders (which has been ingrained in users' muscle memory for thirty years of keyboard form filling).

[DelightRun]

But what if you press ESC after you select a candidate?

[magiconair]

FWIW, I regularly falling into this trap and press <Enter> to accept the choice effectively adding a new line. I may be beating a dead horse here but is there a proper config option in YCM by now to configure this or do I have to remap the key as @fatih describes?

[anadodik]

Hi, I also have the same question. I am working on a codebase which has me pressing tab for alignment after completions. However, this obviously only cycles through the completion list. I would find it nice if this option was added. I have also experienced the problem @unphased is referencing.

[puremourning]

Does using ctrl-y work for you?

[anadodik]

Yes, but I have to press it twice for some reason. Also pressing enter is more intuitive for me personally than ctrl-y. Is there a way to remap enter to ctrl-y, and still be able to use enter in the usual situations? I tried what @fatih suggested, but that didn't work for me properly.

And regarding the first issue, does anybody know why I might need to press ctrl-y twice for the menu to disappear? The first time it reduces to only the currently selected option, and the second time it disappears, but I feel like this should be just one press.

[jondot]

@Valloric thanks for YCM!. The reason IDEs typically do this is to allow for fuzzy matching. so to match foobar.AppRegistry i could type foobar.AR.

It's possible to do this with YCM by emptying out the completion triggers and using arrow keys, or mapping (c-j, c-k) to the arrow keys, with this script i grabbed from somewhere and hacked around:

let g:ycm_key_list_select_completion=[]
let g:ycm_key_list_previous_completion=[]
function! OmniPopup(action)
    if pumvisible()
        if a:action == 'j'
            return "\<Down>"
        elseif a:action == 'k'
            return "\<Up>"
        endif
    endif
    return a:action
endfunction

[puremourning]

If you type foobar.AR ycmd will suggest AppRegistry by using what you call fuzzy matching. (Indeed word-boundary characters and longest common subsequence match).

I'm not sure i see how that is related to this.

[mkrahal]

For those still struggling with this, you can re-map the enter key to ctrl-y while still being able to use enter in regular situations (i.e to return to line or create new blank lines) by adding the following to .vimrc:

inoremap <expr> <CR> pumvisible() ? "\<C-Y>" : "\<CR>"

This will remap the enter key to ctrl-y in 'insert mode' only when the pop-up menu is visible. Thus still allowing for normal behavior when the pop-up menu is not visible.

[ajkhoury]

@mkrahal Thank you!

[ktmud]

@mkrahal Thank you indeed! It amazes me that people are still struggling with this after 4 years!

[drbeco]

@unphased wrote:
Oh hey. I just was able to put into words the one situation that i do often find myself in that requires "menu dismissal". That is in the situation where you have typed a variable which is a prefix of many other variables. For instance:

[...CUT / IMAGE / ...CUT]

example for illustrating need for dismissal key for ycm
I have replaced whatever constructor was there (FYI, it was "Qdiwuaternion", which you can guess at how that made its way there) with "Quaternion", now I am done with the line, but I MUST NOT use the arrow keys to navigate out of the line (And I like using arrow keys to move to the next line to stay in insert mode), else it will go select a different word. Here is where I would love to hit Enter and carry on in insert mode.

That is exactly my problem. I like to contemplate the code one UP, one Down, here and there, while thinking, and my hand is definitely not in "home" (I'm not typing, just aimlessly looking around a line or two).

One of the advantages of the arrow is just that: you move without changing to normal mode. I am a stronger believe of the "hands-in-home" and all that stuff, but I am also very open-minded on how each one uses vim.

To solve this problem, I would like to "remap" the arrows to their prior tasks and let them ignore completely the pop-up menu. I prefer to use <TAB> and <S-TAB> to select the menu. Also, I don't like the idea of remapping <CR> to <C-Y> because I agree that once I've selected, I could just keep typing (<ENTER> inclusive).

So, to summarise, how to accomplish:

• <ARROWS> are <ARROWS> (and ignore/dismiss the menu)
• <TAB> and <S-TAB> move the selection (and only they do)

(and <ENTER> is the way it is already, no need to change)

Someone has a magic trick for that? ☺️

[drbeco]

I'm trying to figure that out, but this code doesn't seem to help (commit d0223a8)

@Valloric or @mkrahal, do you got anything in your sleeves to help disable arrows at all?

PS. Yes, I read that:

 +
 +  " Basically, we need to only trigger the completion menu when the user has
 +  " inserted or deleted a character, NOT just when the user moves in insert mode
 +  " (with, say, the arrow keys). If we trigger the menu even on pure moves, then
 +  " it's impossible to move in insert mode since the up/down arrows start moving
 +  " the selected completion in the completion menu. Yeah, people shouldn't be
 +  " moving in insert mode at all (that's what normal mode is for) but explain
 +  " that to the users who complain...
 +  if !s:BufferTextChangedSinceLastMoveInInsertMode()
 +    return
 +  endif
 +

But I just want to disable the arrows altogether if possible. Thanks!

---

Edited:

The oppose of what is proposed in issue #83
Reference: #79

[drbeco]

🤔 Maybe disabling the arrows is as simple as:

let g:ycm_key_list_select_completion = ['<TAB>']
let g:ycm_key_list_previous_completion = ['<S-TAB>']

I'll check that.

---

Edited:
Nope, the arrows still wants the menu.

[drbeco]

New attempt: I've tried this settings:

inoremap <expr> <CR> pumvisible() ? "\<C-Y>" : "\<CR>"
inoremap <expr> <UP> pumvisible() ? "\<C-Y>" : "\<UP>"
inoremap <expr> <DOWN> pumvisible() ? "\<C-Y>" : "\<DOWN>"

But although the arrows do not move inside the menu anymore, the menu itself won't close. It get stuck. The cursor also won't move. Also <CR> won't close the menu either. It is stuck, with a visible blinking of the menu each time I press.

If I hold down the arrow for a few moments, the menu blinks a lot but at some point the arrow takes over and is able to move the cursor away from that unholy position!

[drbeco]

OK! GOT IT! 😆

let g:ycm_key_list_select_completion = ['<TAB>']
let g:ycm_key_list_previous_completion = ['<S-TAB>']
let g:ycm_key_list_stop_completion = ['<C-y>', '<UP>', '<DOWN>']

Wow! That is perfect! You guys should try it! Lovely!

Case solved. You can double-close this issue now.

[0x000bff]

@drbeco thank you!

A little late here but:
let g:ycm_key_list_stop_completion = ['<C-y>', '<CR>']
gives the behavior I was looking for (closes completion popup on Enter and frees up the arrow keys).