From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame Date: Mon, 14 Nov 2011 14:54:29 -0800 Message-ID: <811EE3EE511B43748AEF1A9E8CFE5654@us.oracle.com> References: <01C1F1EEC9F042E8B9E91B12BD34EE33@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1321311336 9215 80.91.229.12 (14 Nov 2011 22:55:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 14 Nov 2011 22:55:36 +0000 (UTC) To: <10037@debbugs.gnu.org> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 14 23:55:32 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RQ5R5-0004aD-Ox for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2011 23:55:32 +0100 Original-Received: from localhost ([::1]:41728 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ5R5-0003i1-2F for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Nov 2011 17:55:31 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:42487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ5R1-0003gt-Kv for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2011 17:55:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQ5R0-0000au-Em for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2011 17:55:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQ5R0-0000ao-Bs for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2011 17:55:26 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RQ5RZ-00081b-QJ for bug-gnu-emacs@gnu.org; Mon, 14 Nov 2011 17:56:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Nov 2011 22:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10037 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10037-submit@debbugs.gnu.org id=B10037.132131131930796 (code B ref 10037); Mon, 14 Nov 2011 22:56:01 +0000 Original-Received: (at 10037) by debbugs.gnu.org; 14 Nov 2011 22:55:19 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQ5Qs-00080f-OB for submit@debbugs.gnu.org; Mon, 14 Nov 2011 17:55:18 -0500 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RQ5Qp-00080S-HP for 10037@debbugs.gnu.org; Mon, 14 Nov 2011 17:55:16 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pAEMsXis019909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <10037@debbugs.gnu.org>; Mon, 14 Nov 2011 22:54:33 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pAEMsW1r009247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <10037@debbugs.gnu.org>; Mon, 14 Nov 2011 22:54:32 GMT Original-Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pAEMsQTP000649 for <10037@debbugs.gnu.org>; Mon, 14 Nov 2011 16:54:26 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Nov 2011 14:54:26 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <01C1F1EEC9F042E8B9E91B12BD34EE33@us.oracle.com> Thread-Index: AcyiKm441PP4TdOATICNgOdFqvmb9AA0ytyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090203.4EC19C2A.000F,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 14 Nov 2011 17:56:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:53915 Archived-At: > 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.