Feature Request: highlight current search match

[noscript]

It would be great if I could distinguish the current search match from the rest.

For example in Vim and TMUX is it possible to configure highlight the current match and non-current matches differently. Chrome and Firefox can do that out of the box.

In Vim:

Search		Last search pattern highlighting (see 'hlsearch')
CurSearch	Current match for the last search pattern (see 'hlsearch').

In TMUX:

copy-mode-match-style style                Set the style of search matches in copy mode.
copy-mode-current-match-style style        Set the style of the current search match in copy mode. 

How it looks in Vim:

https://github.com/user-attachments/assets/5add3f95-21a0-4366-afe3-b7af6d48b7dd

[gwsw]

In less, unlike vim, the current search match is always on the same line of the screen (the first line, or the line specified by the -j option). So it doesn't seem very difficult for the user to identify which is the current match. I'm not rejecting this idea, but I'd like to hear more motivation about why this would be useful.

[EL-git-git]

Using ^K at the beginning of a search means the location of the match could be anywhere on the page. Not sure if this affects anything.

[zzhaolei]

In the Kitty terminal, less is used by default for searching and scrolling through the buffer. However, it currently does not highlight the current cursor position. I believe that supporting different colors to distinguish the current location would make it much more user-friendly for beginners.

Here is an extreme example:

[gwsw]

I'm not sure what you mean by "current cursor position". I think you mean the current search match? But less doesn't really have a concept of a "current search match", and I'm having difficulty understanding what the desired behavior would be for this new feature to make it appear that there is a current match. When executing a search, less highlights all matches, and scrolls so that the first match after the target line is now on the target line. I think you want that particular match to be colored differently. But this raises a number of questions:

1. If you scroll, for example with the j command, should the specially colored match remain specially colored?
2. If you scroll so that a different search match is now placed on the target line, should that match become specially colored?
3. If you jump away from the current screen, for example with the g or p command, and you happen to land on a page with a search match placed on the target line, should it be specially colored?
4. If you jump away from the current screen and then return to it, should the match that was specially colored previously now remain specially colored?
5. If you disable highlighting with the ESC-u command and then re-enable it, should the specially colored line again appear specially colored?

I'm having a hard time imagining a conceptual model that produces obvious answers to questions like this, of which there are many in addition to these above.

[avih]

I think the model is editors, where the cursor typically moves to the next match and highlight it.

There are two main models I know if:

GUI editors, where the cursor can typically be outside the visible screen while scrolling (but on key navigation or editing the view "jumps" to where the cursor is).

In the GUI model the cursor (and last match highlight) stays at the last match even if scrolled outside the screen, and when scrolled back into view, and "find next" finds the next match from the cursor (even at the same line), and brings it into view if needed.

I think most gui editors behave like this, for instance VSCode (multi platform) or Notepad++ (windows) or Geany (unix/multi), but also some TUI editors, like micro (cross latform).

Then there's the model of vim, where, at least with my config, the cursor can't leave the screen.

This is similar to the GUI model, except that if the last match is scrolled outside the view, the cursor still stays at the view, and the next match is always from the cursor - so not necessarily from the last match if it was scrolled out.

I think one way to look at it is that highlighting the last match differently can serves two porpuses:

• Identify it if navigating away from it and then back so that it's visible again, or even if just scrolling a bit while it's still visible.
• Visible indication where "find next" will start it's search from (if it's in view).

Whether this can fit into the model in less where, as far as I know, the search always starts at the top visible line, and find-next starts at the 2nd visible line, and, unlike editors, a line is only matched once, even if it has multiple (highlighted) matches, is not something I know.

I do generally like the behavior of last-match-highlighted (differently), but making such thing useful in less needs some though to specify a reasonable behavior for such feature.

[gwsw]

Yes, I agree with all that. Highlighting the current match makes sense when there is a cursor in the text that moves to the next match when doing a search. It's much less clear what "current search match" means in less, which has no such cursor.

BTW,

as far as I know, the search always starts at the top visible line, and find-next starts at the 2nd visible line,

This is the default behavior, but the search starting position can be changed by the -j option.

[avih]

as far as I know, the search always starts at the top visible line, and find-next starts at the 2nd visible line,

This is the default behavior, but the search starting position can be changed by the -j option.

Yeah, I recalled there was such option, just not exactly which one :)

It's much less clear what "current search match" means in less, which has no such cursor.

Indeed. Off the top of my head, I can think of few things which might be useful, which could be mixed and matched to figure out a behavior.

Add an "editor-like" search mode, where the "edit cursor" is generally assumed at the begining of the top visible line, so that's where a new search start (like now), but "find next" works like in a GUI editor.

That is: multiple matches can happen at the same line, and the last match is highlighted differently, and the cursor is assumed at the last match, which is remembered even if scrolled out of and back into view (together with its highlighted match).

Find next starts at the "cursor", even if outside the view.

If the search is cleared (or a new search starts?), then the cursor becomes "normal" again (assumed at begining of top visible line at any given time).

Another option is like above, but with at most one match per line (all matches are highlighted, last match highlighted differently, but next match search would always start at the line next to the last match).

Another option is to only remember the last match (and its highlight, and it being the start pos for next match) only as long as it's visible. It does feel to me less useful than the previous ones, and I'm only suggesting it in case it's easier to implement.

Another option is purely cosmetic. Last match is highlighted differently, but carries no functionality other than being visible right after it was matched. In such case, I think the it should be cleared as soon as the content scrolled in any way, to not make people think that it indicates the start pos for next match (but if no scroll happened, then effectively it is the start pos for next match).

[avih]

Find next starts at the "cursor", even if outside the view.

Another option is like the 1st or 2nd ("editor-like" find next, once or multi per-line), but instead of "even if outside the view", do "only if it's in view".

I.e. remembers the last match and its highlight (as it goes out of and into view), but find next starts at the last highlight only if it's in view.