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

mg979 / vim-visual-multi

Multiple cursors plugin for vim/neovim

MIT License

4.2k stars 80 forks source link

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

Open eyalk11 opened 1 week ago

eyalk11 commented 1 week ago

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

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 commented 1 week ago

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

eyalk11 commented 1 week ago

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

vds2212 commented 1 week ago

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

vds2212 commented 1 week ago

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 commented 1 week ago

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 commented 6 days ago

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 commented 5 days ago

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

vds2212 commented 5 days ago

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

eyalk11 commented 1 day ago

@mg979 ? If you are still maintaning it.