Space character in labels

[Flosker]

And useless search character prefix, which confuses user.

Screenshot 1

Screenshot 2

Screenshot 3 - Hop

Screenshot 4

1. In screenshot above, I searched for e, The green color parts don't need first e to jump to, so they are confusing.

2. f & j in purple color need space key to be pressed first, which is not obvious, and space is neither in the labels config.

3. And why do I have very few 1 character jumps in Screenshot 2? Hop & Easymotion make jump labels as short as possible. See Line 1-6 in Hop screenshot.

4. In Screenshot 4, there is a capital H, which I didn't include in labels config, why is it there?

How to remove space form labels & e from those green color areas.

Config

require'lightspeed'.setup({
	jump_to_first_match = false,
	highlight_unique_chars = false,
	grey_out_search_area = true,
    -- Target keys
	labels = {'d', 'k', 'f', 'j', 's', 'l', 'a', ';', ',', 'c', 'm', 'e', 'i', 'w', 'o', 'g', 'h', 'v', 'n', 'r', 'u', 't', 'x', ',', 'q', 'p', '[', ']', 'z', '.', '/', 'y', 'b'}
})

[Flosker]

EDIT: I just found out Hop also has character jump feature, so I am staying with it.

[György Andorka]

Hi there!

I suspect you are misunderstanding how the s/S command should work (but that's fine, it means the documentation should be improved). Lightspeed's s/S is not like HopChar1, it's like an enhanced version of HopChar2. You should enter two characters as a search pattern, and you'll see one target label, that is an invariant. It is just a visual aid that the labels are visible right after the first input, so your brain can process them before you actually need to type them (this is one of the main inventions of this plugin). But you should type the second character in the pattern anyway. The advantage over Hop(/EasyMotion/Sneak)'s implementation is that while you're typing that second character, you already see the label, so there's no pause needed after that.

A quick primer on how the highlighting works:

• After entering the first character of the pattern, let's call it A, you see all possible 2-char matches that start with A.

• If jump_to_first_match is on, then certain matches will be highlighted as they are (the green ones here), without labels (hints in Hop terminology). Like eH in your example. That means you just have to type H after e (well, finishing the pattern), and that's all.

• All other matches look like this (let's say you'd like to jump to AB):
  original on-screen characters:
  [A][B]
  after entering A, i.e. the first input:
  [B-that-is-now-masked-by-the-label][label (_always_ one character)]

So those spaces are not labels, those are possible AB = e<space> matches, with B - that is, a space - shown in the first column, and the label in the second.

But there are a bunch of things on these screenshots that confuse me. My very first question: what colorscheme are you using? Why does the highlighting look like exactly the same as Hop's? Are they overriding Lightspeed's highlight groups? Because this highlight scheme makes it extremely confusing indeed. In the relevant section of the readme, you can see yourself that with the default highlighting the "masked" second characters (shown over the first ones) are much-much dimmer and less obtrusive than the labels (that are also underlined btw).

Moreover, if jump_to_first_match is turned off in the config, then there shouldn't be any "green" matches in the first place... (i.e. unlabeled ones, that are directly reachable.)

It would be great if you'd give it another try, now that the usage is - hopefully - clearer. I'm ready to answer any remaining questions/issues you have.

[Flosker]

1. Why does the highlighting look like exactly the same as Hop's?
   Because I configured the highlight groups. I found default highlighting to be confusing. Also, I only enable 1 plugin at a time.

2. jump_to_first_match is indeed turned off.

I will give it a shot!

[Flosker]

I tried & now it makes sense! I will probably keep using this one I guess, as it takes same amount of keys, but is more intuitive.

I do have one question, is it possible to ignore case? like in above eH?

[György Andorka]

I tried & now it makes sense! I will probably keep using this one I guess, as it takes same amount of keys, but is more intuitive.

Okay, cool, I'm glad! I hope the highlighting makes sense now, everything has a reason there. If you decide to tweak the colors though, you should definitely keep assigning distinct attributes to the different groups, like shortcuts, or overlapped matches.

I do have one question, is it possible to ignore case? like in above eH?

Not at the moment, unfortunately. For this plugin, it's technically challenging, both implementation and UI-wise (it would become problematic to decide how to assign the labels ahead of time). I have already addressed this issue in the Readme. I'm thinking about it, but it's a non-trivial task.

[Flosker]

Alright that's no big deal! Thanks for this great plugin ;)