Comments (5)
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
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.
from auto-pairs.
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
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? Doesimap <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
.
from auto-pairs.
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
from auto-pairs.
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
from auto-pairs.
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.
from auto-pairs.
Related Issues (20)
- Too aggressive close checks can break multibyte pairs HOT 1
- Option to Move Openinig Brace to the Next Line in "Insert new indented line after Return" HOT 4
- Close brackets are added even when the next character is alphanumeric HOT 2
- 'Insert new indented line after Return' failed when used with vim-auto-popmenu HOT 2
- Can't delete in pairs HOT 5
- Testing for dupe tags HOT 1
- Breaking some non-English characters HOT 4
- g:AutoPairsMapCR conflicts against coc.nvim HOT 14
- Providing an option to skip setting up key maps in a file type? HOT 1
- Add a prefix variable to all the places that use `<C-p>` as a prefix
- Multibyte pair \( and \) causing errors. HOT 4
- Regex issue with new tex multibyte pairs HOT 14
- Not getting auto completed parenthesis just before a quote HOT 7
- Changing variables has no effect on functionality of the plugin HOT 8
- Confused about MultiLineClose HOT 2
- Error is thrown while trying to use vertical split when I use auto-pairs in neovim v0.9.0 HOT 19
- bug: variable not found open HOT 2
- Not working under debian HOT 2
- modify `<C-p>` as configurable due to <C-p> in insert mode cause slow react in drop down selection HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from auto-pairs.