* 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).