Option to have uniform highlighting?

[ggandor]

Option to have uniform highlighting?

[ggandor]

Every different highlight type has a function, the ones with the filled background are "shortcuts". You can reach those matches by typing the label character right after entering the first input. See the relevant part in the readme. I'm planning to add a separate section on the highlighting strategy though, with more elaborate explanations.

As for the low contrast, you can tweak any of the highlight groups to your liking, see :h lightspeed-highlight. (If you need further help, just ask, I don't know how experienced you are with Vim.)

I'm closing the issue, but feel free to continue the discussion here, and ask more questions if needed!

[oblitzitate]

Appreciate the explanation! The shortcut highlights must've zipped through my head when reading about it but I totally get it now.

I'm new to lua and neovim's api, but I assume I'm going to have to use vim.api.nvim_set_hl() to change the hightlights right?

[ggandor]

You can execute Vimscript in Lua by using vim.cmd('...'), I think that is the simplest way for the moment.

" Insert your preferred colors in place of XXX, see :h highlight-guibg, :h highlight-guifg, also :h highlight-args
vim.cmd("highlight LightspeedLabel guifg=XXX guibg=XXX gui=bold")
vim.cmd("highlight LightspeedShortcut guifg=XXX guibg=XXX gui=bold,underline")
" ...and so on, for all the highlight groups you want to modify

[jandamm]

Sorry for digging this out @ggandor.
I'm not really sure what the difference between LightspeedLabel and LightspeedShortcut is. They're highlighted differently but in the end it makes no difference typing f or j in the screenshot above. Even though f is a Label and j is a Shortcut.
I get that a Label is defined by require 'lightspeed'.setup { labels = { ... } }. Is there any other difference?

[jandamm]

Sorry, I just found it out myself...
When typing s{char1}{char2} there seems to be no difference (right?).
When typing s{char1} the Shortcut can be used omitting the second char.

Maybe it'd be less confusing if the Shortcuts would highlight as Label when the 2nd char is typed (when above assumption is true).
What do you think?

[ggandor]

@jandamm

When typing s{char1}{char2} there seems to be no difference (right?).
When typing s{char1} the Shortcut can be used omitting the second char.

Yep, exactly.

Maybe it'd be less confusing if the Shortcuts would highlight as Label when the 2nd char is typed (when above assumption is true).
What do you think?

The basic principle is that after s{char1}, every "beacon" should stays as it is, we just eliminate certain targets from the set in the following step. The reason behind this is that it doesn't work like s{char1}... what is the next step? hmm... {char2} ... let's check the label then... {label}, but instead s-char1-char2--while-almost-unconsciously-processing-the-appearing-label--label, in one continuous flow, that is the very point of this plugin, as opposed to its predecessors. This works significantly worse if there's any kind of change in the position or the appearance of the label between the steps.

I have tired many variations while developing the plugin. I have even tried a version similar to your suggestion, quite recently, a week or so ago: I wanted to make the system (presumably) more consistent, based on the principle that every entity gets the same highlight if that leads to the target directly (= if you press it, you'll land on the target in the next step), be it a character from the match itself, or a label. This means that in the 2nd step, all normal labels will suddenly change to "shortcuts". But, because of the reasons described above, it didn't work so well as I imagined. I'm pretty convinced now that the current system is the most efficient/ergonomic one, that cannot be improved significantly (at least without some totally new, groundbreaking approach we haven't even thought about yet).

[jandamm]

The reason behind this is that it doesn't work like s{char1}... what is the next step? hmm... {char2} ... let's check the label then... {label}, but instead s-char1-char2--while-almost-unconsciously-processing-the-appearing-label--label

That is exactly the reason why I find it confusing.
I never typed s{char1} so I didn't even notice that the second char would stay the same. So I wondered why some chars look different than others.

When pausing after s{char1} it does make sense though as it indicates a quicker jump.
This also explains the strong highlight.

[ggandor]

Right, shortcutting only works when one types slower than usual, e.g. starting with something like s(. But that doesn't invalidate the above reasoning, that is, the highlights should stay the same for the 2nd round, whether it's a shortcut or not, because your brain starts processing the label unconsciously after the first input anyway, and any change has the potential to confuse it. At the same time, shortcuts obviously need some different highlight than the labels, by definition, so I don't see any other way to do this.

[jandamm]

Only solution I'd see is to introduce another highlight group for the Shortcuts after the second char which would look identically but could be linked otherwise.
But I'm not sure if it's worth the additional complexity.