GNU bug report logs - #41338
Toolbar-bug in Emacs 27.0.91/Pretest

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 41338 <at> debbugs.gnu.org, juri <at> linkov.net, konrad.podczeck <at> univie.ac.at
Subject: bug#41338: Toolbar-bug in Emacs 27.0.91/Pretest
Date: Sun, 17 May 2020 15:37:12 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.