-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure correctness while typing a query fast #270
Conversation
Codecov Report
@@ Coverage Diff @@
## master #270 +/- ##
==========================================
- Coverage 90.74% 90.53% -0.22%
==========================================
Files 1 1
Lines 508 507 -1
==========================================
- Hits 461 459 -2
- Misses 47 48 +1
Continue to review full report at Codecov.
|
OK, but by pressing another "special key" ( The reason for case CTRL_A:
cursor_position = 0;
if (!dofilter)
dochoices = 0;
break; in 59ddc0f is to avoid a blank screen (with no choices) for |
Ah, good catch. Just updated #270 with a potential fix. I this works, |
Great! Works perfect! Closing #268 in favor for this ... |
Typing a query fast enough to trigger the poll check in filter_choices() could yield a wrong set of choices. Since filter_choices() is interrupted, all choices have yet not been examined and potential matches could still be left unexamined. Calling print_choices() in this state causes the unexamined choices to never be reconsidered as potential matches since they will have a score = 0. The solution is to never call print_choices() if filter_choices() was interrupted. Problem reported and partial solution provided by Jenz Guenther in GitHub issue #268.
Enabling dofilter implies dochoices by now. Therefore, there's no longer necessary to fiddle with dochoices for each key binding that doesn't result in filtering of the choices.
Nice! Please try the latest commit which includes a simplification of |
That's it! Time for version 2.0.1 of |
Yes! I'm planning on releasing 2.0.1 next year (that's two days from now ) |
Typing a query fast enough to trigger the poll check in filter_choices()
could yield a wrong set of choices. Since filter_choices() is
interrupted, all choices have yet not been examined and potential
matches could still be left unexamined. Calling print_choices() in this
state causes the unexamined choices to never be reconsidered as
potential matches since they will have a score = 0. The solution is to
never call print_choices() if filter_choices() was interrupted.
Problem reported and partial solution provided by Jenz Guenther in
GitHub issue #268.