Open part1zano opened 6 years ago
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?
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:
Basically, ignore the first screenshot I provided: I may have applied the patch incorrectly.
I also set g:clang_make_default_keymappings
to 1
, and nothing changed.
Looks like since 72eabd5 that code is part of s:StopMonitoring()
, maybe not all original logic was preserved.
So, will anything be done on that?
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.
Dear @xaizek By no means did I mean to try and make you do something about that. Sorry if that worried you.
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.
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. 🙏
@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.
@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:
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.
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
)
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.
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.
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.
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)
literally solved my problem, thanks!
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.