> From: Gregor Zattler <grfz@gmx.de>
> Cc: bug-gnu-emacs@gnu.org, notmuch@notmuchmail.org
> Date: Wed, 09 Nov 2022 15:35:01 +0100
> 
> > The backtrace seems to indicate that it reads from the minibuffer, but
> > in that case, does it mean the mini-window was 7-lines high in this
> > case?
> 
> quite possible, I have quite a few saved searches which are
> presented to me.  The hight of the minibuffer also depends
> on the frames width.  If the frame is half of the width of
> my monitor the choices are listed in 6 lines, then there is
> a blan line and a final line with a prompt.  In fullscreen
> it's 3 lines of choices, the blank line and the prompt.
> 
> > Also, can you describe what you do to trigger this assertion
> > violation?
> 
> I can do so only on the level of user interaction: I call
> notmuch-jump-search via it's key binding which is key chord
> prefixed.  Then I enter one or more chars to select the
> specific saved search I want to perform.  It might be
> possible that I'm typing faster than Emacs performs this
> commands.  Emacs hits the assertion with the choices still
> visible.  I cannot say if it does so after my last key
> stroke or in the middel of them.

OK.  I installed a possible fix.  Can you update from Git, rebuild,
and see if it eliminates the assertions?
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org