GNU bug report logs - #10037
24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10037 <at> debbugs.gnu.org
Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Date: Tue, 6 Dec 2011 16:25:14 -0800

> > What I do not understand is why handling the `switch-frame' event in
> > the normal way would exit Isearch.
> 
> AFAIK isearch has always exited upon switch-frame, yes.

Dontcha think that's likely because mouse events, and a standalone minibuffer
frame, were not foreseen during search?  In a keyboard-only scenario and no
minibuffer frame, a frame switch would pretty naturally indicate a logical end
to search in the current buffer (likely anyway).

That's not the use case I have.  There are lots of things in Emacs that do not
foresee/expect/plan for multiple frames and a standalone minibuffer.  This just
seems like another one.

> Often switch-frame end up selecting another buffer, 

"Another buffer" could well be the minibuffer: isearch already involves two
buffers and two windows, independently of frame switching.

> so making Isearch behave "properly" in this case without
> actually exiting is a bit tricky.

I don't have any reason to doubt you that it might be tricky, for some meaning
of "behave properly".  I don't have any insight wrt the code here.

On the other hand, the switch-frame event is very likely to be because of the
mouse movement in this case, and the frame switched to is likely to be the frame
where the mouse is clicked.

IOW, why wouldn't it just "work", in practice, at least most of the time, if
`switch-frame' were not coded to exit isearch?  Just why is that exiting needed?

It can always be the case that you click mouse-2 in a window other than what you
really intended.  Why is this so different?  Why should crossing a frame
boundary be handled so very differently (in this case) from crossing a window
boundary?  If the concern is which buffer ends up the target, and whether it was
the intended target, it seems like that problem should be the same in both cases
(window/frame).

Just food for thought, I guess.  I don't see the logical obstacle.  I do imagine
designers possibly not thinking about the use of a standalone minibuffer.  And I
wonder if that might not be the only reason behind this behavior.

Previous Next

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