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

Previous Next

To reply to this bug, email your comments to 10037 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Date: Sun, 13 Nov 2011 09:34:00 -0800

Download these two libraries, which do little more than make Emacs use a
standalone minibuffer frame:
http://www.emacswiki.org/emacs/download/hexrgb.el
http://www.emacswiki.org/emacs/download/oneonone.el
 
runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f
"1on1-emacs"
 
Now try to use `isearch-mouse-2':
 
1. Visit a file - e.g. hexrgb.el.
 
2. Select some text with the mouse - e.g. `for'.
 
3. Hit `C-s'.
 
4. Move the mouse to the echo area and click mouse-2.
 
The selected text should be inserted into the search string.  Instead,
Isearch is exited.  A guess would be that this is because of a
switch-frame event.
 
In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-07 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -I"D:/devel/emacs/libs/libXpm-3.5.8/include"
 -I"D:/devel/emacs/libs/libXpm-3.5.8/src"
 -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
 -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include"
 -I"D:/devel/emacs/libs/giflib-4.1.4-1/include"
 -I"D:/devel/emacs/libs/jpeg-6b-4/include"
 -I"D:/devel/emacs/libs/tiff-3.8.2-1/include"
 -I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags
 -L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'
 

Message #8 received at 10037 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <10037 <at> debbugs.gnu.org>
Subject: RE: bug#10037: 24.0.91;
	`isearch-mouse-2' no good with standalone minibuffer frame
Date: Mon, 14 Nov 2011 14:54:29 -0800

> The selected text should be inserted into the search string.  Instead,
> Isearch is exited.  A guess would be that this is because of a
> switch-frame event.

A little debugging showed that this is indeed the case.
The `isearch-mouse-2' code does this:

(defun isearch-mouse-2 (click)
  "..."
  (interactive "e")
  (let* ((w (posn-window (event-start click)))
         (overriding-terminal-local-map nil)
         (binding (key-binding (this-command-keys-vector) t)))
    (if (and (window-minibuffer-p w)
             (not (minibuffer-window-active-p w)))
      (isearch-yank-x-selection)
      (when (functionp binding)
        (call-interactively binding)))))

When you click mouse-2 in a standalone minibuffer, `this-command-keys-vector'
corresponds to a switch-frame event.  `switch-frame' is bound to nil in
`isearch-mode-map', so `key-binding' returns nil.

What I do not understand is why handling the `switch-frame' event in the normal
way would exit Isearch.  But that is what I see on Windows, even with `emacs
-Q': Isearch exits.

These comments in the isearch.el code suggest that `switch-frame'
(intentionally) does NOT exit Isearch:

;; Pass frame events transparently so they won't exit the search.
;; In particular, if we have more than one display open, then a
;; switch-frame might be generated by someone typing at another keyboard.

But Isearch does exit - at least that is what I see on Windows.  Is this a bug,
perhaps a Windows-specific bug?  Do `switch-frame' events on Linux also cause
Isearch to exit, in contradiction to the Isearch code comment above?

In my case, I bind `down-mouse-2' globally to a command,
`mouse-flash-position-or-M-x'.  During Isearch I do not want this command to be
invoked when I click `mouse-2' in the minibuffer.  So I bind `down-mouse-2' in
Isearch to `ignore' instead of nil, to prevent such invocation.  That works,
when there is no standalone minibuffer frame (so no `switch-frame' event).

But because I usually have a standalone minibuffer frame, that is not a complete
solution.  The `switch-frame' event occurs (just) before the `down-mouse-2', so
Isearch mode has already been exited when `down-mouse-2' is clicked in the
standalone minibuffer frame.  Neither the `down-mouse-2' Isearch binding nor the
`mouse-2' Isearch binding is invoked, because Isearch is finished.  The
`down-mouse-2' event invokes the globally bound command instead,
`mouse-flash-position-or-M-x'.

So to fix that I now do the same thing for `switch-frame' as for `down-mouse-2':
bind it to `ignore' instead of nil.  That works OK.  Clicking `mouse-2' in any
frame then does not exit Isearch.  (And yet, the frame seems to be switched to.)

This seems like a workaround, however.  According to the nil binding and the
Isearch code comments for it, it seems like a `switch-frame' event should NOT
exit Isearch.  Please let me know whether you think this is a bug and could be
fixed.  (In that case I would bind `switch-frame' to `ignore' only for older
Emacs releases.)

The Isearch code currently has several `isearch-mode-map' bindings of nil:

(define-key map [switch-frame] nil)
(define-key map [delete-frame] nil)
(define-key map [iconify-frame] nil)
(define-key map [make-frame-visible] nil)
(define-key map [mouse-movement] nil)
(define-key map [language-change] nil)
(define-key map [down-mouse-2] nil)

Dunno what a better default binding might be for some of them, but AFAICT for my
setup of a standalone minibuffer, binding `switch-frame' and `down-mouse-2' to
`ignore' takes care of the problems I encountered.

Message #11 received at 10037 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10037 <at> debbugs.gnu.org
Subject: Re: bug#10037: 24.0.91;
	`isearch-mouse-2' no good with standalone minibuffer frame
Date: Tue, 06 Dec 2011 17:54:38 -0500

> 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.
Often switch-frame end up selecting another buffer, so making Isearch
behave "properly" in this case without actually exiting is
a bit tricky.


        Stefan

Message #14 received at 10037 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 10037 <at> debbugs.gnu.org
Subject: RE: 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.

Message #17 received at 10037 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10037 <at> debbugs.gnu.org
Subject: Re: bug#10037: 24.0.91;
	`isearch-mouse-2' no good with standalone minibuffer frame
Date: Tue, 06 Dec 2011 20:15:40 -0500

> 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?

Because subsequent operations would take place in the wrong context.
The switch-frame occurs *before* and not *together with* the mouse-2
event (or at least, Emacs may very well process the switch-frame event
before receiving the mouse-2 event: it's clearly the case for me where
I use focus-follows-mouse so the switch-frame event happens as soon as
I move the mouse over the other frame, but it can also be the case in
the click-to-focus case depending on timing).

I.e. to fix this issue, we need to postpone (some part of) the
processing of switch-frame events.  E.g. Isearch could handle
switch-frame by putting itself in an "about to exit" state, but making
it work right is likely to be pretty tricky since the time where we
actually do exit would likely be something like pre-command-hook at
which point the key sequence has already been looked up in the active
keymaps which is wrong since which keymaps are active depends on whether
we should have exited Isearch or not.


        Stefan

Message #20 received at 10037 <at> debbugs.gnu.org (full text, mbox):

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

> > 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?
> 
> Because subsequent operations would take place in the wrong context.
> ... I.e. to fix this issue, we need to postpone (some part of) the
> processing of switch-frame events....

I'll take your word for it.

Previous Next

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