Changing the selection during a search is performed but not visually indicated

[josch]

And another regression from 0.7 to 0.8. In 0.7, when one hit the "down" key during an ongoing search, one could see the next entry selected once the search finished. Since 0.8, the same element is shown as selected after the search finished but when hitting enter or when hitting the "down" key for a second time, then one sees that the next item got indeed selected. It was just not shown! This can be very confusing and means that one should really avoid hitting any key during an ongoing search, or the item that is shown as selected after the search finished might not be the actually selected one. Please restore the behaviour from version 0.7

[pazz]

This is impossible for me to test because all my searches take less than a second.. Also, the behaviour in 0.7 was certainly not planned but accidental..

Quoting josch (2019-02-10 20:18:48)

And another regression from 0.7 to 0.8. In 0.7, when one hit the "down" key during an ongoing search, one could see the next entry selected once the search finished. Since 0.8, the same element is shown as selected after the search finished but when hitting enter or when hitting the "down" key for a second time, then one sees that the next item got indeed selected. It was just not shown! This can be very confusing and means that one should really avoid hitting any key during an ongoing search, or the item that is shown as selected after the search finished might not be the actually selected one. Please restore the behaviour from version 0.7

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.*

[jljusten]

I think I noticed something similar with s hotkey for toggletags unread. If I press s, and then quickly press the down arrow, the visible selection doesn't change. If I wait a few seconds and press the down arrow again, then the visible highlight goes down by 2 lines.

[josch]

@pazz with a couple of threads with a few hundred emails each in the result, alot easily takes 30 seconds or more to show the results. The bottleneck is not notmuch but alot. The same search takes a fraction of a second with notmuch. According to the debug log, alot tries to do "something" with all the messages in each thread even though it only is supposed to show one line for each thread.

Which behaviour in 0.7 was accidental? That alot would correctly show the new selection after a search instead of showing the item that is not really selected?

@jljusten yes, that's precisely the effect that I'm seeing

[pazz]

Quoting josch (2019-02-10 21:44:02)

@pazz with a couple of threads with a few hundred emails each in the result, alot easily takes 30 seconds or more to show the results. The bottleneck is not notmuch but alot. The same search takes a fraction of a second with notmuch. According to the debug log, alot tries to do "something" with all the messages in each thread even though it only is supposed to show one line for each thread.

Interesting.

Which behaviour in 0.7 was accidental? That alot would correctly show the new selection after a search instead of showing the item that is not really selected?

hehe, No: Actually, I don't remember ever thinking of user input while a search buffer is still being "filled". Pre 0.8, this was done concurrently, using a separate process. In 0.8 (iirc), this is done using async calls.