Conflict with auto_pairs

[part1zano]

The said conflict had been fixed in #427 but recently reappeared. I tried to apply the same patch they used, but it still displays error after every completion. So please, try and reapply that patch again.

[part1zano]

[xaizek]

I don't think there is any conflict. Could it be that g:clang_make_default_keymappings isn't 1 for you so s:old_cr doesn't even get defined?

[part1zano]

I do think there's a conflict as the patch you can observe in #427 isn't exactly in the source code anymore. See, this piece of code:

function! s:TriggerSnippet()
  " Dont bother doing anything until we're sure the user exited the menu
  if !b:snippet_chosen
    return
  endif

  " Stop monitoring as we'll trigger a snippet
  let b:snippet_chosen = 0
  call s:StopMonitoring()

  " Trigger the snippet
  execute s:py_cmd 'snippetsTrigger()'

  if g:clang_close_preview
    pclose
  endif
endfunction

lacks the lines provided in the pull request:

[part1zano]

Basically, ignore the first screenshot I provided: I may have applied the patch incorrectly.

[part1zano]

I also set g:clang_make_default_keymappings to 1, and nothing changed.

[xaizek]

Looks like since 72eabd5 that code is part of s:StopMonitoring(), maybe not all original logic was preserved.

[part1zano]

So, will anything be done on that?

[xaizek]

Well, I just hinted on what might be the reason, but I'm not using neither auto_pairs nor clang_complete at the moment, so wasn't planning to configure everything and try to come up with the fix. Sorry, should have mentioned it initially.

[part1zano]

Dear @xaizek By no means did I mean to try and make you do something about that. Sorry if that worried you.

[xaizek]

Well, unfortunately for the project you're pretty much out of luck waiting for anyone else with push access to respond.

See issue559 branch, I haven't tested it, but if 72eabd5 broke it the way I think, the fix should be along those lines. It was easier to do in the code than to suggest how it might be fixed in text.

[fleischie]

I have mixed results with e9d32830 unfortunately.

Sometimes it's reporting an infinite recursion, and sometimes it just outputs <SNR>46_AutoPairsReturn verbosely into the current cursor position.

The infinite recursion seems to be coming from (I made sure to check, what value "a:what" has, when I traced this): https://github.com/Rip-Rip/clang_complete/blob/e9d32830509bbb32ceed34da8533266702bd3a8c/plugin/clang_complete.vim#L573-L574 https://github.com/Rip-Rip/clang_complete/blob/e9d32830509bbb32ceed34da8533266702bd3a8c/plugin/clang_complete.vim#L529-L531

And happens, if b:snippet_chosen is set to 1. I was able to trigger this with a fresh buffer and inputting the following characters:

int<C-N><CR>

NOTE: <C-N> selects the next element in the suggestion list, so basically sets b:snippet_chosen = 1 (I am using deoplete.nvim for the suggestion box, but I don't think that this has anything to do with anything).

Now I am not in too deep into what this fix is supposed to do actually, but I had a similar issue in another plugin once. I fixed it then by having a global semaphore, that I set to 1 whenever I initially called the nested from the outer function. In the inner function I checked, whether it was set and did not call the outer function from in the inner one. I don't know, if this is helpful or not, but I just wanted to share my knowledge on this topic. If I can do anything more to help, let me know. 🙏

[xaizek]

@fleischie, thanks for testing it. I've added 2bdcbc944b132c832a0cd0209290cd1d8004d1e9 which tries to address the recursion, b:snippet_chosen should always be reset on entering s:TriggerSnippet(). Not sure about <SNR>46_AutoPairsReturn though.

[fleischie]

@xaizek no problem, thanks for working on this plugin. 🙇

The recursion issue seems to be solved now. The <SNR>46_AutoPairsReturn is now printed whenever I select a snippet and it should expand it and it should evaluate the previous stored <CR> method as it seems.

Typing in int<C-N><CR><CR><CR> (in insert mode in a fresh buffer) yields:

int
<SNR>46_AutoPairsReturn
<SNR>46_AutoPairsReturn

The first <CR> inserts the first <SNR>46_AutoPairsReturn. The second one closes the preview window, that opened when I selected the suggestion with <C-N>. The third one inserts the last line.

Tracing this a bit further I found, that https://github.com/Rip-Rip/clang_complete/blob/2bdcbc944b132c832a0cd0209290cd1d8004d1e9/plugin/clang_complete.vim#L540-L546 constructs and executes the command inoremap <buffer> <CR> <CR><SNR>46_AutoPairsReturn. This would probably explain, why it's <SNR>46_AutoPairsReturn that is inserted into the buffer.

I am still not sure, why it is inserted in the first place and not evaluated. If you can give me a brief run-down of what the fix should do and what the function/the functions I am looking at are supposed to do, I can propose changes as well, that made it work for me if I can formulate them. Otherwise we can still debug it like we do now, where you would fix it and I debug it. :smile: :+1:

[xaizek]

Looking at auto-pairs https://github.com/jiangmiao/auto-pairs/blob/f0019fc6423e7ce7bbd01d196a7e027077687fda/plugin/auto-pairs.vim#L571-L572

  execute 'inoremap <script> <buffer> <silent> <CR> '.old_cr.'<SID>AutoPairsReturn'

It seems that clang_complete mangles its mapping somehow. As if it mixes some from auto-pairs and some from clang_complete.

In a newly opened buffer :imap <cr> should show the command which clang_complete should restore.

[fleischie]

nvim and in ex mode :imap <cr> yields: i <CR> &@<CR><SNR>46_AutoPairsReturn. Which - according to the verbose pre-cmd - was set from the auto-pairs plugin. (auto-pairs/plugin/auto-pairs.vim)

[xaizek]

Looks like clang_complete turns something like this:

inoremap <script> <CR> <CR><SID>PairsReturn

into

inoremap <CR> <CR><SID>PairsReturn

And because it's noremap, <SID>PairsReturn in right-hand side doesn't get expanded.

We lack <script>, but maparg() doesn't report on whether it was used to define the mapping.

[fleischie]

I changed my completion plugin (from Shougo/deoplete.nvim to lifepillar/vim-mucomplete) and found a similar issue with that plugin, in that remappings of <cr> would print the AutoPairs string into the buffer.

This thus seems to be an issue on auto-pairs side, no? Maybe because it's setting the command with an execute 'inoremap <script> ... '.old_cr.'<SID>AutoPairsReturn'.' <cr>'? Maybe? I don't really have a thorough grasp on this mapping thing.

[xaizek]

Well, the mapping is problematic, but I'm not sure if there is a better way of writing it. auto-pairs tries to work around issues with vim-endwise and supertab. If Tim Pope couldn't write vim-endwise in a way that works, Vim probably needs to be extended somehow to support such chaining of mappings.

[bdebyl]

For what it's worth for anyone having the same issues with AutoPairs, my solution to the following happening when hitting <CR> after a completion:

<SNR>29_AutoPairsReturn
<SNR>29_AutoPairsReturn

Was to add the following to my ~/.vimrc:

let g:AutoPairsMapCR = 0

For future reference, this was from AutoPairs 39f06b8, :help g:AutoPairsMapCR:

Map <CR> to insert a new indented line if cursor in (|), {|} [|], '|', "|".
Executes:

    inoremap <buffer> <silent> <CR> <C-R>=AutoPairsReturn()<CR>

(make sure to reload your ~/.vimrc / restart Vim)

[ocidenttal]

literally solved my problem, thanks!