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.

[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

[markstos]

danillos 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?

@the-mikedavis jumping across views is not necessary to optimize for - I think switching views and then jumping within the view would work well enough.

Allowing this to work across all visible windows could be an elegant way to directly switch to another window to reach ones that can't be directly access by simply going "left/right/up/down" or to the last window.

wmfocus, sway-easyfocus, tmux, and some vim plugins all offer a way to switch to another window by selecting a letter. Here's the concept implemented in sway-easyfocus:

demo.mp4

This allows navigating directly to any visible window-- helpful on 4k screens where 6 or Helix windows can fit in a terminal.

By extending it to every visible window, the feature would be useful for both "amp-like jumping to a location in the current window" as well "switching to another window by label".

[pickfire]

I noticed there is a bug where jump label switches positions with the text when cjk characters is involved, which causes layout shift, making it hard to know where to jump to.

I think it should preserves the existing positions if cjk characters is involved, otherwise the user need to read the whole thing to know where to jump to again.

For example

After gw, it becomes

In the second line, it should pad the first cjk character so it doesn't do layout shift either. The same goes for emoji and double width characters.