Control timeout of instant jump/instant repeat labels separately

[thenyeguy]

Currently, all uses of 2-character search use the same timeout (exit_after_idle_msecs.labeled). However, I would like the timeout to behave differently when an instant jump is triggered. Ultimately, the config I would like to use is for normal labeled jumps to have no timeout (so I have time to process the labels that have been selected), but I would like instant jumps to behave like 1 character search (e.g. the labels disappear quickly).

My general reasoning is that for a normal 2-character search, I'm not done until after I've selected the final label, and once a final label is selected all labels disappear. When using an instant repeat, there will continue to be labels even after my cursor has reached its final destination, and I would like those to disappear automatically after a short timeout.

This is especially confusing for me when an instant jump is triggered, since it feels like lightspeed has exited already, but there are still phantom labels in case I choose to do an instant repeat after.

I'm not sure exactly what fits best with this plugin's philosophy, but one of these two things would definitely match my intuition:

1. Add a third exit_after_idle_msecs.instant timeout, that I can set to some small value
2. Use exit_after_idle_msecs.unlabeled for instant jumps.

[ggandor]

Currently, all uses of 2-character search use the same timeout (exit_after_idle_msecs.labeled).

No, that is not entirely true. It is as simple and consistent as possible: if there are labels on the screen, the labeled timeout value applies, if there are no labels, only match highlights, then the unlabeled one (otherwise it is a bug). The kind of motion doesn't matter. For example, if you do a repeated 2-char search, but there are lots of matches (more than the number of safe labels), you can see that after the initial ; the labels will disappear, and change to match highlights. (Otherwise you could not exit safely.)

On the other hand, it is an intentional feature that the labels usually remain active even after ;. You might notice that there are too many matches to ;;;;;; through them, and want to use the label instead. What you're really asking for is a means for disabling this feature, I guess.

The problem is, I'm actually considering removing the timeout option entirely. It is a pretty useless gimmick actually: you most probably want to do something after a jump; the only exception I could think of is if one has some very big scrolloff value set, and want to use a lightspeed motion as a substitute for scrolling; that sounds a bit silly for me though, and in any case, is far from being compelling enough.

[ggandor]

otherwise it is a bug

...and indeed it is the case! Thanks for bringing this to my attention, I'll look into it ASAP.

Still, what about the rest (1. keeping the labels available as a worthwhile feature 2. do we need timeout at all)?

[thenyeguy]

No, that is not entirely true. It is as simple and consistent as possible: if there are labels on the screen, the labeled timeout value applies, if there are no labels, only match highlights, then the unlabeled one (otherwise it is a bug).

After experimenting a little bit more, I actually found the thing that was most disorienting to me was safe_labels, since that is what causes a jump without remove the graywashing, or the labels when using instant repeat. I'm experimenting with unsetting safe_labels. With that unset, it's just the highlights not timing out that bother me. Sounds like that's just a bug.

Still, what about the rest (1. keeping the labels available as a worthwhile feature 2. do we need timeout at all)?

For highlights, I definitely like those timing out (both for instant repeat and for f/t motion). One thing I do pretty commonly is move to a place where I plan to work on next, without having fully decided what I actually want to do. Leaving the highlights indefinitely is distracting. It's more of a polish thing, since the only key that is still bottled is s, and you can always just escape out of it.

Sorry if I'm unclear! I've generally found lightspeed to behave intuitively, but it seems like you built some complex concepts to accomplish that. I definitely had to spend a decent amount of time reading the manual to try to map what I'm seeing onto all those concepts. Lightspeed is definitely my favorite easymotion-style plugin though. Thanks for considering my feedback!

[thenyeguy]

I discovered your leap.nvim plugin, and tried it. I actually find it less disorienting, even with safe_labels. I think the combination of (a) no graywash and (b) repeat being opt-in with enter means that the jumping behavior is a lot more predictable. Surprisingly I don't even miss timeouts being gone there, due to the predictability.

So maybe leap.nvim is just more what I'm looking for, and my thoughts on lightspeed are less relevant? Either way, kudos for your great plugins.