Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The vm#cursors#operation function does not respect user-defined motion #282

Open
ngpong opened this issue Oct 11, 2024 · 0 comments
Open

Comments

@ngpong
Copy link

ngpong commented Oct 11, 2024

I am more accustomed to mapping $ and ^ to - and =, respectively. When setting key mappings, by specifying the mode as OPERATOR, it allows them to work well with commands like d, y, c, etc., in the native environment.

While exploring the plugin, I found that in cursor mode, VM waits for a motions command and does not recursively handle "some" user key mappings. The root cause of this behavior is due to the internal call let s:single = { c -> index(split('hljkwebWEB$^0{}()%nN_', '\zs'), c) >= 0 }, which is a hardcoded check to determine whether it belongs to the motion set. I can accept that this is a "rule," but one counterexample that puzzles me is: user-defined operator commands can work normally via the vim.g.VM_user_operators configuration. From my limited understanding, the term "motions" covers both operator and motion. Since VM_user_operators works fine, could you consider adding user-defined motion as well? (For instance, making some efforts with VM_custom_motions.)

Anyway, thank you very much to the community, this is a fantastic plugin!

@ngpong ngpong changed the title The vm#cursors#operation function does not respect user-defined motions. The vm#cursors#operation function does not respect user-defined motion Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant