Add a simple amp-like jump command

[pascalkuthe]

Closes #274
Closes #510
Closes #5340

This is a simple amp-like jumpmode that @the-mikedavis and I have been toying around with for a while. When discussing/starting to review #5340 we found the PR more complex than we would like for this feature (a diff above 1k loc). We were uncomfortable with how closely it follows hop and the subsequent debate about emulating the million other jumpmode plugins out there. There are many different approaches to jump commands, and we cannot maintain them all in core. Instead, we want to pick a single opinionated choice that we feel fits well with the rest of the editor.

While testing that PR we made the following observations:

• character based jumps (which require a character before tying a label) don't really hold their water, you can use f for simple cases and / (which we want to improve further) for complex cases. Compared to a jumpmode these commands work with multicursors.
• word base jumps can be useful for quickly repositioning the primary cursor.
• a simple implementation like in AMP without dimming, color changes and complex letter assignment based on distance, ... was not only a lot simpler to implement but also more predictable/less disruptive

Based on these observations we decided to mostly follow amps implementation. This PR also has a more correct implementation fixing issues I found with the original PR (labels would appear on single char words, punction and would include leading whitespace, ..).

This PR contains a cherry pick from #6417, depending on which PR is merged first I will rebase the other PR and drop that commit

[danillos]

I was testing it and I didn't see any issue so far on the current implementation. Nice work.

I have a question, would it be possible to work in all visible buffers? So we could go to a word in another split window?

[David-Else]

I have been testing it and it works brilliantly, thanks!

[Omnikar]

Should the default value for jump-label-alphabet be reordered to prefer QWERTY home-row characters first?

[archseer]

Looks fine to me but I'm not a jump mode user. I'd be interested in @semin-park's feedback as the original PR owner

[pascalkuthe]

Should the default value for jump-label-alphabet be reordered to prefer QWERTY home-row characters first?

We generally don't try to tailor our keymap to qwerty (many people use different keymaps). Using the alphabet is a pretty reasonal default IMO.

I have set the setting to my (colmak) homerow plus some keys that are easily reachabke. What exactly those are is highly individual.

[David-Else]

Should the default value for jump-label-alphabet be reordered to prefer QWERTY home-row characters first?

We generally don't try to tailor our keymap to qwerty (many people use different keymaps). Using the alphabet is a pretty reasonal default IMO.

I have set the setting to my (colmak) homerow plus some keys that are easily reachabke. What exactly those are is highly individual.

Alphabet is certainly a good default, but having a config option to prefer the home row keys of QUERTY / Colmeak / Dvorak would be next level awesome :)

I have set the setting to my (colmak) homerow plus some keys

How is this possible? Cheers!

[pascalkuthe]

just add this to your config (under editor, its also documented in this PR):

jump-label-alphabet = "eirsaotndhfuywgm(cplbjvkx)z_"

That example is for my personal layout (colmak) where brackets and underscore are on the base layer. Basically the letters that come first are used first so e, i r and s endup close to cursor (and for me used most often). You may also completely exclude some hard to reach letters (like q in my case)

[David-Else]

@pascalkuthe You are amazing, you thought of everything. Sorry I didn't see that in the PR and wasted your time.

[Omnikar]

Should the default value for jump-label-alphabet be reordered to prefer QWERTY home-row characters first?

We generally don't try to tailor our keymap to qwerty (many people use different keymaps).

Doesn't having hjkl as default directional controls already do that?

[the-mikedavis]

hjkl is a historical artifact, not intentional bias towards qwerty

[qwerty01]

Would it be too difficult to add in the character search mode as well? One case where the word base jumps can still be a bit difficult to use is when you want to jump to the beginning of a portion of code that has a lot of symbols, such as jumping to the beginning of the array at ["--lsp"] (which gets changed to ["--cnp"] in the screenshot):

Or jumping to the open bracket or generics of a function:

It also can't jump to single characters, but I'm not sure that would actually be an issue in practice:
(edit: this was explicitly mentioned as intended behavior)

Another nice to have would be jumping into the middle of identifiers, such as words separated by underscores like in these functions:

but there doesn't seem to be an easy way to implement this.

Or maybe character search should be another PR to keep this one less cluttered.

[Omnikar]

@qwerty01 I think the recommendation for that is to just use search (/ and ?)

[qwerty01]

/ and f would work well for spots that are easily searchable, but braces and other non-word characters are usually not very searchable since they're 1 character and would have lots of matches. With the current solution, it would probably be finding some other spot on the line and then doing some other key combinations to get to the spot you want to, but that kinda defeats the purpose of amp jumps, which is looking at the spot you want to go and typing the keys that pop up.

[Omnikar]

Well you could also type characters before and/or after the brace you're trying to jump to when using /.

[qwerty01]

Oh quick aside, found an issue when scrolling while jump mode is active, only the visible screen at the time of enabling jump mode gives jump options, so if you scroll while jump mode is active, there aren't more options to jump:

Also probably a use case that won't come up often but figured I'd mention it.

EDIT: The limits are explicitly set on line 5882 and 5896, removing them doesn't cause any noticeable performance issues, but still leaves large files mostly unmarked since we run out of jump labels.

EDIT2: Mistyping a jump code can lead to jumping off the screen if it corresponds to a location that was marked off the screen, so it might be best if the current functionality is kept, or maybe exiting jump mode on scroll would be better.

[the-mikedavis]

Yeah, I think we should clear the jump labels / exit jumping mode when the viewport changes (scrolling, resizing, etc.). It's only meant to jump to locations that are visible/in-view.

I have a question, would it be possible to work in all visible buffers? So we could go to a word in another split window?

Currently it's a regular motion so like w/b/e or text-objects it only works on the current view (window). IMO jumping across views is not necessary to optimize for - I think switching views and then jumping within the view would work well enough.

[pascalkuthe]

Yeah, I think we should clear the jump labels / exit jumping mode when the viewport changes (scrolling, resizing, etc.). It's only meant to jump to locations that are visible/in-view.

I have a question, would it be possible to work in all visible buffers? So we could go to a word in another split window?

Currently it's a regular motion so like w/b/e or text-objects it only works on the current view (window). IMO jumping across views is not necessary to optimize for - I think switching views and then jumping within the view would work well enough.

yeah I fixed this by simply dismissing any pending (or pseudo pending) keys whenever a mouse button is pressed (also during bracketed paste). I think mouse buttons behaving the same as other keys in that regard just makes sense. I think this will fix quite a few similar bugs.

[wontem]

Another quick question, is it necessary to have an anchor in the current cursor position (if you're already in the beginning of a word)?

[James-Firth]

Docs are clear and the feature works great! (Just did my first build to test this out)

EDIT: After using it for a bit I get why it's like that, this is better than what I expected! And thanks to trying to respond to a reply I've also answered my own concern about the colour support.

Is it intended to put the cursor at the end of the word you jump to and select the whole word? If so, working great!

Jumping in only after skimming (and not being familiar with amp) that's not what I expected (coming from EasyMotion in VSCode with vim bindings). I could see why you'd often want to act on the word you just jumped to so I can see the logic behind that behaviour!

Just have one comment/question about themes below

[postsolar]

I noticed that, unlike search_next and similar commands, goto_word does not respect selection orientation.

[pascalkuthe]

It does in visual Mode just not on normal mode. It's intentional.

[postsolar]

Got it, but what is the reasoning for this?

[the-mikedavis]

See my comment above: #8875 (comment)

It matches the LSP location jumping features

[lucmos]

Thank you for this feature! It's working great 😄

Just a quick question -- Is it possible to "add" a selection to the word I am jumping to? Without extending the current selection as in visual mode, i.e., an easy way to add multiple cursors.

[the-mikedavis]

There's some discussion about that above: #8875 (comment)

[giann]

Great feature however, the jump point have the same color as the word they're in for me:

How can I fix this?

[pblkt]

It's likely that your theme doesn't define the ui.virtual.jump-label or the fallback ui.virtual.

To verify that this is indeed the issue, check that the labels in :theme default are highlighted as expected .

To fix, make sure your theme defines it by either creating and using a local one or opening a PR.

[giann]

That was it thank you