Error is thrown while trying to use vertical split when I use auto-pairs in neovim v0.9.0 about auto-pairs HOT 19 OPEN

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

from auto-pairs.

I will also try to combine the functions... If I am able to do so, then I will post it here.

from auto-pairs.

The bug still remains once I remove the setting of fillchars

from auto-pairs.

What's the output of :verbose imap <cr>?

from auto-pairs.

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 :h maparg:

		When {dict} is there and it is |TRUE| return a dictionary
		containing all the information of the mapping with the
		following items:			*mapping-dict*
		  "lhs"	     The {lhs} of the mapping as it would be typed
		  "lhsraw"   The {lhs} of the mapping as raw bytes
		  "lhsrawalt" The {lhs} of the mapping as raw bytes, alternate
			      form, only present when it differs from "lhsraw"
		  "rhs"	     The {rhs} of the mapping as typed.

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:

		When there is no mapping for {name}, an empty String is
		returned if {dict} is FALSE, otherwise returns an empty Dict.
		When the mapping for {name} is empty, then "<Nop>" is
		returned.

Which is already covered with an if empty(info) block in the code (Keybinds.vim#215 at the current commit, arsed linking to it). However, since I can't reproduce and consequently can't debug, I need more information (and preferably a minimal config file that's able to reproduce the problem).

from auto-pairs.

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 ~/.local/share/nvim and then downloaded and set up my config again. The error still persists. But when I removed the package LunarWatcher/auto-pairs, the error is no longer thrown.

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 :verbose imap <cr>:

i  <CR>        * <Lua 184: ~/.local/share/nvim/site/pack/packer/start/nvim-cmp/lua/cmp/utils/keymap.lua:127>                                                                                                                               
                 cmp.utils.keymap.set_map                                                                                                                                                                                                  
        Last set from Lua   

from auto-pairs.

Here is my neovim config.

The config requires neovim v0.8.0 or higher, preferably v0.9.0.

from auto-pairs.

I tried with your dotfiles yesterday, and still couldn't reproduce. Tried again now specifically with vsplit, and still can't reproduce. :verbose imap <cr> is as expected. Tried on both 0.9.0 and 0.10.0-dev

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

from auto-pairs.

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:

local lsp = require('lsp-zero').preset({
	name = 'minimal',
	set_lsp_keymaps = true,
	manage_nvim_cmp = true,
	suggest_lsp_servers = false,
})

The error is no longer thrown if it is replaced by:

local lsp = require('lsp-zero').preset({})

I still don't know what caused the issue... will look into it more...Thank you for your time :)

from auto-pairs.

	manage_nvim_cmp = true,

is presumably why nvim-cmp maps <cr>, but that still doesn't make sense. Why would nvim-cmp mapping cr break maparg? The other weird part is that I can't trigger the bug manually even with cr mapped, which doesn't make sense

from auto-pairs.

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

from auto-pairs.

So is it the problem of nvim_cmp or...?

from auto-pairs.

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 info dict. It's not going to fix anything, but it'll show what maparg actually returns. That's theoretically the last missing piece before blame can be assigned. Should appear above the error messages. If it doesn't or you don't see it, clear the errors and check :messages

(You can (and should) switch back to the master branch afterwards. It's a temporary branch purely for debug)

from auto-pairs.

maparg returned {'lnum': 0, 'script': 0, 'mode': 'i', 'desc': 'cmp.utils.keymap.set_map', 'callback': function('<lambda>4'), 'noremap': 1, 'lhs': '<CR>', 'lhsraw': '^M', 'nowait': 0, 'expr': 0, 'sid': -8, 'buffer': 0, 'silent': 1}

This is what returned when triggering the error.

from auto-pairs.

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

from auto-pairs.

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.

from auto-pairs.

Can we do something like... auto-pairs only starts working when require(auto-pairs)? I think this can prevent auto-pairs loading first if we require nvim-cmp first

from auto-pairs.

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.

I took another look at nvim-cmp's code. There aren't any vimscript interfaces or public Lua methods a third party could use to sanely map <CR>. this is wrong. https://github.com/VonHeikemen/lsp-zero.nvim/blob/10c0486d4ad189c5141dfc3ba36e4e9fc5bb8396/doc/md/guides/setup-copilot-lua-plus-nvim-cmp.md?plain=1#L34 says there's cmp.mapping.confirm. That might be the function you'll have to use to create a combined function. See :h autopairs-autocomplete-cr for auto-pairs' function call.

It's... not an elegant map, and I'm not sure how you'd even explicitly call a <Plug> mapping from Lua code. The tricky bit is that the <Plug> is used to hide away some internal logic. You can alternatively call autopairs#AutoPairsReturn directly (note, also a vimscript function, not Lua). Note that regardless, the return value of the function must be used to construct the output of the keybind. It can be conditional, but if the condition decides to invoke auto-pairs, the output is what makes auto-pairs work.

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):

1. Disable AutoPairsMapCR; this isn't the biggest loss of functionality in the world, but it does mean you lose parenthesis expansion on enter. Means you need to hit enter twice rather than once, and manually go back where you want to type
2. Disable the <CR> mapping in nvim-cmp. Vim (and nvim by extension) has the built-in <C-y> keybind that does the exact same thing. Takes some getting used to though

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.

from auto-pairs.

I think disabling AutoPairsMapCR will do for me. I really cannot work with <C-y>. I can press enter twice. Even if I don't, lsp's formatting does it. So I think I will go with option 1

from auto-pairs.