Some of user-defined operators not works

[Shatur]

Describe the issue:

I see that support for all user operators was added in 4e0df743077e9c41ddd4a86fa88e690fce2fbc4a. I tried it with vim-sandwitch operators, but adding surround operation not works because it highlights word and requires to type a surround symbol after the command. Highlighting just blinks after saiw. But if I use this command manually and repeat by dot - it works. Video:

Is it possible to fix?

Steps to reproduce:

0. Install vim-sandwitch
1. Add several cursors
2. Execute saiw.

Settings:

let g:VM_maps = {}
let g:VM_maps['Select Operator'] = '' "Need to remove this mappings to avoid conflitcs
let VM_user_operators = [{'sa': 2}] " I also tried to specify 3

---

• Operating System: Arch Linux
• Vim Version: NVIM v0.5.0-608-ga6917f840
• commit SHA/branch: 42e8c27d63d8019a63ec040ccde63d0752797f9e

[mg979]

You can remap (or unmap if you don't use it) the Select Operator that is using the s key.

Edit: you're doing it already.

[Shatur]

Yes, I know. This what I do in the specified settings above, but the custom operator still not works.

[mg979]

If the operator is sa then {'sa': 3} should work, but then not for all combinations. This is a case of a complex operator that would need a function of its own. You can do \\z and it should work. Or you could write a function that works in VM and does what you want, and map it to sa inside VM (keeping Select Operator unmapped).

[mg979]

Please understand that I cannot write custom stuff for every plugin out there... I'm already supporting vim-surround for this kind of things and I think it's enough for most cases. And you can use \\z to run commands at cursors for things that are not built-in, those commands are there for this purpose.

[Shatur]

Thanks for the explanation. Of course I understand that you can't support every plugin. But I \\z not works for this case too (it works the same as with user-defined operators). Let me explain it more clearly: After execution saiw the plugin highlights the inner word and wait for user input, then adds typed symbol. With \\z it highlights every word for a few milliseconds and not wait for any user input. Is it expected? Also I understand that this can be non-fixable, just asking.

[mg979]

Maybe the plugin doesn't work with a real operator, but it uses getchar() or similar methods, in this case it cannot work because VM just passes the mappings. You could ask the author of the plugin if he wants to add support for VM, it's not something I can fix if it doesn't work with \\z either.

[Shatur]

Got it, thank you!

[Shatur]

I'm sorry! I found that \\z will work if I specify full command with symbol. saiw{ will work. So, I tried the following:

let g:VM_user_operators = [{'saiw': 1}]

This allows me to execute saiw{. But if I trying saiw' or saiw" VM says ...Aborted. Are quotes reserved for this plugin?

[mg979]

Are quotes reserved for this plugin?

No it should work. But do you realize that {'saiw': 1} is not an operator, is almost the full command? If \\z works you can use that (and maybe use an easier VM leader).

:h g:VM_leader-dict

[Shatur]

Yes, I tried saiw because if I understood correctly there is no way to define an operator sa followed by the w or iw and with brace symbol after it. let g:VM_user_operators = ['sa'] will stop execution after saiw or saE (e.g I can't type saiw{).

Because of it I tried {'saiw': 1}, but this not works for all cases... Can this be related because saiw contains iw inside it?

Also I tried {'sa': 3} but this stop execution after saiw (not allow me to type saiw{).

Also something like {'sd': 1} (delete brace) or {'sr': 2} (replace brace) works as expected.

If this is expected I will just use \\z as you suggested.

[mg979]

I think you should do yourself a favor and use vim-surround.

[Shatur]

:D I just like vim-sandwich more. Just weird that ysiw] from vim-surround works as expected, but saiw] not :(

I thought {'sa': 3} will allow me to insert any 3 characters, but it seems like if some of these characters are a text object it stops execution. So, is this a bug or not?