GNU bug report logs -
#41338
Toolbar-bug in Emacs 27.0.91/Pretest
Previous Next
Full log
Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sun, 17 May 2020 17:22:14 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> On May 17, 2020 4:37:12 PM GMT+03:00, Stephen Berman <stephen.berman <at> gmx.net> wrote:
>> > 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.
> Yes, I was asking whether wr should simply not try remaining in
> Isearch when frames are switched or deleted.
I think it would certainly be good if isearch behaved the same in
response to a delete frame event, regardless of how it is generated.
> Juri seems to say that
> we try not to leave Isearch in some of those cases.
I found Juri's post confusing, probably because I know next to nothing
about frame events. He quotes this comment in isearch-mode-map:
;; Pass frame events transparently so they won't exit the search.
but then says "and indeed the ‘switch-frame’ event is fired when the
frame is switched during isearch, and it exits isearch", which seems to
contradict the comment. But in any case, according to my tests, switch
the frame does indeed exit Isearch, whether via `C-x 5 o' or the
toolkits `Alt-TAB'. Juri added: "But I don't know why the
‘delete-frame’ event is not fired on frame deletion." But my tests
indicate that, unlike when switching the frame, when deleting the frame,
Isearch is exited only when the delete frame event comes from Emacs, not
from the toolkit.
Steve Berman
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.