After a recent commit, the shortcut labels will remain on screen after pressing s as a label

[againxx]

After a recent commit 6f3f20a, when the s key appeared in the label lists, and have been pressed for a jump. New labels will appear and remain forever.

In the following example, I first pressed us and the s was shown as a normal label.

After I pressed s to jump to the destination, a set of new labels appear and won't disappear before pressing any key.

[ggandor]

This is intended. You can walk through the matches by pressing <Plug>Lightspeed_s repeatedly, as with f or t. If you'd change the first label on the list to something else, the plugin would exit as usual, but it's logical to use the key mapped to <Plug>Lightspeed_s as the first label too, since they are functional equivalents of each other. NB: Those are not "new" labels technically, but the old ones highlighted as "shortcuts" from then on.

The labels remain there forever, because 02c3138 disabled the default auto-exit for s/x, but you can still set the timeout manually, if you like the feature.

[mikehaertl]

@ggandor I'm suffering from this, too. To be honest I don't get the idea here. If we entered the label for the first match, we already made a choice. Why should we want to walk through other matches? Maybe I also misunderstand completely. This plugin started to do a lot of magic things that unfortunately start to get in the way now.

What I want to achieve is basically disable all this auto-magic as it's too much for my brain. It breaks my flow when I have to consider that behavior after jumping to the first is different than for other matches.

I would prefer to simply have labels for everything (including first match). As the config option for this was removed, I tried with setting safe_labels = nil. But then I suffer from the problem described here.

I also used the timeout feature (which I actually suggested some time ago #62) but I'm not happy with it either. Things often either go to fast (especially if I have groups - my brain needs time to get what's going in) or too slow.

[mikehaertl]

Ok, I figured it out. I thought you talk about safe_labels above - but you meant labels. So not listing s in labels really seems to do the trick.

[ggandor]

@mikehaertl You are right, I've already made a note to myself. Generally, we should only allow this super-clever instant-repeat mode (where the labels also remain available) when there are no unsafe labels, i.e. if someone always uses auto-jump. I will fix this ASAP.

[ggandor]

To be honest I don't get the idea here. If we entered the label for the first match, we already made a choice. Why should we want to walk through other matches?

This is just an alternative, in some cases, or for some people, it might be more comfortable (less mental energy) to simply type ;;; like a machine gun, and jump from match to match, if the target is, say, the 2nd-5th match - that is, to use s like f/t. But, similar to f/t, we also allow s itself to trigger repeat, instead of a separate, dedicated repeat key (;). This is nothing new in itself, Sneak works the same way, which in turn took the idea from clever-f, and extended it to s/S.

[mikehaertl]

I see, thanks for the clarification.

Sidenote: It would be great to see more terminal recordings (in the README or on a dedicated page) to show more/all features. It's much easier to learn if you see things in action than to wade through a long and complex description. (If only there was a pause key for animated GIFs, though. Did you consider something like asciinema? I also found a nice roundup of terminal recording tools here: https://linoxide.com/linux-terminal-recording-tools/. But for a start even more GIFs would be fine.)

[ggandor]

Yes, absolutely. See #75. Any further ideas are welcome.