Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
[Feature Request] Support easymotion-jumptoanywhere
See original GitHub issue[FEATURE REQUEST]
Hello,
I’m happy to report that I’m a daily user of vscodevim and really happy with the integration of easymotion so far!
It would be cool to support easymotion-jumptoanywhere, which is basically a combination of <leader><leader> w/W and <leader><leader> b/B - it searches for start and end of word on the entire viewport. Documentation.
It basically gives us the same functionality as jumpy, which has 16k installs despite the fact that it has never worked 🤣.
How easy / hard would it be to implement this feature? I’d happy to send a PR over the weekend if you could give me a hand on how you think it should be implemented.
Thanks!
xkxx
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:8 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Closed with https://github.com/VSCodeVim/Vim/pull/2454
Hey @Chillee!
Just took a look at the screenshot - that implementation looks nice and clean, as well as better matches how it works natively in VIM.
However, one thing that might be worth considering is how it looks & acts when there are a large amount of matches. For reference, this is how standard easymotion looks with a lot of matches:
Note how much the text gets shifted around in certain parts, making it easy to get lost; the number of shortcuts can be so large it garbles the text and location too much to reasonably decipher which key to press.
One thing I do like about the way it is currently implemented in VSCode is that since the keybindings are just UI labels, you can actually see part of the text behind the labels, and it doesn’t shift around the position text at all which means you know exactly where to go. While the current implementation could definitely use some improvement displaying a large amount of matches in close proximity at once, it still seems less confusing to me than the native behavior where text is shifted around the screen to accomidate the longer strings caused by multi-key shortcuts.
Not saying one way is better than another per-se, I’m honestly cool with both implementations - just something to keep in mind if going down that route 😃