'set cpoptions=n' causes vim-endwise producing 'r' symbol instead of new line

[drew1kun]

Hi, I have updated my vim Plugins including vim-endwise using vim-plug recently (unfortunately I haven't done it for years) and this has revealed some interesting issue...
Now in the Insert Mode when pressing 'Enter' key ('Return' key on MacOS to be precise), neovim produces 'r' symbol instead of new line...
I had 52 plugins installed (lol) so it took some time to find out that the problem ceases when I unplug the single vim-endwise plugin. I also have some custom configuration in my ~./vimrc, so I disabled all the plugins and gradually commenting and uncommenting my config and testing the problem I have found out that using 'set cpoptions=n' in conjunction with vim-endwise causes the issue. I use it for wrapping the long lines in neovim this way:

"================================ BREAK LINES ==================================
let &showbreak = '↳ '               " Symbol shown on the left when long line is broken into multiple lines
set wrap                            " Show long lines as multiple lines (for gpg, ssh keys etc.)
set cpoptions=n

As stated here the 'n' flag does the following:

So it makes just a bit of difference but may break someone's setup as it has broken mine:

So to fix the issue for now the one has to chose either to remove 'set cpoptions=n' from ~/.vimrc or to disable vim-endwise plugin, but why is that the case and why it did not do it before? Just curious...
I guess it will take some time to find out at which point in time the breaking changes happened.

Tested it on two different MacBookPros with Monterey and Catalina.

[tpope]

Try with other plugins disabled. All signs point to this being a different plugin that also maps <CR> interacting with Endwise badly.

[drew1kun]

You are wrong. I tried again - no plugins, only vim-endwise. Absolutely clear ~/.vimrc with just one stanza, mentioned above - same issue. It is 100% this plugin. Too bad you closed the issue without even trying to test it.

[tpope]

I did test it and didn't see anything wrong. But I don't even understand what your trying to show me. For starters, what the heck is an "'r' symbol"?

[jubalfh]

i think i can help here. namely, the issue is that after the upgrade to latest (210bec5), pressing “enter” in the insert mode produces reliably the character ‘r’, at the very least in my vim 9 installation, both console and gvim (patched up to the patch № 135). same behaviour shows in nvim 0.7.2, which, i gather, is what the op has seen.

not remembering much of my vimscript anymore, i tried blindly to replace the single backslash with a double backslash in the mapping in question, and it seems to fix the problem in both vim 9 and nvim 0.7.2.

note: this is a very naïve approach; i did not try to read the code of the plugin at all, and the real issue might be somewhere else, being only masked by the change.

[tpope]

Okay that makes more sense. I can sidestep entirely by using <Bslash>.

[tpope]

And the root cause isn't adding n, it's removing everything else, most notably B. I'd advise to use cpoptions+=n, not cpoptions=n, as this definitely isn't the only plugin that'll break by doing that.

[jubalfh]

yup. though it's more rare than i'd expect, because for a reason i can't even remember i'm explicitly setting cpoptions to something without B since at the very least 2013 (and most likely much, much earlier), and that's the first time i've encountered an issue.

(the +=/-= approach is much safer, obviously)

anyways, thanks for a good lesson. :-)