fix: avoid overwrting user defined mapping

[haorenW1025]

I get called out on stream...so I must fix this 😢 Right now completion-nvim will prompt you to change your g:completion_confirm_key if you already have some mapping on <CR> and won't overwrite it.

Some notes here: There is no api to get a specific mapping. I used nvim_buf_get_keymap and nvim_get_keymap to get a full list of mapping then iterate then to check if there's conflicting mapping, which I think is not that smart... I wonder if there's a better way to do it.

cc @kdheepak @tjdevries

fixes #153

[tjdevries]

Hmmm, it would probably be good to add an API around seeing if there exists any keymap for a particular key.... we do not have it yet though :laughing:

I wouldn't be worried about the performance, luajit would probably be fast enough. You could always just disable it on default? I'm not sure. The surprising thing was that <CR> was mapped by default for me when installing this (and I don't use it).

Perhaps just making it not a default anything would be better? (Sorry, I don't have a great solution nor understand 100% what's happening)

[parmort]

You could try to chain the functionality onto the confirmation key. That makes for a more seamless user experience (and it's what tpope does)

[taylan97]

Doh. I checked issues, but did not see this pull request.

I have suffered from this today, https://github.com/nvim-lua/completion-nvim/issues/255, with a similar fix: https://github.com/taylan97/completion-nvim/pull/1

Seems it's kind of old and no conflict, any reason to not merge?

I do kind of wonder if it's required for completion to set the binding and not just delegate that to the user configuration? I get that it has a custom <Plug> function you have to call, I don't think it can just hook into whatever normal vim "confirm completion" stuff.

If you do have to set it in the actual plugin, I think a less intrusive option would be vim's default completion accept combo, over CR, people who want CR can use the confirm_key option.