-
Notifications
You must be signed in to change notification settings - Fork 6
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
Error is thrown while trying to use vertical split when I use auto-pairs in neovim v0.9.0 #78
Comments
The bug still remains once I remove the setting of fillchars |
What's the output of |
Downloaded and used your dotfiles, can't reproduce it there. maps to nvim-cmp, but it appears to map compatibly. In either case, fillchars is irrelevant. There's either another plugin interfering, or my best guess seeing as reports of this bug so far have only come from nvim, nvim might've broken maparg. According to
Since dict is set to true, rhs is defined. This is also backed up further by the docs' statement for what's returned when the mapping doesn't exist:
Which is already covered with an |
You are right, it might not be the issue of fillchars. I removed fillchars, the config, and all the cache including the installed plugins in I am new to neovim. So I don't understand the errors thrown, so I have only referred to those as error. This is the output of
|
Here is my neovim config. The config requires neovim v0.8.0 or higher, preferably v0.9.0. |
I tried with your dotfiles yesterday, and still couldn't reproduce. Tried again now specifically with vsplit, and still can't reproduce. I'd recommend disabling other plugins to see if disabling another plugin also fixes it. That would check if there's an incompatibility, even if it's an obscure one. If there isn't, I'll personally be blaming nvim (the function call is made and handled according to spec, and if there isn't another plugin interfering, that only leaves one common factor between this and the other case; nvim itself), and recommend you open an issue there instead |
Thank you for the suggestion. I checked out with all the plugins. But the problem was with the configuration provided in lsp-zero. I didn't know that the docs was updated. Turns out this was the problem:
The error is no longer thrown if it is replaced by:
I still don't know what caused the issue... will look into it more...Thank you for your time :) |
is presumably why nvim-cmp maps |
One of my friends is using my config, and he gets the error, but sometimes only. It sometimes throws no error but throws the same error other times in his system |
So is it the problem of nvim_cmp or...? |
Can you switch to the 78-debug branch and try triggering the error? It consists of a single commit (well, two, the second one just adds a string in front of the dict) echoing the contents of the (You can (and should) switch back to the master branch afterwards. It's a temporary branch purely for debug) |
This is what returned when triggering the error. |
Sigh... That confirms it's nvim's fault. I'll open an issue in their repo, though I doubt there's a fix for it. Doc update is probably the best-case here. I'll implement a hack, but the short solution appears to be disregarding Lua-based maps when mapping compatibly. That's annoying |
As for why it isn't consistently reproducible everywhere, my best guess is the plugin init order, though that still doesn't a ccount for everything. It's perfectly possible that what I'm seeing is a result of auto-pairs loading first, and nvim-cmp loading second, while what you're seeing is nvim-cmp loading first, and auto-pairs choking when mapping compatibly due to nvim apparently not defining rhs for lua-based mappings. I have no clue why this would happen though, but I'm also not deep enough in (n)vim code to tell how plugin load order works. |
Can we do something like... auto-pairs only starts working when |
No, auto-pairs isn't Lua-based. Even then, auto-pairs mostly operates on a buffer level. The order difference is realistically going to be in autocmd call order, and I have no clue how you affect it. Some old comments by jiangmiao led me to believe plugins were loaded alphabetically, but that would mean auto-pairs is always loaded before **n*vim-cmp. I'm not sure what exactly the loading order is though. It could be something else, or even platform-dependent. The only good workaround here is defining your own map, manually combining auto-pairs with whatever else you have. I'm pretty sure I wrote docs on how to do that, though that's Vimscript-based, and assumes you're able to independently call all the things you want to call. Based on what I saw of nvim-cmp's code, I doubt you'd be able to map nvim-cmp to a separately invocable function. I'll have to look at auto-pairs' options for dealing with it later though. The solutions also depend on what direction neovim goes in, which first requires me to finish the bug report |
Nasty hack pending neovim/neovim#23666 getting fixed (or not, resulting in the nuclear option of officially removing nvim support)
I've pushed a temporary hack. It disables AutoPairsMapCR if rhs is undefined. It's not great, but I'm not familiar enough with nvim to do anything better. On the bright side, you'll get the warning once per session, and with a real explanation.
It's... not an elegant map, and I'm not sure how you'd even explicitly call a It wasn't intended to be used in a functional Lua context, so it's not great, but with some code, it should be doable. In either case, you're unfortunately on your own if you want to make a function combining auto-pairs and nvim-cmp. I can help with pointing you in the direction of the correct auto-pairs function to use, but that's about it. Aside that, you have two options (three if you count finding a nvim-oriented replacement plugin, four if you count upgrading from neovim to regular vim):
Personally, I'd prefer going with option 2 (but I'm biased: C-y feels far more natural than enter now that I'm used to it), but this is entirely up to you. Doing nothing means an implicit option 1 after a warning notifying you that AutoPairsMapCR will be disabled that session. Hopefully, nvim realises that breaking compatibility in a function that established in the vimscript stdlib is monumentally dumb and fixes it, at which point, the rhs compatibility system starts working again, and it should be fine after that. Well, after an update, but whatever. Until then, subpar options all around. I'll also leave the issue open for the time being. There are other nvim users using this plugin, meaning there's always the chance more people have this issue. |
I think disabling |
I will also try to combine the functions... If I am able to do so, then I will post it here. |
OS (name + version; i.e. Linux Mint 20, Windows 10 2004, Macos Big Sur, etc.):
Arch Linux
What vim? (+ version) (i.e. vim, gvim, nvim, nvim-qt, mvim, ...):
NVIM 0.9.0
Reproduced in other variants of Vim? (Optional):
Autopairs config (if applicable):
I have just installed autopairs using packer, no other config
Describe the bug
I have set fillchars in my neovim config as follows:
Following error is thrown when I enter the command
:vnew
:After this error comes along, telescope find files also stops working.
Steps to reproduce
Install autopairs and then set fillchars.
The text was updated successfully, but these errors were encountered: