Open jaredpar opened 10 years ago
:+1:
@jaredpar I realize this is an old issue, but I'd be happy to help if you point me in the right direction. Are you still using this plugin?
@blainesch the main direction here is that EasyMotion needs to declare somehow that it is interesting in handling key strokes. Probably by just adding a GUID or to an ITextView
property bag. Essentially something where VsVim can notice EasyMotion and back off of key handling when it sees that.
Is it possible to have a generic key handlers that fires events that both plugins can listen to? This could be in the form of a separate plugin that these both depend on.
This plugin talking directly to vsvim seems a bit coupled, but at the same time it's not like there's a million plugins doing this sort of thing.
I'm new to C# but don't mind taking a stab at it, do you mind pointing me to some key files I would be interested in?
@blainesch a generic shared handler is possible but ends up requiring a third project. Adding values into a property bag is effectively the same operation though but not as strongly typed. I'm not sure there is a key file to put this into as it requires a couple of changes. Let me look at it.
:+1: I was super excited to see that easymotion exists for Visual Studio, but then totally bummed that it's not compatible with VsVim!
:+1:
@jaredpar This still occurs for me with EasyMotion 1.0.1 and VsVim 2.0.1.0 in Visual Studio Enterprise 2015 version 14.0.25123.00 Update 2.
Results: Insert mode is entered after pressing 'i' prior to pressing the highlighted destination character resulting in the highlighted destination character being inserted at the final destination location immediately after the jump.
Possible solution: Add an EasyMotion-mode to VsVim, triggered with EasyMotion shortcut, that causes VsVim to completely ignore the next two keystrokes (hackish but whatever). Could even possibly use the shortcut as an input toggle for the two plugins and have easy motion emit (but ignore) the shortcut after the jump to handoff input priority back to VsVim. Pretty disgusting but possibly easy to implement?
Maybe call easymotion directly from within VsVim, instead of making EasyMotion listen to keystrokes itself.
Agree. It would be cool feature of vsvim. Because they are really do not want to work together.
did this problem fixed?
Anyone know of a workaround? I would love to use both of these extensions, or substitutes if you know of any.
Could it just disable vsvim and re-enable vsvim at the end?
I'm using the Vim emulation in VsCode, and what they have done is embed easymotion into their vim emulator ( along with some other toys ) ... given both this project and the easymotion one have the same originator. Maybe this is an option for VsVim? just build it into the project and have an option to turn it on?
Is this still a problem?
@learc83 I haven't tried recently, but I'm guessing it's not fixed, I have mentioned in another thread on VsVim that there is another tool called AceJump that does something similar and works well with VsVim. You can also bind it to whatever keystrokes you like with your vimrc
I just tested out PeasyMotion and this also seems to work fine with VsVim. https://marketplace.visualstudio.com/items?itemName=maksim-vorobiev.PeasyMotion2022
Right now VsVim and EasyMotion are fighting for the same key strokes. Need to resolve this conflict