Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instant-repeat should only use safe labels (or nothing) #123

Closed
ggandor opened this issue Feb 3, 2022 · 7 comments
Closed

Instant-repeat should only use safe labels (or nothing) #123

ggandor opened this issue Feb 3, 2022 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@ggandor
Copy link
Owner

ggandor commented Feb 3, 2022

See #102 (comment) and above.

@ggandor ggandor added the bug Something isn't working label Feb 3, 2022
@ggandor ggandor self-assigned this Feb 3, 2022
@ggandor ggandor changed the title Instant-repeat w/ labels should only be allowed if auto-jump is forced Instant-repeat should only use safe labels (or nothing) Feb 3, 2022
@ggandor ggandor closed this as completed in d648301 Feb 3, 2022
@mikehaertl
Copy link

@ggandor Hmm, I see no difference yet if I don't exclude s from labels. Here's my config:

require'lightspeed'.setup {
  -- Disabled: There's often not enough time to understand what's going on
  -- exit_after_idle_msecs = { labeled = 700, unlabeled = 30000 },

  -- do not autojump to first match (would keep greyed out area)
  safe_labels = {},
  -- exclude "s" (interferes with first jump) and add more labels
  labels = {
    -- comfortably reachable
    "f", "j", "d", "k", "s", "a", "l", "ö", "r", "t", "u", "e", "i", "v", "h", "c", ",", "n",
    -- weaker fingers or stretchy
    "w", "o", "x", "y", ",", "q", "p", "t", "b", "z", ".", "-", "+", "ä"
  },

  ignore_case = true,
}

@ggandor
Copy link
Owner Author

ggandor commented Feb 3, 2022

@mikehaertl Here I just fixed an actual bug that is loosely related to your issue (on the first quick reading, when I responded, I thought you have the same problem, sorry). s still enters instant-repeat, but the important thing is that if there are no safe labels, then the matches won't be labeled at all, they will simply be highlighted as they are, and can be reached by ssss/;;;;. So there is no danger of being taken to another labeled target when you press the next key (to do some edit) after landing on the second (s-labeled) target.

Providing an option to disable entering instant-repeat for s altogether is another question. We might do that, but as an API expansion, let's not rush it. Is the highlighting of the subsequent matches really so annoying?

Note: you can set the value to nil if you want to disable the timeout.

@mikehaertl
Copy link

s still enters instant-repeat, ...

I still think, that this is weird. All I want is to type s, then 2 letters for what I search, and then the target label. If this happens to be s (and I didn't exclude it) I expect that I am where I want to go and lightspeed is done.

Here I'm in line 1 and want to jump to od in line 20, so I pressed sod:

ls_1

Is the highlighting of the subsequent matches really so annoying?

To me it is, because now if i press the targe label s i see this:

ls_2

I don't know what happend, why line 7 is highlighted now and what I'm expected to do. So I have to press ESC which is extremely annyoing.

@ggandor
Copy link
Owner Author

ggandor commented Feb 4, 2022

The problem here is that s (or, to be more precise, whatever <Plug>Lightspeed_s is mapped to) as repeat trigger takes precedence over s (or whatever <Plug>Lightspeed_s is mapped to) as label. So for the moment, you can only use s as the first label, which is just a pseudo-label then, and in fact triggers a recursive (repeat) call. (It jumps to the first match, and highlights the subsequent matches, waiting for you to go on repeating with s, or fall through with some other key and exit.)
You can put some other key to the front of the label list though, and it will work as expected, exiting the function after landing. But you cannot use s as a label other than the first one, since you will not be able to reach that position then, for the aforementioned reason.

@mikehaertl
Copy link

I now finally believe that I understand what "repeat trigger" means. In my words I would rather call it "alternative navigation through highlight locations" (if you don't want to press label keys). Because it does not "trigger" another search, right? It keeps the higlights there and you move from one to the next. At least that's what I now think it does. If that's the case it feels - well - awkward, as to me this somehow cancels the whole idea of this plugin: To save you keystrokes. It reminds me of the first steps in vim when you hammered on the cursor keys to go up and down ... But that's probably just me.

Still I think this should be a feature that you can turn off easily. It took me quite a while to find out how to combine the config options to make the plugin not behave unexpectedly (i.e. learn that you have to set safe_labels off, to not get auto jump to first match - then find out that this gives you prolems with s and you need a custom list of labels ... quite a lot for such a simple demand)

@ggandor
Copy link
Owner Author

ggandor commented Feb 5, 2022

to not get auto jump to first match

I'm just curious why you (and probably a lot of others) don't find autojump helpful or intuitive. There remain labels on the screen, but those can safely be ignored, they won't interfere with your editing. (This is the very point of using "safe" labels.) I personally think auto-jumping to the first match is the best feature of Sneak/Lightspeed; the lack of it is one of the things that make working with EasyMotion/Hop feel much less fluid and efficient. It's so much more comfortable that for the closest matches I can just type the two on-screen characters, and voila, I'm right there.

I would rather call it "alternative navigation through highlight locations" (if you don't want to press label keys).

Think of it as repeating the motion, not the search itself (this makes a bit less sense if autojump is not on). But according to the current behaviour it is indeed more like entering a "walkthrough" mode. (Technically these are recursive calls, but in this case we pass on the target list we already have, so no new search loop is invoked.)

If that's the case it feels - well - awkward, as to me this somehow cancels the whole idea of this plugin: To save you keystrokes. It reminds me of the first steps in vim when you hammered on the cursor keys to go up and down ... But that's probably just me.

Related, interesting discussion: #25. I had exactly the same thoughts originally, but I've change my mind. I actually like the current, flexible system, although I indeed rarely use this kind of repeat (or walkthrough) mode in practice.

Still I think this should be a feature that you can turn off easily.

Yeah, I tend to agree.

@mikehaertl
Copy link

I'm just curious why you (and probably a lot of others) don't find autojump helpful or intuitive. There remain labels on the screen, but those can safely be ignored, they won't interfere with your editing.

In short: Too much mental load.

I consider navigating my text a secondary task. My primary focus is on my code logic. I want to stay focused on my primary task as much as possible. So navigation should be a no brainer: (Almost) no decision making, no extra mental load.

My problem with auto-jump is that it makes the plugin behave in different ways depending on where I want to go: Sometimes I need to press 4 keys another time 3 or maybe even only 2 (in worst case even 5 when I need to jump to another group - but that's probably unavoidable). Sometimes a greyed out area remains sometimes not. And I can't even tell in which way it will behave before I enter the search pattern. So too often I found that it steals my attention.

I prefer to always press 4 keys without further distraction. This way I know exactly what to expect. That's very easy to "store" as a mental side routine which I can call without getting distracted from my main task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants