Plugin Conflict with Matchem [GIF inside]

[jwmann]

I'm getting some very annoying functionality when inserting strings. So far I've only noticed this happening in vim filetypes but can't exclude it from others.

Here's a small GIF what happens.

I'm not tabbing, it just auto-closes on the 'fi' suggestion. Now I'm not sure if this is matchem or mucomplete misbehaving but I figured I'd at least start here.

Following the troubleshooting steps, you can recreate this bug with this small vimrc

set runtimepath+=$HOME/.vim/bundle/vim-mucomplete/
set runtimepath+=$HOME/.vim/bundle/matchem/
set completeopt=menuone,noinsert,noselect
set showmode shortmess-=c
let g:mucomplete#enable_auto_at_startup = 1

set ft=vim

[lifepillar]

MUcomplete should warn you about <c-g><c-g> already being mapped (if it doesn't, please try the current master). Have you tried setting g:mucomplete#ctrlx_mode_out? For example, you may try to put this in your vimrc:

let g:mucomplete#ctrlx_mode_out = "\<c-x>\<c-b>\<bs>"

This fixes the issue for me (at least, the specific instance you've showed).

See :h mucomplete#ctrlx_mode_out for more options.

[jwmann]

This does seem to work better, thank you!

I did get the mapping warning when I first installed MUcomplete but it stopped showing so I figured it was just a weird anomaly.

Honestly though, I did check out the :h mucomplete#ctrlx_mode_out way before making this post and had a very difficult time understanding what I was reading and what it meant. As far as I knew, I wasn't mapping <C-g><C-g> so I didn't think it applied to me.

I don't even know what's so special about "\<c-x>\<c-b>\<bs>" either. Is it just a combination of mappings that Vim doesn't use in order to trigger the omnicomplete menu? Like you can't trigger the menu programatically so you have to change the original keyboard trigger? A little confusing.

I'm going to close this because my issue is resolved (thanks again!) but if you could elaborate on what that ctrlx_mode_out is I'd greatly appreciate it. 😄

[lifepillar]

I did get the mapping warning when I first installed MUcomplete but it stopped showing so I figured it was just a weird anomaly.

The warning shows up only when autoload/mucomplete.vim is loaded for the first time, typically at Vim's startup (if you have automatic completion enabled) or upon the first tab-triggered completion. You should never ignore warnings ;)

As far as I knew, I wasn't mapping so I didn't think it applied to me.

You weren't, but Matchem apparently does :) I'll add a note to the compatibility section of the documentation.

if you could elaborate on what that ctrlx_mode_out is I'd greatly appreciate it.

Several Vim completion methods enter a special sub-mode of Insert mode, called Ctrl-X sub-mode (see :h i_CTRL-X). Now, there are cases in which µcomplete needs to exit Ctrl-X sub-mode in order to trigger a different completion. The typical case is when µcomplete needs to trigger keyword completion (<c-p> or <c-n>), but the pop-up menu may be already opened (in which case, <c-p>/<c-n> would just move around the menu entries instead of activating keyword completion).

The value of g:mucomplete#ctrlx_mode_out defines the key sequence that does that. Finding a suitable value is tricky, because such key sequence must exit Ctrl-x sub-mode if it is active, but it must do nothing if Vim is not in Ctrl-x sub-mode.

As far as I can tell, <c-g><c-g> is the shortest sequence that works as expected. If some other plugin (or the user) maps <c-g><c-g> in Insert mode, though, a different sequence must be used. MUcomplete's documentation reports a few possibilities, which I have found after some trial and error, and with some help (see https://github.com/lifepillar/vim-mucomplete/issues/41).

If you want to experiment with Ctrl-x submode yourself, disable µcomplete's autocompletion, set

:set showmode shortmess-=c

start typing something, then type <c-x> to enter Ctrl-x submode (keep an eye below the status line). At this point, you may choose among different completion methods. Say you type <c-o> for omni completion. Two things may happen (depending on whether omnifunc is defined and whether there are available completions): the pop-up menu appears or it doesn't. If the pop-up menu appears, pressing <c-n> or <c-p> will move up and down the menu entries. If the pop-up menu does not appear, <c-n> and <c-p> will do nothing (because Vim is still in Ctrl-x mode). In either case, if you want to use keyword completion you have to exit Ctrl-x submode first, then type <c-n> or <c-p>: <c-g><c-g> will do just that, regardless of the visibility of the menu.

[lifepillar]

I don't even know what's so special about "\\\" either.

There are two cases:

1. if Vim is currently in Ctrl-x sub mode, then <c-x> does nothing, <c-b> exits Ctrl-x sub-mode and puts a literal ^B into the buffer, and finally <bs> deletes the inserted ^B.

2. If Vim is not in Ctrl-x sub mode, then <c-x> enters Ctrl-x sub mode, then <c-b><bs> behaves as above.

The net effect is that, in either case, Vim is surely out of Ctrl-x mode.

Using <c-b> is somewhat arbitrary: any key that is not valid in Ctrl-x sub mode will do (see :h ins-completion). I prefer <c-b> because it is not mapped in Insert mode any more (see :h i_CTRL-B-gone).

You may think that using just <c-b><bs> would work, too. I am positive that it doesn't, but right now I don't recall why (the reason is likely buried somewhere in the Git log) :)

[lifepillar]

If https://github.com/vim/vim/issues/1397 gets into Vim, all of the above will not be necessary any more.

[zhen-huan-hu]

I used ^n^e in my plugin, but it really feels like I am fighting Vim nevertheless. ^g^g seems to be a better choice. You don't actually need to worry about mapping if you use feedkeys("\<C-g>\<C-g>", 'n')

[jwmann]

@lifepillar Thank you very much for that explanation! I have a much greater understanding of what's going on in the background now. 😄

Seriously 👍

---

Sidenote: Wasn't expecting that vim issue reference to be made just few hours ago I figured that something like that should've been brought up a long time ago haha.

[lifepillar]

If vim/vim#1397 gets into Vim, all of the above will not be necessary any more.

On a second thought, that's wrong. MUcomplete would be able to detect whether Vim is in ctrl-x mode or not, but the problem of how to exit ctrl-x sub mode without side effects would still exist.

@akanosora I hadn't thought about using feedkeys(…, 'n'). That's a really good idea, which allows me to get rid of g:mucomplete#ctrlx_mode_out. Thanks!

[zhen-huan-hu]

On a second thought, that's wrong. MUcomplete would be able to detect whether Vim is in ctrl-x mode or not, but the problem of how to exit ctrl-x sub mode without side effects would still exist.

I am curious how you detect ctrl-x mode. If you can do that, can you use ctrl-e to get back to the insert mode?

[lifepillar]

I am curious how you detect ctrl-x mode.

What I meant is, it would be possible with the patch https://github.com/vim/vim/issues/1397.

MUcomplete just needs to make sure that, in certain situations, Vim is surely out of ctrl-x mode. It doesn't actually check whether Vim is in ctrl-x mode (I wouldn't know how to do it without the patch mentioned above), it just sends the key sequence <c-g><c-g>, which obtains the desired result.

[lifepillar]

@jwmann I have removed g:mucomplete#ctrlx_mode_out (and the confusion it created) from the current master, which should work for you out of the box. If you still have issues with it, feel free to open a new issue!

[jwmann]

@lifepillar Alright! Thanks for the heads up 😄