bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#41338: Toolbar-bug in Emacs 27.0.91/Pretest
Date: Sun, 17 May 2020 16:12:38 +0300
User-agent: K-9 Mail for Android

On May 17, 2020 3:59:55 PM GMT+03:00, Stephen Berman <stephen.berman@gmx.net> 
wrote:
> On Sun, 17 May 2020 15:36:10 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > On May 17, 2020 12:11:04 PM GMT+03:00, Stephen Berman
> <stephen.berman@gmx.net> wrote:
> >> On Sun, 17 May 2020 10:56:50 +0200 Stephen Berman
> >> <stephen.berman@gmx.net> wrote:
> >> 
> >> > On Sun, 17 May 2020 10:20:55 +0200 martin rudalics
> <rudalics@gmx.at>
> >> wrote:
> >> >
> >> >>> But I don't know why the ‘delete-frame’ event is not fired on
> >> frame deletion.
> >> >>
> >> >> How do you delete the frame?  You don't get a 'delete-frame'
> event
> >> when
> >> >> you delete a frame via C-x 5 0 or C-x 5 1.
> >> >>
> >> >> martin
> >> >
> >> > In my test I followed the OP's recipe:
> >> >
> >> >> (7) Using the mouse, close the frame showing mouse.el, but do so
> in
> >> a state
> >> >> where still isearch overlays show up.
> >> >
> >> > I.e., I clicked on the 'X' (close frame button) in the frame's
> title
> >> > bar.
> >> 
> >> But when I close the frame with `C-x 5 0' instead and then proceed
> >> with
> >> the OP's recipe, the tool bar does not change and when I switch to
> the
> >> buffer where isearch had been invoked, the search is now abandoned,
> >> i.e., no isearch tool bar or lighter, no overlays.  So only closing
> >> the
> >> frame by clicking the close frame button with the mouse induces the
> >> surprising behavior.
> >> 
> >> Steve Berman
> >
> > Could someone please explain to me what is deemed to be the bug
> here?  Because
> > I'm confused wrt what is the part of the original description that
> seems to be
> > the problem.  In particular, the Isearch overlays are per-window,
> AFAIK.
> 
> 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?

Does it make sense to remain in Isearch in tbis scenario?  Could it be that we 
are over-engineering this stuff?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]