bug#41338: Toolbar-bug in Emacs 27.0.91/Pretest

[Eli Zaretskii]

On May 17, 2020 4:37:12 PM GMT+03:00, Stephen Berman <stephen.berman@gmx.net> 
wrote:
> On Sun, 17 May 2020 16:12:38 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > On May 17, 2020 3:59:55 PM GMT+03:00, Stephen Berman
> <stephen.berman@gmx.net> wrote:
> >> The bug reported in the OP (the unexpected tool bar change) seems
> to
> >> be triggered by isearch (it was part of the OP's recipe and I
> haven't
> >> been able to reproduce it without using isearch), but maybe the
> >> observation about isearch I reported in my followup is a separate
> bug
> >> or perhaps no bug, even though it surprised me.
> >>
> >> Steve Berman
> >
> > So the problem is that the toolbar is not reconfigured to reflect
> the fact
> > that we are in Isearch?
> 
> In the OP the tool bar change was in the message-mode buffer, not the
> buffer where isearch was invoked.  My additional observation was that
> in
> the latter buffer the tool bar and lighter indicated isearch in
> progress, but the overlays were missing and point was in its
> pre-isearch
> position.
> 
> > Does it make sense to remain in Isearch in tbis scenario?  Could it
> be
> > that we are over-engineering this stuff?
> 
> As I reported in my followup to Martin, it is only when deleting the
> frame by clicking the toolkit's close frame button that isearch
> remains
> in progress, with `C-x 5 0' it is cancelled.  So the former seems to
> be
> the problematic case, since it's also the method used in the OP.
> 
> Steve Berman

Yes, I was asking whether wr should simply not try remaining in Isearch when 
frames are switched or deleted.  Juri seems to say that we try not to leave 
Isearch in some of those cases.