Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict with vim-visual-multi. AutoPairsReturn and AutoPairsDelete invalid. #326

Open
onlycalm opened this issue Jun 20, 2021 · 2 comments

Comments

@onlycalm
Copy link

When I use plug-ins auto-pairs and vim-visual-multi at the same time, the function of auto-pairs fails.
I also raised the problem on vim-visual-multi, when I still don't know how to solve it. issue (Here is a more detailed description of the problem.)

@LunarWatcher
Copy link

Vim-visual-multi, by default, disables auto-pairs. I don't know the exact motivation behind it, but that's just how things are.

Instead of trying to make maps compatible (auto-pairs initializes some maps that are prone to conflict in such a way that it, well, doesn't conflict), they overwrite them and rather reload them.

The issue states that there are warnings on startup. As another user of that plugin myself, I haven't noticed that warning until I updated today. It hasn't been there before, and it wasn't there when testing with my fork until after I updated. In spite of that, bisecting VM doesn't result in an obvious starting point for the error. Since it happens with this stale repo as well, it's reasonable to guess that it's VM's fault, but it doesn't seem to be the case.

Now, the good news is that it's a warning. The other good news is that it's possible to disable the warnings (let g:VM_show_warnings = 0). The bad news is that there isn't really a way to enable auto-pairs.

Since VM is enabled after auto-pairs, there's not really a way to preserve the keybinds. It's on VM to make it possible to preserve mappings and even do compatible maps. I'm sus that the autoload files need to specify a <Plug> mapping for the core keybinds to avoid conflict and make it reusable, but that's my interpretation of a very vague comment that may or may not be referring to the recursive requirement for plug maps to work, and the obscenely complex nature of plugins trying to be compatible with each other. Fun, innit? :')

I'll gladly throw in plug mappings in definitions to make them expandable and modifiable by other plugins, but when ·it seems it forcibly overrides maps by design, and a few plugins are still forcibly disabled with no options for compatibility aside gracefully shutting down, there's not really much else to do than silence warnings and live with auto-pairs not working when VM is running.

@onlycalm
Copy link
Author

Thank you for your reply, which makes me learn a lot. ^_^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants