motions don't effect multi cursors when `vim-remotions` is installed.

[eyalk11]

Describe the issue: motions doesn't effect multi cursors in normal mode.

They only work on the current single one I have tried \\space and it seems to do nothing. Why the its status is not shown in \\l ?

Steps to reproduce

1. just enter normal mode and do a motion (like l)

I guess it is related to my configuration but have no idea how to debug

[eyalk11]

My suspicions were right. vds2212/vim-remotions plugin was the culprit . It doesn't work iff I load it.

[eyalk11]

Probably similar to this : https://github.com/jinh0/eyeliner.nvim/issues/59

[vds2212]

Thanks for reporting this problem. I'll try to reproduce it on my side. I'll let you know.

[vds2212]

Here is the problem I have reproduced:

If you register the h and l motions with vim-remotions:

let g:remotions_motions = {
      \ 'TtFf' : {},
      \ 'char' : {
      \    'backward' : 'h',
      \    'forward' : 'l',
      \    'repeat_if_count' : 1,
      \ },

When you are using vim-visual-multi when you are using these motion in multi cursor mode:

• the cursor only move for the current word/cursor and not for all the cursors
• when inserting text after the user (e.g. using the a operator) the text is insert like if the cursor has not been moved.

I believe the reason is that [vim-visual-multi] hijack the motions (i.e. introduces their own mapping for h and l) and these mapping get confused with the mapping for h and l that vim-remotions introduced.

I there is a solution I supposed it is in vim-visual-multi.

I had a look at the code but it seems rather complex.

Remark: If you don't have vim-remotions remapping h and l it seems to work fine with vim-visual-multi.

[eyalk11]

You can check if the current state is normal visual-multi-cursors , just return the original key. I don't know if there is a local buffer variable for it. I think your plugin take precedence . So if it does, it should handle these cases. Making vim work good is constant pain , balancing all plugins with their respective bugs. There are so much hacks and competing resources.

[vds2212]

vim-remotions is not aware that vim-visual-multi is on so it can adapt.

I believe that vim-visual-multi introduces a general mapping where vim-remotions introduces <buffer> mapping that overtake (win over the vim-visual-multi mapping) the vim-visual-multi mapping which is the cause of the problem.

A solution could be that:

• vim-visual-multi make use of <buffer> mapping instead of global mapping
• vim-visual-multi restore the mappings it override instead of just deleting the mapping it has introduced

[eyalk11]

I do agree that seems like a good solution. Do visual multi has a reason to use global mappings?

[vds2212]

I don't see any. The <buffer> mapping feature is already supported with vim 7.0.

[eyalk11]

@mg979 ? If you are still maintaning it.

[vds2212]

I had a closer look. It seems that vim-visual-multi already create <buffer> mapping for the motions but doesn't override existing <buffer> mapping for motions. A solution would be to let vim-visual-multi the override the <buffer> mapping but to restore them when it leaves the multi-cursor mode.