Feature Request: Modern Search UX
Closed this issue · 6 comments
Is your feature request related to a problem? Please describe.
I haven't found a pager that has a search feature similar to modern graphical text editors or user-friendly terminal emulators such as GNOME Terminal or Konsole. I'm currently using the Kitty terminal emulator which searches its scrollback via a pager.
Describe the solution you'd like
- additional highlighting of the currently focused result relative to other results
- display number of total results and currently focused result (#102)
- incremental search (#105)
- context-dependent deactivation of incremental search, for instance
if (number of lines > X && search string length < Y). (I made this one up and would personally set it to something likeX=1000andY=4) (#105)
Describe alternatives you've considered
zellij, less, moar, most, kitty-kitten-search
Hey! thanks for filing the issue. It actually brought out some new ideas which I might have never looked at.
But I wanna tell you a that (2) is actually already implemented inside minus. If you look at the bottom right side of the prompt, its already there. But there is a bug where jumping to next current focus count doesn't change the number. I am working on it.
I will also experiment on the rest of the features that you discussed.
BTW if you don't mind, I want to edit you description to add checklist and PR refs as I create them so that I can track them easily.
BTW if you don't mind, I want to edit you description to add checklist and PR refs as I create them so that I can track them easily.
Of course, go ahead.
Hi there @J-Kappes! So I was experimenting with (1) and there are certain issues on which I would like to have your opinion.
So currently minus works by ignoring all the escape codes that come between inverting the background color of each match and just before resetting that inversion. By this method it is able to have the background of the previous text color. This makes it look better over other pagers but can cause some inaccurate output display. Now coming to how less does is it places all the escape codes regardless of any situation and that's why less search sometimes looks funky but output is less buggy.
Now if I start implementing (1) and take minus's previous route, then it would be surely possible but again, it can cause inaccurate color display.
I have no idea how to do this by taking less's route. I think that's the reason why popular pagers before minus haven't tried this before.
Anyway, if you any suggestions please let me know on this.
Sorry, but this is beyond me. I have very little in both practical coding experience and theoretical knowledge and will likely only be able to contribute from a user's perspective or at most implementing solutions that other people have thought through.
@J-Kappes so I was experimenting with incremental searching inside minus and it's coming up pretty nicely till now. It's like complete with finishing touches here and there. I will try my best to get a PR by today or tomorrow so that you can also try it out and report me if you find any issues with it.
Once it's done I will move on to working on (4), it seems it's easy one to get through.
I am mainly concerned with (1) and also fear that I may not be able to get going. IMO it may introduce more bugs than solving an issue. You see (1) requires a deep dive into how terminals use ANSI codes to format text and I find ANSI escape sequences to be really notorious on my part.
Anyways I will give it one last shot and if I find my implementation isn't worthy enough, I will create a separate issue on this and share all of my findings there so that if anyone is interested to work on that, they can jump ahead.
EDIT: Typos.
I am closing this PR as most of it is already completed.