From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Date: Wed, 4 Oct 2017 15:30:45 -0400 Message-ID: References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <20171003224017.GA51637@breton.holly.idiocy.org> <20171004163048.GA52414@breton.holly.idiocy.org> <20171004185900.GA52514@breton.holly.idiocy.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113fe9f0b52294055abda692" X-Trace: blaine.gmane.org 1507145534 28762 195.159.176.226 (4 Oct 2017 19:32:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 19:32:14 +0000 (UTC) Cc: 28620@debbugs.gnu.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 04 21:32:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpOp-0006dH-Nl for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 21:32:08 +0200 Original-Received: from localhost ([::1]:36580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpOx-000131-3Z for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Oct 2017 15:32:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpOo-00012k-Cu for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 15:32:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzpOl-0006fz-10 for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 15:32:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40533) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dzpOk-0006fM-UR for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 15:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dzpOj-0004M2-MX for bug-gnu-emacs@gnu.org; Wed, 04 Oct 2017 15:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Oct 2017 19:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28620-submit@debbugs.gnu.org id=B28620.150714548916689 (code B ref 28620); Wed, 04 Oct 2017 19:32:01 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 19:31:29 +0000 Original-Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpOC-0004L5-Fh for submit@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzpO9-0004Ks-FS for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dzpO0-00063K-Qh for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:20 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35590) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dzpO0-000639-N9 for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400 Original-Received: from mail-qk0-f170.google.com ([209.85.220.170]:54592) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dzpO0-00087K-Bc for 28620@debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400 Original-Received: by mail-qk0-f170.google.com with SMTP id n5so10352680qke.11 for <28620@debbugs.gnu.org>; Wed, 04 Oct 2017 12:31:16 -0700 (PDT) X-Gm-Message-State: AMCzsaXv24iQ7unVwRdFPdnRWQ3catkCcLsaW01lhEt6Er60ioHLD5Hz uCuWfa/9GiOQ7sNGXaWmmY9sFOjnfVxX0+jE/yo= X-Google-Smtp-Source: AOwi7QADgFz1KE0FvfuEbnD5dWPhA2xFSddfzqI96UiLFb+XB18X3V8bJuu0xynK2b5DlA8B+YpSqJN4jtDP4617ALI= X-Received: by 10.55.19.228 with SMTP id 97mr25344470qkt.271.1507145475759; Wed, 04 Oct 2017 12:31:15 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 12:30:45 -0700 (PDT) In-Reply-To: <20171004185900.GA52514@breton.holly.idiocy.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:137916 Archived-At: --001a113fe9f0b52294055abda692 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alan: Thanks for your thoughts on this. On Wed, Oct 4, 2017 at 2:59 PM, Alan Third wrote: > On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote: > > > =E2=80=8BSo how is it that Emacs processes a drag event when the mouse = button is > > released in the new frame if it never sees the mouseUp (drag release) > > event?=E2=80=8B If I drag across frames, on mouseUp, the key binding a= ssociated > > with mouseUp (mouse-1 as opposed to down-mouse-1 is run). > > The NSEvent is delivered to the EmacsView belonging to the frame where > the drag was initiated. I don=E2=80=99t think there=E2=80=99s anything we= can do to > change that. > =E2=80=8BSo you are saying that only one NSEvent is delivered to Emacs for = both the press and release of a drag that crosses frames? And that Emacs internally internally recognizes both the press and release of the mouse button and fires their respective key bindings but they both share the location from that one NSEvent? If so, why can't the nsterm.m mouseUp (release) handler synthesize an NSEvent based on the current mouse position that is run prior to invoking the keybinding for mouseUp? =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > The mouse wheel code is also handled in > =E2=80=8B=E2=80=8B > mouseDown, the difference is > =E2=80=8B=E2=80=8B > > > that macOS always sends the mouse whe > =E2=80=8B=E2=80=8B > el event to the emacs frame under > =E2=80=8B=E2=80=8B > > > the mouse pointer, whereas the mouse cli > =E2=80=8B=E2=80=8B > ck event is not sent when the > =E2=80=8B=E2=80=8B > > > frame is not already key (i.e. selected). > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B =E2=80=8BOk, I understand that now.=E2=80=8B =E2=80=8B=E2=80=8B=E2=80=8B > =E2=80=8B > > =E2=80=8BCan you show some sample code that would make macOS send the m= ouse drag > =E2=80=8B=E2=80=8B > > release event to the frame under the mouse pointer just as the scroll > wheel > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > c > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > d > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > d > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > e > =E2=80=8B=E2=80=8B > s > =E2=80=8B=E2=80=8B > . > =E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I don=E2=80=99t believe it=E2=80=99s possible. As I described before we= =E2=80=99d have to do > =E2=80=8B=E2=80=8B > something like: > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > [...] get a list of NSWindows, iterate over them to find out which > =E2=80=8B=E2=80=8B > one the mouse pointer is over, convert that NSWindow back to an Emacs > =E2=80=8B=E2=80=8B > frame, and [return it]. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > AFAICT Emacs does the right thing here, exactly the same thing as > =E2=80=8B=E2=80=8B > > > every other macOS app. > =E2=80=8B=E2=80=8B > > > > =E2=80=8B=E2=80=8B > > =E2=80=8BAs Eli noted, this does not happen under MS Windows. =E2=80=8BI just tested under MS Windows 7 with Emacs 25 and saw the same be= havior as on the Mac (mouse-1 drag between frames yields a release event with the depress frame rather than the release frame). I'll have to talk to Eli about this. =E2=80=8B > =E2=80=8B=E2=80=8B > I want to have > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > behavior that allows for drags across frames. The present code does no= t, > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > so whether it is consistent with Mac UI guidelines, it is not useful fo= r > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > that purpose. I would like your help in figuring out how to enable su > =E2=80=8B=E2=80=8B > ch > =E2=80=8B=E2=80=8B > > behavior as you seem to understand the macOS event flow well. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > But which behaviour? I can=E2=80=99t work out exactly what we=E2=80=99re = talking ab > =E2=80=8B=E2=80=8B > out > =E2=80=8B=E2=80=8B > here. Are you trying to get cross=E2=80=90frame dragging working =E2=80=8BYes.=E2=80=8B =E2=80=8B=E2=80=8B > or > =E2=80=8B=E2=80=8B > are you > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > genuinely concerned that Emacs doesn=E2=80=99t receive a click event when= the > =E2=80=8B=E2=80=8B > frame is selected using the mouse? These seem like two different > =E2=80=8B=E2=80=8B > things to me. > =E2=80=8BI want to work around that if possible. The fact that Emacs can d= ispatch on the mouseUp=E2=80=8B event tells me that we just need to determine the p= roper window of mouse position at that point and use that instead of the frame the Mac window system provides. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > There=E2=80=99s nothing fancy here, emacsframe is an instance variabl= e > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > associated with the EmacsView that macOS sends the mouse > =E2=80=8B=E2=80=8B > event to. > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8BSo show me how and where I could set that variable to the frame = of the > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > mouse position at the point of mouseUp=E2=80=8B and I will test it and le= t people > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > know if it works. > =E2=80=8B=E2=80=8B > > F > =E2=80=8B=E2=80=8B > ns_frame_list_z_order in nsfns.m does some of what=E2=80=99s described > a > =E2=80=8B=E2=80=8B > bove... But... > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > It looks like there=E2=80=99s maybe a neater way to get the current frame > =E2=80=8B=E2=80=8B > under the mouse... > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Lisp_Object frame =3D Qnil; > =E2=80=8B=E2=80=8B > NSWindow *w =3D [NSApp windowWithWindowNumber: > =E2=80=8B=E2=80=8B > [NSWindow windowNumberAtPoint:[NSEvent > mouseLocation] > =E2=80=8B=E2=80=8B > belowWindowWithWindowNumber:0]]; > =E2=80=8B=E2=80=8B > if (w !=3D nil) > =E2=80=8B=E2=80=8B > XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe); > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I=E2=80=99ve not tested this, so it may not work at all. Note that [NSEve= nt > =E2=80=8B=E2=80=8B > mouseLocation] returns an NSPoint indicating where the mouse is *right > =E2=80=8B=E2=80=8B > now*. It would probably be more sensible to use any co=E2=80=90ordinates > =E2=80=8B=E2=80=8B > provided by the event itself. > If the coordinates represent the location of the mouseUp event rather than mouseDown (of which I'm not sure), then why couldn't the frame differ as well when we have the right functionality together? Let me see if I can test with mouseLocation first. I would suggest that the (mouse-position) function should always return the uppermost Z-ordered frame at point, even though it fails to do that now. Bob --001a113fe9f0b52294055abda692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alan:

Thanks for your thoughts on this.

On Wed, Oct 4, 2017 at 2= :59 PM, Alan Third <alan@idiocy.org> wrote:
On Wed, Oct 04, 2017 at 01:26:18PM -0400, = Robert Weiner wrote:

> =E2=80=8BSo how is it that Emacs processes a drag event when the mouse= button is
> released in the new frame if it never sees the mouseUp (drag release)<= br> > event?=E2=80=8B=C2=A0 If I drag across frames, on mouseUp, the key bin= ding associated
> with mouseUp (mouse-1 as opposed to down-mouse-1 is run).

The NSEvent is delivered to the EmacsView belonging to the frame whe= re
the drag was initiated. I don=E2=80=99t think there=E2=80=99s anything we c= an do to
change that.

=E2=80=8BSo you are saying that onl= y one NSEvent is delivered to Emacs for both the press and release of a dra= g that crosses frames?
And that Emacs internally internally recognizes bot= h the press and release of the mouse button and fires their respective key = bindings but they both share the location from that one NSEvent?

If = so, why can't the nsterm.m mouseUp (release) handler synthesize an NSEv= ent based on the current mouse position that is run prior to invoking the k= eybinding for mouseUp?

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > The mouse wheel code is also h= andled in
=E2=80=8B=E2=80=8B
mouseDown, the difference is
=E2=80=8B=E2=80=8B
> > that macOS always sends the mo= use whe
=E2=80=8B=E2=80=8B
el event to the emacs frame under=
=E2=80=8B=E2=80=8B
> > the mouse pointer, whereas the= mouse cli
=E2=80=8B=E2=80=8B
ck event is not sent when the<= br>
=E2=80=8B=E2=80=8B
> > frame is not already key (i.e.= selected).
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=E2=80=8BOk, I un= derstand that now.=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B
=E2= =80=8B
> =E2=80=8BCan you show some sample code that would make mac= OS send the mouse drag
=E2=80=8B=E2=80=8B
> release event to the frame under th= e mouse pointer just as the scroll wheel
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
c
=E2=80=8B=E2=80=8B
o<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa= y:inline">=E2=80=8B=E2=80=8B
d
=E2=80=8B=E2=80=8B
e=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
d
=E2=80=8B=E2=80=8B
o
=E2=80=8B=E2=80=8B
e
=E2=80=8B=E2=80=8B
s
=E2=80=8B=E2=80=8B
.
= =E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I don=E2=80=99t believe it=E2=80= =99s possible. As I described before we=E2=80=99d have to do
=E2=80=8B=E2=80=8B
something like:
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 [...] get a list of NSWind= ows, iterate over them to find out which
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 one the m= ouse pointer is over, convert that NSWindow back to an Emacs
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 frame, and [return = it].
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > AFAICT Emacs does the right th= ing here, exactly the same thing as
=E2=80=8B=E2=80=8B
> > every other macOS app.
=E2=80=8B=E2=80=8B
> >
=E2=80=8B=E2=80=8B
> =E2=80=8BAs Eli noted, this does no= t happen under MS Windows.

=E2=80=8BI just te= sted under MS Windows 7 with Emacs 25 and saw the same behavior as on the M= ac (mouse-1 drag between frames yields a release event with the depress fra= me rather than the release frame).=C2=A0 I'll have to talk to Eli about= this.
=E2=80=8B
=E2=80=8B=E2=80=8B
=C2=A0 I want to have=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B

=E2=80=8B=E2=80=8B
> behavior that allows for drags acro= ss frames.=C2=A0 The present code does not,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> so whether it is consistent with Ma= c UI guidelines, it is not useful for
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> that purpose.=C2=A0 I would like yo= ur help in figuring out how to enable su
=E2=80=8B=E2=80=8Bch
=E2=80=8B=E2=80=8B
> behavior as you seem to understand = the macOS event flow well.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
But which behaviour? I can=E2=80= =99t work out exactly what we=E2=80=99re talking ab
=E2=80=8B=E2= =80=8B
out
=E2=80=8B=E2=80=8B
here. Are you trying to get cross=E2=80= =90frame dragging working

=E2=80=8BYes.=E2=80=8B
=E2= =80=8B=E2=80=8B
or
=E2=80=8B=E2=80=8B
are you
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
genuinely concerned that Emacs doesn=E2= =80=99t receive a click event when the
=E2=80=8B=E2=80=8B
frame is selected using the mouse? These= seem like two different
=E2=80=8B=E2=80=8B
things to me.

<= /div>
=E2=80=8BI want to work around that if possible.=C2=A0 The fact that Emacs= can dispatch on the mouseUp=E2=80=8B event tells me that we just need to d= etermine the proper window of mouse position at that point and use that ins= tead of the frame the Mac window system provides.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> > There=E2=80=99s nothing fancy = here, emacsframe is an instance variable
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
> > associated with the EmacsView = that macOS sends the mouse
=E2=80=8B=E2=80=8B
event to.
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B =E2=80=8BSo show me how and where I could set that variable to the frame = of the
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B mouse position at the point of mouseUp=E2=80=8B and I will test it and le= t people
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B know if it works.
=E2=80=8B=E2=80=8B

F
=E2=80=8B=E2=80=8B
ns_frame_list_z_order in nsfns.m= does some of what=E2=80=99s described
a
=E2=80=8B=E2=80=8B
bove... But...
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
It looks like there=E2=80=99s maybe a ne= ater way to get the current frame
=E2=80=8B=E2=80=8B
under the mouse...
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil= ;
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 NSWindow *w =3D [NSApp win= dowWithWindowNumber:
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[NSWindow windowNumberA= tPoint:[NSEvent mouseLocation]
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0belowWindowWithW= indowNumber:0]];
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 if (w !=3D nil)
=E2=80=8B=E2=80=8B
=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, (= (EmacsView *)[w delegate])->emacsframe);
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I=E2=80=99ve not tested this, so it may = not work at all. Note that [NSEvent
=E2=80=8B=E2=80=8B
mouseLocation] returns an NSPoint indica= ting where the mouse is *right
=E2=80=8B=E2=80=8B
now*. It would probably be more sensible= to use any co=E2=80=90ordinates
=E2=80=8B=E2=80=8B
provided by the event itself.

If the coordinates represent the location of the mouseUp e= vent rather than mouseDown (of which I'm not sure), then why couldn'= ;t the frame differ as well when we have the right functionality together?= =C2=A0 Let me see if I can test with mouseLocation first.

I would = suggest that the (mouse-position) function should always return the uppermo= st Z-ordered frame at point, even though it fails to do that now.

Bo= b
--001a113fe9f0b52294055abda692--