[Feature request] Search highlight

[magras]

Could lf implement a feature similar to vim's hlsearch, which highlights all search matches?

[CatsDeservePets]

I looked into this myself some time ago. I only got search count showing back then. It required lots of changes as currently lf only searches till the next match and does not iterate over all matches. Highlighting would be even more complicated as one would need to extract the matching parts of the found filenames while also taking the truncation of too long file names in account.

Personally, I would like a feature like this as well but it would require some changes which might make the code convoluted.

[CatsDeservePets]

Hello @joelim-work!

I could really need your input here. This is a feature I would really like to see myself. I tried picking it up multiple times but it just seems a little overwhelming as it requires a complete refactor of the current search logic.

I think it will work something like this:

• Iterate over the whole dir and store matches inside a slice, similar to the way filters work
• Reload on changes
• Make clear command hide the results so one could map it like in vim so <esc> hides the results again

The tricky part will be colouring the matching parts of the file names inside printDir, especially keeping truncation in mind.

[joelim-work]

To me this feature sounds complex to implement because there are a number of edge cases to consider, in terms of both functionality and display.

• Are the search matches calculated on demand (e.g. when finding the next match, or drawing the UI) or are they stored/cached per directory? Note that the search pattern is global (app.ui.cmdAccLeft + app.ui.cmdAccRight during searching, app.nav.search after the search is saved) and not per directory, and that it is possible to change directory during the middle of a search, in which case the search pattern should immediately be applied to the new directory. Calculating matches on demand is easier than storing matches and having to keep it up to date.
• If the directory is changed (i.e. update from app.nav.dirChan, or a filter is applied), then the search will have to be reapplied. Again this is easier (probably works out of the box) if search matches are calculated on demand.
• How does incsearch affect the behavior? The code is designed so that if incsearch is disabled then searches are evaluated lazily, but this will now no longer be the case as the search has to be evaluated to find all matches.
• How should this behavior be configured? A boolean option like hlsearch might make sense, but there are different cases to consider:
  • The user might not want to have search highlight enabled at all.
  • The user might want search highlight to be enabled when searching.
  • The user might want search highlight to be enabled only when typing the search pattern, and then disabled after pressing <enter>.
  • Even after a search is complete, it can be used again via search-back/search-next, and in this case the search highlight should be enabled again.
• The clear command is used for clearing the clipboard, I don't think it makes sense to use it for clearing search highlights as well.
• Should there be a way to display how many matches there are, and which match, on the ruler? For example 7/10 means that there are 10 matching files, and the cursor is on the 7th matching file.
• What happens if a filename contains multiple occurrences of a search pattern, should they all be highlighted and be counted towards the match count, or should only the first occurrence be considered? I think the latter is more practical here.
• There should be a new fmt option to control the style of the search highlight. Should there be a default, and if so what is a reasonable value? Perhaps it is worth using reversed attributes otherwise it could conflict with the default file colors scheme.
• How does styling for the search highlight get applied 'on top' of the current style? If you change the color to draw the search highlight, then there might not be a way to get the old color back. Of course, it should be possible to draw the original filename first, then the search highlight afterwards - in this case should it also respect the cursoractivefmt option?
• As you have already mentioned, it is possible for a search match to be truncated. For example foobar.txt gets truncated to fooba~, and when searching for bar, the ba should be highlighted but the ~ should not.

Anyway these are some of the things you have to consider when implementing this feature, at least off the top of my head.

[CatsDeservePets]

• The clear command is used for clearing the clipboard, I don't think it makes sense to use it for clearing search highlights as well.

You are right, I got confused here. Instead a simple user cmd that checks the current value of the setting should work.