Unexpected behavior with julia.vim

[hungpham3112]

OS: Windows 11 22H2
**What vim?: gvim, vim 9.0 patch 1-1071

Autopairs config (if applicable):

""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"                             Plugin: AutoPairs                              "
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
vim9script
g:rust_kep_autopairs_default = 1
g:AutoPairsMapBS = 1
g:AutoPairsShortcutFastWrap = "<C-f>"

Describe the bug

When install julia.vim, editting the code for the first time returns <SNR>122_AutoPairsOldCRWrapper73<SNR>122_AutoPairsReturn. If open other event for example like NerdTree or other file, then comeback to old file, now you can edit the file normally by magic. I opened the issue in julia.vim for 6 month but there is no new response about this behavior. I suppose there is a bug with one of 2 plugins.

Without julia.vim:

162108660-5255620a-0519-4c9b-9db9-8d1eb75f5f47.mp4

With julia.vim:

162109320-a5c4c1a1-8df3-4410-988b-0933403bde15.mp4

Steps to reproduce

1. Install julia.vim and auto-pair
2. install coc.nvim with coc-snippets if you want to have snippets like above videos (optional)
3. type to see the result

Tell me if you can reproduce the bug. Thanks you.

[LunarWatcher]

Based on JuliaEditorSupport/julia-vim#40, particularly

JuliaEditorSupport/julia-vim#40 (comment)

which states the plugin also conflicts with delimitmate, I'd take a guess and say it's mapping-related. A possible source is

https://github.com/JuliaEditorSupport/julia-vim/blob/fca7e3e59e6f9417d3fd77bac50d4b820a3e8bc4/autoload/LaTeXtoUnicode.vim#L680

resulting in a weird mapping conflict. IIRC, that's also what the OldCR wrapper does. I can't immediately reproduce, but I'm currently stuck on windows where none of my normal automation systems work, and it seems I currently have the wrong version of Python, so coc-snippets doesn't work. Getting everything up-to-date is gonna take a bit of work, and it's 1 in the morning and I just don't feel like doing that right now. I'll take a look tomorrow and see if I can reproduce it then.

In the meanwhile, is it just <CR> that's misbehaving? Do the parentheses work as normal? Is this exclusively related to snippets? Does imap <CR> say anything useful beyond the output you got? If julia.vim is loaded after auto-pairs, it's most likely their fault for trying to map compatibly, but just overwriting it poorly. They do have some type of compatibility function it seems, but i haven't read through it to see what it does.

If not, it's probably auto-pairs' "compatible CR mapping" being garbage. I haven't touched it after inheriting the code. It could very well be broken. These types of bugs have been around for a while though, but I've never been able to reproduce any of the previous reports (and they were abandoned, so never got any feedback to help me find the root of the issue)

There was a comment in auto-pairs' code about <SID> resulting in some incompatibility with certain plugins, but I never had enough data to figure out what type of incompatibility, or when <SID> expands properly when attempted mapped outside the script defining the <SID> map. Mapping core keys like <CR> in insert mode is a minefield, basically.

[hungpham3112]

Based on JuliaEditorSupport/julia-vim#40, particularly

JuliaEditorSupport/julia-vim#40 (comment)

which states the plugin also conflicts with delimitmate, I'd take a guess and say it's mapping-related. A possible source is

https://github.com/JuliaEditorSupport/julia-vim/blob/fca7e3e59e6f9417d3fd77bac50d4b820a3e8bc4/autoload/LaTeXtoUnicode.vim#L680

resulting in a weird mapping conflict. IIRC, that's also what the OldCR wrapper does. I can't immediately reproduce, but I'm currently stuck on windows where none of my normal automation systems work, and it seems I currently have the wrong version of Python, so coc-snippets doesn't work. Getting everything up-to-date is gonna take a bit of work, and it's 1 in the morning and I just don't feel like doing that right now. I'll take a look tomorrow and see if I can reproduce it then.

In the meanwhile, is it just <CR> that's misbehaving? Do the parentheses work as normal? Is this exclusively related to snippets? Does imap <CR> say anything useful beyond the output you got? If julia.vim is loaded after auto-pairs, it's most likely their fault for trying to map compatibly, but just overwriting it poorly. They do have some type of compatibility function it seems, but i haven't read through it to see what it does.

If not, it's probably auto-pairs' "compatible CR mapping" being garbage. I haven't touched it after inheriting the code. It could very well be broken. These types of bugs have been around for a while though, but I've never been able to reproduce any of the previous reports (and they were abandoned, so never got any feedback to help me find the root of the issue)

There was a comment in auto-pairs' code about <SID> resulting in some incompatibility with certain plugins, but I never had enough data to figure out what type of incompatibility, or when <SID> expands properly when attempted mapped outside the script defining the <SID> map. Mapping core keys like <CR> in insert mode is a minefield, basically.

Thanks for fast reply. I can confirm that the problem goes when I hit <CR>, nothing wrong with brackets. I removed snippet to minimize the problem -> it's not snippets fault.

imap <CR> in julia file returns

i  <CR>        &@<SNR>129_AutoPairsOldCRWrapper73<SNR>129_AutoPairsReturn
	Last set from ~\vimfiles\plugged\auto-pairs\autoload\autopairs\Keybinds.vim line 245
i  <CR>        * coc#pum#visible() ? coc#pum#confirm(): "\<C-G>u\<CR>\<C-R>=coc#on_enter()\<CR>"
	Last set from ~\vimfiles\plugin\autocomplete_engine\coc-nvim_settings.vim line 22

imap <CR> in other file returns

i  <CR>        &@<SNR>129_AutoPairsOldCRWrapper73<SNR>129_AutoPairsReturn
	Last set from ~\vimfiles\plugged\auto-pairs\autoload\autopairs\Keybinds.vim line 245
i  <CR>        * coc#pum#visible() ? coc#pum#confirm(): "\<C-G>u\<CR>\<C-R>=coc#on_enter()\<CR>"
	Last set from ~\vimfiles\plugin\autocomplete_engine\coc-nvim_settings.vim line 22

There is thing weird in here I don't understand is that in julia file it should be three imap output, one from coc-nvim, one from auto-pairs and on top is julia-vim but auto-pairs doesn't exist but still have <SNR>122_AutoPairsOldCRWrapper73<SNR>122_AutoPairsReturn.

[LunarWatcher]

The coc.nvim map is the problem. See #66 - not sure why you're not seeing it everywhere, but that's async for you. This is unfortunately a wontfix due to how coc.nvim is structured. Nothing any other plugin does works consistently thanks to its async behavior. Even pum detection (discussed in #66) will fail intermittently. You may be able to make an alternative mapping explicitly integrating auto-pairs instead of <cr>, but it's a mess to do universally when a large variety of autocomplete plugins exist. Seeing as enter for autocomplete has such a popularity lead over the natively supported <C-y>, I may implement a function at some point that provides better support for manual maps, or some type of system that integrates conditional maps, but the core problem remains a wontfix (and coc.nvim's fault)

As for three maps in the Julia file, no. That's unfortunately not how Vim's keybind system works. You get a buffer keybind and a global keybind for each key. If two different plugins map the same key, only one of them apply. Some plugins try to avoid that (auto-pairs included) by taking whatever is already mapped, prefixing it, and leaving itself as a fallback (or postfixing it and taking priority over the other plugin). Vim's decision to do so makes for quite a few interesting design challenges around commonly mapped keys (again, particularly individual letters, cr, bs, space, ..., in insert mode), and it's all up to the individual plugins to cope

[LunarWatcher]

Also means that the problem is non-deterministic and dependent on unpredictable async operations. Julia.vim might be doing something tipping the scales in favor of the race condition making auto-pairs misbehave, but trying to track it down isn't really possible, and that assumes its a tangible cause to begin with. At an extreme, there could be an autocmd going off (registered by Julia.vim) that ties back to some key typed event that stalls the map processing just long enough (but still on the order of milliseconds at most; it's a race condition, not a performance issue) for an async interrupt to swoop in just in time to break the map, and that nothing else in the configuration provides that thing biasing each keypress towards a race condition.

That's why it's inevitably easier to change or remove the map used to make <cr> accept the auto-complete's suggestion. Plus, vim's input system doesn't really have clear systems to deal with async stuff, which opens for fun stuff in use-cases like these that just result in wontfixes

[LunarWatcher]

I was writing a reply over in Julia.nvim and got nerd sniped. TL;DR: The global <CR> actually sneaks into AutoPairsOldCRWrapper. I misunderstood the map system.

In fact, buffer maps are always prioritised over global maps. If not for what auto-pairs does, the global <CR> mapping would be overridden. Fuck knows what triggered #66 then; I have no idea. I can't reproduce it anymore either.

This also means I've narrowed down the problem further. I couldn't reproduce without julia-vim, but when I enabled let g:latex_to_unicode_auto = 1, it fell apart. The buffer map was replaced with <Plug>L2UAutoSub, which invokes L2UFallbackCR, which tries to invoke the former mapping.

The problem appears because julia-vim fails to maintain auto-pairs' <expr> mapping. It instead feeds the keys of the old CR key, which is very wrong.

This means I was wrong; there is indeed a bug here, and it's with julia-vim.