-
Notifications
You must be signed in to change notification settings - Fork 150
-
Notifications
You must be signed in to change notification settings - Fork 150
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
Mapping interferes with regular commands #415
Comments
@igrekster If we ever implement an "eclipse motion action", things might become more dire as you might want to use it as an operator. |
@albertdev
This way we would put a motion command into the normal and visual maps and a motion text object into the operator map. So for the example above |
@albertdev, you mentioned in #425 that we really should fix this defect. I'd also like to see this defect fixed mostly because it's another regression from our last release. I just wanted to add my vote in case you were debating which defect to work on next. :) Also, thank you for spending so much time with Vrapper and contributing so much to this project. I really appreciate the work you're doing and I'm amazed at the things you're able to fix. I feel like I'm not pulling my own weight anymore but I'll try to help you out as much as I can. Thank you for continuing to move this project forward! |
@keforbes Actually, it's not a regression in the usual sense: Vrapper 0.32.0 and before also suffered from this problem, so I had to make the trade-off of fixing #409 or reintroducing this bug from long ago. After fixing #425, most corner cases are handled through the magic of Still, it would be nice to have more complete support for maps, we're still a while removed from Vim in that regard. I'll look at it in the coming days. As for the help, you're most welcome. I steal all the challenging work while you are left with the chores of releasing. ;) |
Mapping 's' to something in normal mode would have weird side effects: since KeyMapResolver would keep returning "NormalMode", pressing 'fs' used to trigger the 's' mapping even though 's' is not a prefix of 'fs'. Since the resolver now returns null when in the middle of a command, mappings will no longer be triggered in that state. One side-effect is that all KeyMapResolver instances can not return null after a CountConsumingState is traversed or they would break counts before remaps. Also added helper methods in ConstructorWrappers to help with operator keymaps (those need to return omap after the operator or when any count for the following motion was entered). Work for #415.
Just an update: I think I've made some good progress on this issue. All tests work, but I'm going to do some more tests and fixes as I think that most of our plugins could be broken with respect to counts before a text object. |
Plugins needed a bit of extra work to support counts before operator mappings. Work for #415.
I think this issue has been resolved, no more need for workarounds. |
I've updated the unstable update site with a new build (0.43.20140515) which includes this fix in case anyone else is interested in it. |
As mentioned in commit d089258, certain mappings can interfere with a normal command. For example:
When then pressing
di]
the "operator pending" caret remains active and the delete action won't finish.Instead, the
]]
sequence should only be matched with the command buffer when the current keymap was just (re-)entered.Optionally, a timer might need to be implemented which aborts the remap matching after a while and just proceeds with the command as entered (though this might be hard to do with the current code).
This bug was mitigated by commits d089258 and fa74be5, but fixing #411 by reverting these two commits has brought this bug back.
The text was updated successfully, but these errors were encountered: