* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame @ 2011-11-13 17:34 Drew Adams 2011-11-14 22:54 ` Drew Adams 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2011-11-13 17:34 UTC (permalink / raw) To: 10037 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"' ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame 2011-11-13 17:34 bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame Drew Adams @ 2011-11-14 22:54 ` Drew Adams 2011-12-06 22:54 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2011-11-14 22:54 UTC (permalink / raw) To: 10037 > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame 2011-11-14 22:54 ` Drew Adams @ 2011-12-06 22:54 ` Stefan Monnier 2011-12-07 0:25 ` Drew Adams 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2011-12-06 22:54 UTC (permalink / raw) To: Drew Adams; +Cc: 10037 > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame 2011-12-06 22:54 ` Stefan Monnier @ 2011-12-07 0:25 ` Drew Adams 2011-12-07 1:15 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: Drew Adams @ 2011-12-07 0:25 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 10037 > > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame 2011-12-07 0:25 ` Drew Adams @ 2011-12-07 1:15 ` Stefan Monnier 2011-12-07 2:50 ` Drew Adams 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2011-12-07 1:15 UTC (permalink / raw) To: Drew Adams; +Cc: 10037 > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame 2011-12-07 1:15 ` Stefan Monnier @ 2011-12-07 2:50 ` Drew Adams 0 siblings, 0 replies; 6+ messages in thread From: Drew Adams @ 2011-12-07 2:50 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 10037 > > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-07 2:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-13 17:34 bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame Drew Adams 2011-11-14 22:54 ` Drew Adams 2011-12-06 22:54 ` Stefan Monnier 2011-12-07 0:25 ` Drew Adams 2011-12-07 1:15 ` Stefan Monnier 2011-12-07 2:50 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).