make mappings more easily configurable and remappings more robust

[Konfekt]

Maybe you deem some of the following suggestions useful:

• always offer (global variant) of s:MapTab() to remap key to bound fallback (it goes to great lengths to achieve this and works quite generally, so give it some publicity as it is useful for any plug-in or user redefining a map so that it falls back to an existing map, for example snippet expansion)
• document mappings for individual fallbacks
• add some documentation
• try to respect user insert mode remappings (this was not evident for <c-o> and <cr> in insert mode, though)
• Just wondering why

  imap <Plug>(copilot-next)     <Cmd>call copilot#Next()<CR>
  imap <Plug>(copilot-previous) <Cmd>call copilot#Previous()<CR>
  imap <Plug>(copilot-suggest)  <Cmd>call copilot#Suggest()<CR>

are recursively mapped? Isn't <CR> supposed to be non-recursive? If it's because of the output of call copilot#Next(), then how about using a script-local remapping of <CR>?

At the moment we are not accepting contributions to the repository.

[tpope]

• try to respect user insert mode remappings (this was not evident for <c-o> and <cr> in insert mode, though)

This is not necessary or desirable.

• Just wondering why

  imap <Plug>(copilot-next)     <Cmd>call copilot#Next()<CR>
  imap <Plug>(copilot-previous) <Cmd>call copilot#Previous()<CR>
  imap <Plug>(copilot-suggest)  <Cmd>call copilot#Suggest()<CR>

are recursively mapped? Isn't <CR> supposed to be non-recursive? If it's because of the output of call copilot#Next(), then how about using a script-local remapping of <CR>?

All <Cmd> maps are non-recursive, regardless of whether map or noremap is used.

At the moment we are not accepting contributions to the repository.

Please observe this going forward. This repository is for distribution only. PRs can't be merged. Feedback can be shared at https://github.com/orgs/community/discussions/categories/copilot.

[Konfekt]

All maps are non-recursive, regardless of whether map or noremap is used.

Thank you, I just thought of it as a variant of noremap ... :<c-u> ... <cr>.

try to respect user insert mode remappings (this was not evident for and in insert mode, though)
This is not necessary or desirable.

Maybe there's a misunderstanding; what was meant is that the mappings of this plug-in should work independent of the user's vimrc.

[tpope]

Maybe there's a misunderstanding; what was meant is that the mappings of this plug-in should work independent of the user's vimrc.

I tried remapping <Left> and <C-R> in my vimrc and everything still worked.

[Konfekt]

I had a remapping of <end> that made the cursor fall one short of jumping to the end, and so did the cursor after accepting the copilot suggestion; I removed it, which is fine, just to (make others) be aware of it.

[tpope]

I had a remapping of <end> that made the cursor fall one short of jumping to the end, and so did the cursor after accepting the copilot suggestion; I removed it, which is fine, just to (make others) be aware of it.

Tested and I can't reproduce this either. Was this with the default <Tab> map or something custom?

[Konfekt]

No, <Tab> was mapped to <Plug>(MUcompleteFwd). In this case, when <tab> is mapped to a recursive mapping, then copilot.vim must use the recursive mapping for <tab>. In particular, for <end>.