search

qutebrowser / qutebrowser

A keyboard-driven, vim-like browser based on Python and Qt.
https://www.qutebrowser.org/
GNU General Public License v3.0
9.45k stars 1.01k forks source link

Debounce search-in-document #8238

Open Lanny opened 1 week ago

Lanny commented 1 week ago

Closes #8134

Adds a new config entry search.delay which is an interval to wait since the last keystroke during search (//?) before submitting the search. This helps the search experience on large documents with more constrained hardware as we don't end up searching the document for each prefix of the entered leading up to the full query.

I selected 400ms based on a very unscientific source at the top of a web search suggesting the average typist types 200 characters per minute, or roughly a character every 333ms so by this (shaky) logic that gives a little buffer to ensure an average typist can complete their search query before a search is executed. Subjectively this delay is definitely perceptible, but not particularly sluggish feeling. I'm happy to change it to whatever seems reasonable, maybe the strongest argument is for a value of 0 since that's effectively what it was previously.

Lanny commented 6 days ago

Thanks! Could you please look into using throttle.py for this instead of hand-rolling this? I believe this would make things a bit simpler.

So throttle.py does something related but fundamentally different that what the code here is doing, throttle's semantics are "fire the wrapped function at most once every " while the code here is "fire the wrapped function after , if no other call is made. If one is, cancel the original invocation and schedule the most recent invocation to happen in ".

I think the latter is what we'd want in a scenario like this. With the throttle semantics we're guaranteed to execute an actual search on the first character typed, which is both the most expensive search (most matches), but also least likely to be what the user is actually trying to search for. Additionally short throttle intervals (like the proposed 400ms) means we're re-executing the search every 400ms while the user is typing and this still produces some chunky unpleasant delays when searching large documents.

I'd be happy to factor this debounce logic out into a class that constructs a callable in the same style as throttle though, if that'd be cleaner. This would be the only caller of it right now, at least as far as I know

Also, some tests are failing - maybe that delay needs to be disabled for the testsuite?

Yup, exactly that