GNU logs - #10037, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 13 Nov 2011 17:35:02 +0000
Resent-Message-ID: <handler.10037.B.132120568921219 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 10037 <at> debbugs.gnu.org
From: "Drew Adams" <drew.adams@HIDDEN>
Date: Sun, 13 Nov 2011 09:34:00 -0800
Message-ID: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcyiKm441PP4TdOATICNgOdFqvmb9A==
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

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 sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Drew Adams" <drew.adams@HIDDEN>
Subject: bug#10037: Acknowledgement (24.0.91; `isearch-mouse-2' no good
 with standalone minibuffer frame)
Message-ID: <handler.10037.B.132120568921219.ack <at> debbugs.gnu.org>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
X-Gnu-PR-Message: ack 10037
X-Gnu-PR-Package: emacs
Reply-To: 10037 <at> debbugs.gnu.org
Date: Sun, 13 Nov 2011 17:35:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 10037 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
10037: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D10037
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 14 Nov 2011 22:56:01 +0000
Resent-Message-ID: <handler.10037.B10037.132131131930796 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: <10037 <at> debbugs.gnu.org>
From: "Drew Adams" <drew.adams@HIDDEN>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
Date: Mon, 14 Nov 2011 14:54:29 -0800
Message-ID: <811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
Thread-Index: AcyiKm441PP4TdOATICNgOdFqvmb9AA0ytyQ
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

> 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 sent to bug-gnu-emacs@HIDDEN:

Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 06 Dec 2011 22:56:02 +0000
Resent-Message-ID: <handler.10037.B10037.132321212420584 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Drew Adams" <drew.adams@HIDDEN>
Cc: 10037 <at> debbugs.gnu.org
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvwra9b9eb.fsf-monnier+emacs@HIDDEN>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
	<811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN>
Date: Tue, 06 Dec 2011 17:54:38 -0500
In-Reply-To: <811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN> (Drew Adams's
	message of "Mon, 14 Nov 2011 14:54:29 -0800")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org

> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Dec 2011 00:27:01 +0000
Resent-Message-ID: <handler.10037.B10037.132321756928583 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 10037
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "'Stefan Monnier'" <monnier@HIDDEN>
Cc: 10037 <at> debbugs.gnu.org
Received: via spool by 10037-submit <at> debbugs.gnu.org id=B10037.132321756928583
          (code B ref 10037); Wed, 07 Dec 2011 00:27:01 +0000
Received: (at 10037) by debbugs.gnu.org; 7 Dec 2011 00:26:09 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1RY5Kr-0007Qy-79
	for submit <at> debbugs.gnu.org; Tue, 06 Dec 2011 19:26:09 -0500
Received: from rcsinet15.oracle.com ([148.87.113.117])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <drew.adams@HIDDEN>) id 1RY5Kp-0007Qq-M2
	for 10037 <at> debbugs.gnu.org; Tue, 06 Dec 2011 19:26:08 -0500
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB70POvE024103
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 00:25:25 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB70POkQ013770
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 00:25:24 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB70PIYG019113; Tue, 6 Dec 2011 18:25:18 -0600
Received: from dradamslap1 (/10.159.45.61)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 16:25:18 -0800
From: "Drew Adams" <drew.adams@HIDDEN>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN><811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN>
	<jwvwra9b9eb.fsf-monnier+emacs@HIDDEN>
Date: Tue, 6 Dec 2011 16:25:14 -0800
Message-ID: <308914D4D17149D99C5B8361D477ED04@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <jwvwra9b9eb.fsf-monnier+emacs@HIDDEN>
Thread-Index: Acy0ag8dfn4FXvyaQo+7fJyZ4IBNEwACrsQg
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4EDEB275.008E,ss=1,re=0.000,fgs=0
X-Spam-Score: -6.2 (------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.2 (------)

> > 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Dec 2011 01:17:01 +0000
Resent-Message-ID: <handler.10037.B10037.1323220587480 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 10037
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "Drew Adams" <drew.adams@HIDDEN>
Cc: 10037 <at> debbugs.gnu.org
Received: via spool by 10037-submit <at> debbugs.gnu.org id=B10037.1323220587480
          (code B ref 10037); Wed, 07 Dec 2011 01:17:01 +0000
Received: (at 10037) by debbugs.gnu.org; 7 Dec 2011 01:16:27 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1RY67W-00007g-18
	for submit <at> debbugs.gnu.org; Tue, 06 Dec 2011 20:16:26 -0500
Received: from pruche.dit.umontreal.ca ([132.204.246.22])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <monnier@HIDDEN>) id 1RY67T-00007Y-Jx
	for 10037 <at> debbugs.gnu.org; Tue, 06 Dec 2011 20:16:24 -0500
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
	by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id pB71Ff7l013670;
	Tue, 6 Dec 2011 20:15:41 -0500
Received: by pastel.home (Postfix, from userid 20848)
	id 65087593FF; Tue,  6 Dec 2011 20:15:40 -0500 (EST)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvborlyyts.fsf-monnier+emacs@HIDDEN>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN>
	<811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN>
	<jwvwra9b9eb.fsf-monnier+emacs@HIDDEN>
	<308914D4D17149D99C5B8361D477ED04@HIDDEN>
Date: Tue, 06 Dec 2011 20:15:40 -0500
In-Reply-To: <308914D4D17149D99C5B8361D477ED04@HIDDEN> (Drew Adams's
	message of "Tue, 6 Dec 2011 16:25:14 -0800")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4063=0
X-NAI-Spam-Version: 2.2.0.9309 : core <4063> : streams <708434> : uri <1023074>
X-Spam-Score: -4.6 (----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -4.6 (----)

> 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 sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#10037: 24.0.91; `isearch-mouse-2' no good with standalone minibuffer frame
Resent-From: "Drew Adams" <drew.adams@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 07 Dec 2011 02:51:01 +0000
Resent-Message-ID: <handler.10037.B10037.13232262608712 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 10037
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "'Stefan Monnier'" <monnier@HIDDEN>
Cc: 10037 <at> debbugs.gnu.org
Received: via spool by 10037-submit <at> debbugs.gnu.org id=B10037.13232262608712
          (code B ref 10037); Wed, 07 Dec 2011 02:51:01 +0000
Received: (at 10037) by debbugs.gnu.org; 7 Dec 2011 02:51:00 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1RY7b2-0002GS-1f
	for submit <at> debbugs.gnu.org; Tue, 06 Dec 2011 21:51:00 -0500
Received: from acsinet15.oracle.com ([141.146.126.227])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <drew.adams@HIDDEN>) id 1RY7b0-0002GK-0k
	for 10037 <at> debbugs.gnu.org; Tue, 06 Dec 2011 21:50:58 -0500
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	pB72oEkM021157
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 7 Dec 2011 02:50:15 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	pB72oDoZ001359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 7 Dec 2011 02:50:14 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	pB72o802026983; Tue, 6 Dec 2011 20:50:08 -0600
Received: from dradamslap1 (/10.159.45.61)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 06 Dec 2011 18:50:07 -0800
From: "Drew Adams" <drew.adams@HIDDEN>
References: <01C1F1EEC9F042E8B9E91B12BD34EE33@HIDDEN><811EE3EE511B43748AEF1A9E8CFE5654@HIDDEN><jwvwra9b9eb.fsf-monnier+emacs@HIDDEN><308914D4D17149D99C5B8361D477ED04@HIDDEN>
	<jwvborlyyts.fsf-monnier+emacs@HIDDEN>
Date: Tue, 6 Dec 2011 18:50:03 -0800
Message-ID: <532CB3F1A98D46BF911DB1EB8D132941@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <jwvborlyyts.fsf-monnier+emacs@HIDDEN>
Thread-Index: Acy0fcN0o2mtip3UQASFhujYz6/A3gADO5jQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4EDED468.0033,ss=1,re=0.000,fgs=0
X-Spam-Score: -6.2 (------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -6.2 (------)

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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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