GNU bug report logs -
#41338
Toolbar-bug in Emacs 27.0.91/Pretest
Previous Next
Full log
View this message in rfc822 format
On May 17, 2020 4:37:12 PM GMT+03:00, Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Sun, 17 May 2020 16:12:38 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > On May 17, 2020 3:59:55 PM GMT+03:00, Stephen Berman
> <stephen.berman <at> 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.
This bug report was last modified 363 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.