An universal setting for mapping <CR> to closing the completion popup and after use the DiscretionaryEnd?

[bbtdev]

So in all autocompletion plugins I tried I'm having a problem, I have to press Enter two times when the completion popup is visible, to go to the next line.
Doing "do... end" is annoying, and I tried multiple hacky ways but I can't find a solution. I'm sure some folks got confronted by this. Any solutions found?

[bluz71]

A solution is mentioned in issue #105.

Plug 'tpope/vim-endwise'
let g:endwise_no_mappings = 1
imap <expr> <CR> (pumvisible() ? "\<C-e>\<CR>\<Plug>DiscretionaryEnd" : "\<CR>\<Plug>DiscretionaryEnd")

[tpope]

I'm guessing this errant behavior is triggered by a said plugin changing 'completeopt'. Can someone tell me what that value is?

[bluz71]

Hello Tim,

In my case it is set completeopt=menu,menuone,noinsert,noselect.

Quite a few completion managers auto-set that value.

[tpope]

So you also have to press enter twice if you don't have Endwise installed, no?

Edit: I guess this must mean said plugins also provide a <CR> map. Can someone point me to the implementation in one of these completion plugins?

[bluz71]

Tim,

Without endwise, <CR> is still suboptimal. So endwise, for my setup, is not making things worse.

I need to hit <CR> three times to enter a carriage return with endwise out of the loop. I don't know what the first <CR> does. The 2nd hit of <CR> closes the completion pop-up. The 3rd enters the real <CR>.

I use vim-lsc for LSP auto-completion using the Solargraph Ruby language server.

The best result I get is with endwise enabled, and the pumvisible solution I mentioned a couple post above. That works perfect.

I will do a few more tests and pass on any details that may be of interest.

[bluz71]

Ok, my three enter issue is vim-lsc.
Take lsc out results in the need to hit <CR> two times, 1st closes the popup, 2nd appends a carriage return.

That results from the value of completeopts=menu,menuone,noinsert,noselect.

Using the default value of completeopts=menu,preview fixes the double <CR> issue.

What does it all mean?
I don't know.
I am not sure there is anything you should do except maybe documenting the solution above for folks who use an auto-completion plugin such as: coc, deoplete, ncm2, lsc, etc.

[stevenharman]

I guess this must mean said plugins also provide a map. Can someone point me to the implementation in one of these completion plugins?

The coc.nvim plugin is one such, including an issue specifically mentioning vim-endwise: neoclide/coc.nvim#297

Though to be clear, they don't explicitly set that mapping in the plugin. Rather they offer the following mapping in their docs as a way to get <CR> to confirm the selection.

inoremap <expr> <cr> pumvisible() ? "\<C-y>" : "\<C-g>u\<CR>"

When using that mapping, and vim-endwise's default mappings, and with completeopt=menu,preview, I see the exact problems mentioned in the linked coc.nvim Issue.

[Th3Whit3Wolf]

I know this is kind of late @stevenharman but you can add this to your config

let g:endwise_no_mappings = v:true
inoremap <expr> <Plug>CustomCocCR pumvisible() ? coc#_select_confirm() : "\<C-g>u\<CR>\<c-r>=coc#on_enter()\<CR>"
imap <CR> <Plug>CustomCocCR<Plug>DiscretionaryEnd

This will let endwise work with coc and auto-select the first completion item and notify coc.nvim to
format on enter.

[laomaiweng]

@tpope I'm not sure that's best fixed on your end rather than on the completers' (non-expr mapping) or Neovim's end (ability to "chain" mappings?), but failing that would it be possible to put a warning in the README? This bug affects multiple auto-completers, isn't trivial to isolate, and can be quite disruptive (complete neovim hang with Coq), so I figure people would be glad to know before getting bitten.

It took me days to find out this was the root cause for my hangs, I'd sure have appreciated a heads up. 😅

[tpope]

We now support chaining to expression maps. That should take care of the worst of this.