lnav

lnav copied to clipboard

If I type /foo <ENTER> and the first occurrence of foo is off the bottom of the screen, I have to press n to get to it. This is counter-intuitive, since in every other search interface I've encountered, as soon as you enter the search, it jumps to the first occurrence.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39423808-search-doesn-t-jump-to-first-result?utm_campaign=plugin&utm_content=tracker%2F449456&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F449456&utm_medium=issues&utm_source=github).

It's a live search, if you don't press <ENTER>, it will move the view to the first hit. I've just become accustomed to the behavior at this point. I suppose I can make it jump to the first hit if one is found right away, but otherwise the search will run in the background and I don't want to block the UI waiting to scan all the files.

Ah, I see what the confusion is here. I'm talking about a situation where I type the whole search string and press Enter even before the live search has found the first match. In that situation the view doesn't move at all, and that's the bug I'm talking about. IMHO as soon as Enter is pressed it should always immediately jump to the first match, since that's what happens in every other search interface I've encountered.

What if it takes 10 seconds of searching a huge file to find the first match? I'm not going to block the UI waiting for the first hit and I'm not going to yoink the user away from what they were doing when the first hit was finally found. I can change the behavior so that it waits a fraction of a second to see if there are any hits and then moves to the first that was found.

I'm not going to block the UI waiting for the first hit

Why not? That's what other popular programs do, such as less(1) (sorry to keep quoting that as an example, but it really does get an awful lot right). The blocking would only be an issue if it was uninterruptible, and anyway the average user will probably instinctively expect Control-C to interrupt and cancel a long-running search.

The timeout threshold approach is a possible alternative to making the search interruptible, but the problem with that is that it's impossible to find a good value for the timeout. If it's too low then the first match won't get found and we're back to the problem we already have. And if it's too high then the user is forced to wait longer than their patience dictates.

Why not?

Because that's a behavior I am used to and it's never really bothered me in the last 6 years of using lnav. In fact, sometimes I use that behavior to highlight stuff in the running stream of text; and I don't really care to be yanked to the top of the page when I am looking at a live log.

A non-trivial amount of my day is spent working with lnav and the argument that lnav should conform to other popular programs does not sound convincing enough to be making changes to behavior that some of us are so used to by now.

I'm not going to block the UI waiting for the first hit

Why not? That's what other popular programs do, such as less(1) (sorry to keep quoting that as an example, but it really does get an awful lot right).

I have always found blocking an awful user experience in less/vim and is part of the reason I wrote lnav in the first place. Anyways, what's the point of doing the same thing that other programs do? That seems like a boring waste of time.

The blocking would only be an issue if it was uninterruptible, and anyway the average user will probably instinctively expect Control-C to interrupt and cancel a long-running search.

But, why make the user cancel out of something like that? The machine can do the work in the background and update the user as hits are found (in the bottom status bar and the ticks in the scroll bar on the right). The only interrupt the user should need to do is to start another search by hitting '/'.

The timeout threshold approach is a possible alternative to making the search interruptible, but the problem with that is that it's impossible to find a good value for the timeout. If it's too low then the first match won't get found and we're back to the problem we already have. And if it's too high then the user is forced to wait longer than their patience dictates.

I pushed a change that will move if a hit is found within a second, which seems to work pretty well on my system. I'll let it bake awhile and then close this out.

I pushed a change that will move if a hit is found within a second, which seems to work pretty well on my system. I'll let it bake awhile and then close this out.

This is looking pretty great so far, thanks a lot! There seems to be a corner-case where if you retype exactly the same search term when there is no match on the screen and hit Enter then the original behaviour returns (no jump to the next match), but this is definitely a minor issue which I think I could happily ignore!

Anyways, what's the point of doing the same thing that other programs do? That seems like a boring waste of time.

Just to clarify, I wasn't proposing imitating other programs for the sake of imitation. Obviously it only makes sense when other programs implement functionality worth stealing :-) (Conversely, I don't think it's worth deliberately avoiding standard approaches to interface design either - intuitive design is often based on consistency with existing software.) But this new behaviour seems a good alternative to the approach that less(1) takes, so I'm happy :-) Thanks again!