bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer


From: Drew Adams
Subject: 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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]