Restore behaviour of the n/N keys
Would it be possible to make the behaviour of the n/N keys configureable, or have the old behaviour of n/N reassigned to other keys? I heavily rely on pressing "n" to move me to the next line.
Thanks
To clarify, there's a cluster of search hits and you're expecting 'n' to move to the next line instead of the next cluster? Do you think you can get used to using j/down-arrow to move to the next line after getting to a cluster?
The problem is that our log lines tend to be quite long, so if I get to a cluster by pressing n, I don't necessarily know whether there is a hit the line below (because the match could be lots of screenful to the right). So yes, I would love to have the "move top line to next hit" (regardless of whether it is part of a cluster) behaviour restored / or remapped to other keys.
Not knowing there is a search hit because it's off-screen sounds like a problem in-and-of-itself. I'd like to try and address that before reverting the n/N change.
How about markers on either side? Just imagine one is right in the middle of a long log line, some pages to the right. Jump to the next line, the search term is somewhere near the beginning. Then we should get a marker to the left of course. However I think, jumping right to the occurrence is a better way.
Thank you for the added markers. This helps, but please consider making the cluster search functionality toggleable (e.g. via a /ui/cluster-search config). Thanks.
This is the only reason I haven't upgraded since 0.8.1. Any way I could help with this?
In the near future the keymap will be user-configurable, so you'll be able to define the keys to do whatever you like.
Hello @tstack, sorry to revive this old thread, but is it now possible to remap certain keys so that I can move between individual search results, as opposed to clusters of results? Thanks!