GNU bug report logs - #28620
Mouse drag event records wrong window for release when crossing frames

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: rswgnu@HIDDEN; dated Wed, 27 Sep 2017 15:45:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 19 Oct 2017 18:33:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 19 14:33:13 2017
Received: from localhost ([127.0.0.1]:50701 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e5Fd2-0002MW-TA
	for submit <at> debbugs.gnu.org; Thu, 19 Oct 2017 14:33:13 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53074)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e5Fd1-0002MG-BF
 for 28620 <at> debbugs.gnu.org; Thu, 19 Oct 2017 14:33:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e5Fcs-0002GG-TP
 for 28620 <at> debbugs.gnu.org; Thu, 19 Oct 2017 14:33:06 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38744)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e5Fcs-0002Fs-Pf
 for 28620 <at> debbugs.gnu.org; Thu, 19 Oct 2017 14:33:02 -0400
Received: from mail-qt0-f176.google.com ([209.85.216.176]:44243)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e5Fcs-0002UU-FI
 for 28620 <at> debbugs.gnu.org; Thu, 19 Oct 2017 14:33:02 -0400
Received: by mail-qt0-f176.google.com with SMTP id 8so15647139qtv.1
 for <28620 <at> debbugs.gnu.org>; Thu, 19 Oct 2017 11:33:02 -0700 (PDT)
X-Gm-Message-State: AMCzsaWxf+ucioBe5ZzSoT9oiyRewKjP6MdjCotnabt0ft6lFPhp5yk5
 LKAEEIBszGjXg5O5aeQbP1Rtga2ozRUHW01/7wc=
X-Google-Smtp-Source: ABhQp+ThO37hFVVtRizJTSQPyzRquFVXxM8KKP+9zzm+wbB6Pf+Praf8PoiYE5vwwhroouoZnWWmGmBl8osn2Bt0gkU=
X-Received: by 10.200.56.52 with SMTP id q49mr3496696qtb.309.1508437981940;
 Thu, 19 Oct 2017 11:33:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.12.74 with HTTP; Thu, 19 Oct 2017 11:32:31 -0700 (PDT)
In-Reply-To: <59E5C5FE.2050807@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
 <59E32CFA.5080405@HIDDEN>
 <CA+OMD9gm_LDZhcHu6QYuv-NepiWBvqeTTB5eJADjUVS5G1xSFQ@HIDDEN>
 <59E5C5FE.2050807@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Thu, 19 Oct 2017 14:32:31 -0400
X-Gmail-Original-Message-ID: <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
Message-ID: <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a113e205214511b055bea96f5"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a113e205214511b055bea96f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 17, 2017 at 4:57 AM, martin rudalics <rudalics@HIDDEN> wrote:

> > =E2=80=8BYes, you would need to follow a common drag-and-drop protocol.
> > I don't understand why that is an issue if that is what you want
> > to do.
>
> Wasn't that something _you_ wanted to do?  If not then we can obviously
> ignore it.


=E2=80=8BYes, I would like Emacs drag-and-drop to work across Emacs frames =
and
potentially even across other applications using whatever protocol is
common to the platform in use.


>
> >> At least for top-level windows.  This will work as long a child window=
s
> >> =E2=80=8Bare fully contained by their parents which IIUC is not necess=
arily true
> >> =E2=80=8B
> =E2=80=8Bf=E2=80=8B
> or macOS systems.
> >
> > =E2=80=8BCould you give a concrete example of where this might be a pro=
blem
> > so I could test code against it?
>
> Hardly.  Child windows are a separate problem because, for example, on X
> you currently cannot drop files on them - the drop goes to the parent
> window instead.


=E2=80=8BWe would certainly live within the constraints of the drag-and-dro=
p
protocol.
=E2=80=8B

>
>
> >>> and (2) a function would be needed to get the attributes of
> >>   those windows.
> >
> > =E2=80=8BI have figured that part out from the macOS APIs.
>
> Window attributes are a problem on X.  You will learn about that as soon
> as you try to adapt your code for it.


=E2=80=8BOk.  It would be more helpful if you explained which problems you =
feel are
relevant to the discussion at hand.
=E2=80=8B
Bob

--001a113e205214511b055bea96f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Tue, Oct 17, 2=
017 at 4:57 AM, martin rudalics </span><span dir=3D"ltr" style=3D"font-fami=
ly:arial,sans-serif">&lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blan=
k">rudalics@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-seri=
f"> wrote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; =E2=80=8BYes, yo=
u would need to follow a common drag-and-drop protocol.<br>
&gt; I don&#39;t understand why that is an issue if that is what you want<b=
r>
&gt; to do.<br>
<br></span>
Wasn&#39;t that something _you_ wanted to do?=C2=A0 If not then we can obvi=
ously<br>
ignore it.</blockquote><div><br></div><div class=3D"gmail_default" style=3D=
"font-family:monospace,monospace">=E2=80=8BYes, I would like Emacs drag-and=
-drop to work across Emacs frames and potentially even across other applica=
tions using whatever protocol is common to the platform in use.</div><div c=
lass=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""><br>
<br>
&gt;&gt; At least for top-level windows.=C2=A0 This will work as long a chi=
ld windows<br>
&gt;&gt; =E2=80=8Bare fully contained by their parents which IIUC is not ne=
cessarily true<br>
&gt;&gt; =E2=80=8B<div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace;display:inline">=E2=80=8Bf=E2=80=8B</div>or macOS systems.<br>
&gt;<br>
&gt; =E2=80=8BCould you give a concrete example of where this might be a pr=
oblem<br>
&gt; so I could test code against it?<br>
<br></span>
Hardly.=C2=A0 Child windows are a separate problem because, for example, on=
 X<br>
you currently cannot drop files on them - the drop goes to the parent<br>
window instead.</blockquote><div><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace">=E2=80=8BWe would certainly live wit=
hin the constraints of the drag-and-drop protocol.</div><div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace">=E2=80=8B</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><span class=3D""><br>
<br>
&gt;&gt;&gt; and (2) a function would be needed to get the attributes of<br=
>
&gt;&gt;=C2=A0 =C2=A0those windows.<br>
&gt;<br>
&gt; =E2=80=8BI have figured that part out from the macOS APIs.<br>
<br></span>
Window attributes are a problem on X.=C2=A0 You will learn about that as so=
on<br>
as you try to adapt your code for it.</blockquote><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BOk.=
=C2=A0 It would be more helpful if you explained which problems you feel ar=
e relevant to the discussion at hand.</div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace">=E2=80=8B</div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">Bob</div><div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace"><br></div></div></di=
v></div>

--001a113e205214511b055bea96f5--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 17 Oct 2017 08:58:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 17 04:58:02 2017
Received: from localhost ([127.0.0.1]:44857 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e4NhK-0001ZR-2F
	for submit <at> debbugs.gnu.org; Tue, 17 Oct 2017 04:58:02 -0400
Received: from mout.gmx.net ([212.227.15.19]:61545)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e4NhI-0001Z6-QR
 for 28620 <at> debbugs.gnu.org; Tue, 17 Oct 2017 04:58:01 -0400
Received: from [192.168.1.100] ([46.125.249.51]) by mail.gmx.com (mrgmx001
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MaaOf-1doeGF0yt7-00K6m7; Tue, 17
 Oct 2017 10:57:42 +0200
Message-ID: <59E5C5FE.2050807@HIDDEN>
Date: Tue, 17 Oct 2017 10:57:34 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: rswgnu@HIDDEN
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
 <59E32CFA.5080405@HIDDEN>
 <CA+OMD9gm_LDZhcHu6QYuv-NepiWBvqeTTB5eJADjUVS5G1xSFQ@HIDDEN>
In-Reply-To: <CA+OMD9gm_LDZhcHu6QYuv-NepiWBvqeTTB5eJADjUVS5G1xSFQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:dHgLt+mCWuLYrhLPcHqnJpINbKVZX6QU9MwV/kWfhrl6px+J8qE
 HlpyO+Wf/Rf5Mg8J2fi4ypHsXM4osGX5qTTAeMTMLT5hoU299LPwJVMQEblpsxv6FX/5Nmg
 PjEkfGtu1TOGTzQutn8GvAPdUAELyDD3yrb8MYzyEElQXgzRdLD8ZkgRfmQ4gccjwuZUeuD
 oSGRfOy6Uts+UMyArM5UA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ub9g463CYjI=:ZkWOkKxGcluckb4EIvyajB
 YZiBLfHMogKpIhZ5mGUfU4YDib9s90m2mO33DoCFFE8T/MANQ9MoTo2D4xzdoQM7mBBKBS45Y
 9065vCPpUXwiBJ77W/w3IFc9AcN7wXkqVWhLPj164nnyl1IdGBguqRJU8EsC4myEffr4SRSUe
 j49sxtK37WtEzuoCmCR0QjgmpFbObzhEsbM0Y1rekcPRZMttkJYzXT/CrmoKg++btPht9teb/
 TN/IMHCNlWqwlXFMYBoElCNFH1frTe1OzHKqTiKxX/EAqF4Rffi0xjlkpyGz2g7B7I8hBMnsV
 5Ljj201axWMfoz3bgIqyNvT+Ipg8V2+xkVdCPq8lzOI94MiTR2VUiIIwF0JN1BVxqG0T8BBPu
 B/Yoczkj9nNTUnTqnqdDXhK168HimkOoL8IRtrHWVH2mzhYTKKVLAJ47R0e3SRQgwojGAoznH
 oxJes3v4miUzzCKh7+Wjg0dk8wHAW9MgJCAx7GxwtqX0EMG76BtJmD4A3P0oqOVMzktOGfMgn
 PgZwnR/URdi9XDz7Jt7QE4hmma1bSCnDIGKYlHubIIyqOMn4MED8Sv+zWVbbb2acVIIfllj69
 d9PCKLCUPRmaHB2JLaJfx3Lrik4nzi72jbk9lRzINuBL60b6V2ZQRc9tjNmarFRud666N+w/W
 QbcVzoIQE3wwn5fLTD/FEz+Wy0tvepTcHr2d7w5lt4j1HoUd+jR8DEvdJlKYGhvfZu1iyh3eC
 UUl4rns/MYK7XypOvISYvFDprnVWAKFVO1xCCBjQewHTVyLs76IY9EaFmUTxyBjIDQ4C+c+CX
 1BlLFrxLqPyqbewhevzqbD7kB+zidfzxv+hH1eVPa3/BwEX0GfDiG9T1+4uaEOsQqHlTRnO
X-Spam-Score: -0.8 (/)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

 > =E2=80=8BYes, you would need to follow a common drag-and-drop protocol=
=2E
 > I don't understand why that is an issue if that is what you want
 > to do.

Wasn't that something _you_ wanted to do?  If not then we can obviously
ignore it.

 > For programmatic purposes when Emacs receives a mouse button
 > drag release event, we only care about whether the topmost
 > window-system window at the point of release is an Emacs frame
 > or not.  If at that point, it is occluded by another window,
 > we don't care how transparent that window is and whether the
 > Emacs frame can be "seen" but only whether it is logically
 > the window clicked upon.  Again, even if it is not, we can
 > process the event as if it were *if we so choose* but having
 > the choice is the key issue here.

So I warned here about possible problems with "visibility" once and will
drop this issue.

 >> At least for top-level windows.  This will work as long a child windo=
ws
 >> =E2=80=8B=E2=80=8B
 >> are fully contained by their parents which IIUC is not necessarily tr=
ue
 >> =E2=80=8B=E2=80=8B
 >> for macOS systems.
 >
 >
 > =E2=80=8BCould you give a concrete example of where this might be a pr=
oblem
 > so I could test code against it?

Hardly.  Child windows are a separate problem because, for example, on X
you currently cannot drop files on them - the drop goes to the parent
window instead.

 >>> and (2) a function would be needed to get the attributes of
 >> =E2=80=8B
 >> =E2=80=8B=E2=80=8B
 >>   those windows.
 >> =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=8BI have figured that part out from the macOS APIs.

Window attributes are a problem on X.  You will learn about that as soon
as you try to adapt your code for it.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 16:31:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 16 12:31:47 2017
Received: from localhost ([127.0.0.1]:44099 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e48It-0003Yp-9Q
	for submit <at> debbugs.gnu.org; Mon, 16 Oct 2017 12:31:47 -0400
Received: from eggs.gnu.org ([208.118.235.92]:46161)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e48Is-0003Yd-9g
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 12:31:46 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e48Ij-0004Er-Vl
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 12:31:41 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57653)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e48Ij-0004Eg-Rl
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 12:31:37 -0400
Received: from mail-qt0-f169.google.com ([209.85.216.169]:43851)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e48Ij-0005Gx-EF
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 12:31:37 -0400
Received: by mail-qt0-f169.google.com with SMTP id j58so21803459qtj.0
 for <28620 <at> debbugs.gnu.org>; Mon, 16 Oct 2017 09:31:37 -0700 (PDT)
X-Gm-Message-State: AMCzsaVEvOqWsxdI31kkfY11GKqD8WAwMwFz+X1VjqCKqS18MWQ8qAbt
 TGeHoYt0hjPWhJiRcnkkNJK88nSwdFQZMwNg4nA=
X-Google-Smtp-Source: AOwi7QD0UUoSfBnjnQx6J17ocF2ZO5Ns457DjF2AdU1+1YCBL/tInKckcfYlY6Far57vOaLFHHcj+UvQjV5znMkPKco=
X-Received: by 10.200.54.220 with SMTP id b28mr14299145qtc.186.1508171496825; 
 Mon, 16 Oct 2017 09:31:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Mon, 16 Oct 2017 09:31:06 -0700 (PDT)
In-Reply-To: <59E32CFA.5080405@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN> <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
 <59E32CFA.5080405@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Mon, 16 Oct 2017 12:31:06 -0400
X-Gmail-Original-Message-ID: <CA+OMD9gm_LDZhcHu6QYuv-NepiWBvqeTTB5eJADjUVS5G1xSFQ@HIDDEN>
Message-ID: <CA+OMD9gm_LDZhcHu6QYuv-NepiWBvqeTTB5eJADjUVS5G1xSFQ@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a113755ca542939055bac8abc"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a113755ca542939055bac8abc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Oct 15, 2017 at 5:40 AM, martin rudalics <rudalics@HIDDEN> wrote:

>
> Even if the Emacs frame is covered by another application's frame,
> nothing prevents us from having that covered Emacs frame accept the
> drop.  We could even give frames a "no-accept-drops" parameter and this
> way have a drop on such frames pass the drop through to yet another
> frame below that does accept drops.


=E2=80=8BYes.  My point is that there should be some extension to Emacs'
reporting of window system events that allows a user of such
information to know whether any other application occluded the
Emacs frame at the time and point of release.  Then in cases
where this information can be gleaned from the external window
manager, it can be used in programs.  The user program is still
free to allow a drop to go through in such cases but only if
desired.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> > I guess you are saying that Emacs drag events must start and end within
> =E2=80=8B=E2=80=8B
> > Emacs frames.  I think about it a bit differently.  Since the mouse can
> =E2=80=8B=E2=80=8B
> > move in and out of Emacs frames and release events can occur (in logica=
l
> =E2=80=8B=E2=80=8B
> > Z-ordered OS window space) outside of Emacs, yet still register with
> Emacs
> =E2=80=8B=E2=80=8B
> > (when the release occurs within the geometry of a frame but the frame i=
s
> =E2=80=8B=E2=80=8B
> > covered by another app's window), I think Emacs event handling should
> =E2=80=8B=E2=80=8B
> > return different information when the release frame is not the topmost
> =E2=80=8B=E2=80=8B
> > OS-level window at the point of release.  Then handler code could
> dispatch
> =E2=80=8B=E2=80=8B
> > as necessary.
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> But to be useful, that "handler code" must be written and such code must
> =E2=80=8B=E2=80=8B
> f
> =E2=80=8B=E2=80=8B
> o
> =E2=80=8B=E2=80=8B
> l
> =E2=80=8B=E2=80=8B
> l
> =E2=80=8B=E2=80=8B
> o
> =E2=80=8B=E2=80=8B
> w
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> a
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> s
> =E2=80=8B=E2=80=8B
> t
> =E2=80=8B=E2=80=8B
> a
> =E2=80=8B=E2=80=8B
> n
> =E2=80=8B=E2=80=8B
> d
> =E2=80=8B=E2=80=8B
> a
> =E2=80=8B=E2=80=8B
> rd interface for the OS used.


=E2=80=8BIt is not only drag-and-drop that we are interested in.  We
often want to simply call different functions based on whether
the drag release was inside or outside of Emacs.  For example,
Hyperbole now uses a drag release outside of Emacs to clone the
window depressed upon into a new frame.=E2=80=8B

=E2=80=8B=E2=80=8B
>   Consider the trivial task
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> that one Emacs instance wants to drop some text to a second Emacs
> =E2=80=8B=E2=80=8B
> instance.  How would we trigger the drop event on that second instance?


=E2=80=8BYes, you would need to follow a common drag-and-drop protocol.
I don't understand why that is an issue if that is what you want
to do.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B
> > =E2=80=8BEach window has a 'visible' attribute.  Are you saying this is=
 not
> =E2=80=8B=E2=80=8B
> > accurate these days?=E2=80=8B
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> Yes.  The GTK manual says that
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
>   Modern composited windowing systems with pervasive transparency make
> =E2=80=8B=E2=80=8B
>   it impossible to track the visibility of a window reliably,


For programmatic purposes when Emacs receives a mouse button
drag release event, we only care about whether the topmost
window-system window at the point of release is an Emacs frame
or not.  If at that point, it is occluded by another window,
we don't care how transparent that window is and whether the
Emacs frame can be "seen" but only whether it is logically
the window clicked upon.  Again, even if it is not, we can
process the event as if it were *if we so choose* but having
the choice is the key issue here.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> >> (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to retu=
rn all windows on
> =E2=80=8B
> =E2=80=8B
> your system
> =E2=80=8B
> =E2=80=8B=E2=80=8B
> >
> =E2=80=8B=E2=80=8B
> > =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=
=8Bthat would
> supply
> =E2=80=8B=E2=80=8B
> > that information given what you have said?
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> At least for top-level windows.  This will work as long a child windows
> =E2=80=8B=E2=80=8B
> are fully contained by their parents which IIUC is not necessarily true
> =E2=80=8B=E2=80=8B
> for macOS systems.


=E2=80=8BCould you give a concrete example of where this might be a problem
so I could test code against it?
=E2=80=8B

> =E2=80=8B=E2=80=8B
>
> =E2=80=8B
> =E2=80=8B=E2=80=8B
> >
> =E2=80=8B=E2=80=8B
> > and (2) a function would be needed to get the attributes of
> =E2=80=8B
> =E2=80=8B=E2=80=8B
>  those windows.
> =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=8BI have figured that part out from the macOS APIs.
=E2=80=8B
Bob
=E2=80=8B

--001a113755ca542939055bac8abc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Sun, Oct 15, 2=
017 at 5:40 AM, martin rudalics </span><span dir=3D"ltr" style=3D"font-fami=
ly:arial,sans-serif">&lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blan=
k">rudalics@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-seri=
f"> wrote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D""><br></span>
Even if the Emacs frame is covered by another application&#39;s frame,<br>
nothing prevents us from having that covered Emacs frame accept the<br>
drop.=C2=A0 We could even give frames a &quot;no-accept-drops&quot; paramet=
er and this<br>
way have a drop on such frames pass the drop through to yet another<br>
frame below that does accept drops.</blockquote><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BYes.=
=C2=A0 My point is that there should be some extension to Emacs&#39;</div><=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace">repor=
ting of window system events that allows a user of such</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">information to kno=
w whether any other application occluded the</div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace">Emacs frame at the time and p=
oint of release.=C2=A0 Then in cases</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace">where this information can be gleaned=
 from the external window</div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace">manager, it can be used in programs.=C2=A0 The u=
ser program is still</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace">free to allow a drop to go through in such cases but =
only if</div><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace">desired.</div><div class=3D"gmail_default" style=3D"font-family:mo=
nospace,monospace"><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; I guess you are saying that Emacs d=
rag events must start and end within<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; Emacs frames.=C2=A0 I think about i=
t a bit differently.=C2=A0 Since the mouse can<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; move in and out of Emacs frames and=
 release events can occur (in logical<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; Z-ordered OS window space) outside =
of Emacs, yet still register with Emacs<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; (when the release occurs within the=
 geometry of a frame but the frame is<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; covered by another app&#39;s window=
), I think Emacs event handling should<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; return different information when t=
he release frame is not the topmost<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; OS-level window at the point of rel=
ease.=C2=A0 Then handler code could dispatch<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; as necessary.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>But to be useful, that &quot;handler cod=
e&quot; must be written and such code must<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>f<div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>o<di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:=
inline">=E2=80=8B=E2=80=8B</div>l<div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>l<div c=
lass=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inl=
ine">=E2=80=8B=E2=80=8B</div>o<div class=3D"gmail_default" style=3D"font-fa=
mily:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>w<div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline=
">=E2=80=8B=E2=80=8B</div> <div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>a<div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline"=
>=E2=80=8B=E2=80=8B</div> <div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>s<div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace;display:inline">=
=E2=80=8B=E2=80=8B</div>t<div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>a<div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div>n<div class=3D"gmail_default" style=3D"font-family:mon=
ospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>d<div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=E2=80=8B</div>a<div class=3D"gmail_default" style=3D"font-family:monosp=
ace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>rd interface for the =
OS used.</blockquote><div><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace">=E2=80=8BIt is not only drag-and-drop that =
we are interested in.=C2=A0 We</div><div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace">often want to simply call different functio=
ns based on whether</div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace">the drag release was inside or outside of Emacs.=C2=A0=
 For example,</div><div class=3D"gmail_default" style=3D"font-family:monosp=
ace,monospace">Hyperbole now uses a drag release outside of Emacs to clone =
the</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">window depressed upon into a new frame.=E2=80=8B</div><div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace"><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 Consider the=
 trivial task<div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>that one Emacs instance wants to drop so=
me text to a second Emacs<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>instance.=C2=A0 How would we trigger the=
 drop event on that second instance?</blockquote><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BYes, =
you would need to follow a common drag-and-drop protocol.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">I don&#39;t un=
derstand why that is an issue if that is what you want</div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace">to do.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><span class=3D""><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=
=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B</div>&gt; =E2=80=8BEach window has a &#39;visible&#39;=
 attribute.=C2=A0 Are you saying this is not<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; accurate these days?=E2=80=8B<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>Yes.=C2=A0 The GTK manual says that<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 Modern composited windowing syste=
ms with pervasive transparency make<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 it impossible to track the visibi=
lity of a window reliably,</blockquote><div><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">For programmatic purposes=
 when Emacs receives a mouse button</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">drag release event, we only care about=
 whether the topmost</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace">window-system window at the point of release is an Em=
acs frame</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace">or not.=C2=A0 If at that point, it is occluded by another window=
,</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e">we don&#39;t care how transparent that window is and whether the</div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">Emacs =
frame can be &quot;seen&quot; but only whether it is logically</div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">the window =
clicked upon.=C2=A0 Again, even if it is not, we can</div><div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace">process the event as =
if it were *if we so choose* but having</div><div class=3D"gmail_default" s=
tyle=3D"font-family:monospace,monospace">the choice is the key issue here.<=
/div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;&gt; (1) =E2=80=98frame-list-z-order=
=E2=80=99 would have to be able to return all windows on<div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace;display:inline">=E2=80=8B</div>your system<br><div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace;display:inline">=E2=80=8B=E2=80=8B</div>&gt;<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; =E2=80=8BIs it likely we could buil=
d a multi-platform primitive =E2=80=8Bthat would supply<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; that information given what you hav=
e said?<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>At least for top-level windows.=C2=A0 Th=
is will work as long a child windows<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>are fully contained by their parents whi=
ch IIUC is not necessarily true<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>for macOS systems.</blockquote><div><br>=
</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace=
">=E2=80=8BCould you give a concrete example of where this might be a probl=
em</div><div class=3D"gmail_default" style=3D"font-family:monospace,monospa=
ce">so I could test code against it?</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace">=E2=80=8B</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><span class=3D""><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline"=
>=E2=80=8B=E2=80=8B</div>&gt; and (2) a function would be needed to get the=
 attributes of<div class=3D"gmail_default" style=3D"font-family:monospace,m=
onospace;display:inline">=E2=80=8B</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
>=C2=A0those windows.<div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=
=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=
=8B</div></span></blockquote><div><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:monospace,monospace">=E2=80=8BI have figured that part o=
ut from the macOS APIs.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:monospace,monospace">=E2=80=8B</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">Bob</div><div class=3D"gmail_default" =
style=3D"font-family:monospace,monospace">=E2=80=8B</div></div></div></div>

--001a113755ca542939055bac8abc--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 15:57:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 16 11:57:43 2017
Received: from localhost ([127.0.0.1]:44059 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e47lv-0002j1-1m
	for submit <at> debbugs.gnu.org; Mon, 16 Oct 2017 11:57:43 -0400
Received: from mail-qt0-f176.google.com ([209.85.216.176]:53166)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rswgnu@HIDDEN>) id 1e47lt-0002ip-AJ
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 11:57:41 -0400
Received: by mail-qt0-f176.google.com with SMTP id 31so7178556qtz.9
 for <28620 <at> debbugs.gnu.org>; Mon, 16 Oct 2017 08:57:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version;
 bh=MAdhaXoNXFw2STn2lSTH3qChzrbSHKaBAukUpqCrr5o=;
 b=tb7vO7qO6qwrUaKC/I6aH1ZPBLZdakQB6ncZl8vmi9O9hg6xSA296zX83ml9G7K7W2
 1Vnc6RAiJe6NIvPZ5hiyYKZvoRjdvBrWwEAeMNOPrAQLNoHzscm6xUjf1mHvrf9WZAQl
 dcMzvXDQQpjmDUT73SmqBUTKsfoTn4i3Uj8jR7YbaYQGmuFNyf2t7Xq/KxiSvf2doIbM
 U2UmcJI25WMUTlbo3FFnwLGfrGfkGhdOTSxqcPxPmL/ajCFo7ui3ffa8Gr3yQkSkGHa4
 kXAj77ehCfpxskHHwjeIUxtbvIhSFdHIJLhV687lqOZ0aXHoAiD+oZMyouB41xj/k2w6
 1qyg==
X-Gm-Message-State: AMCzsaUWgg0JSD0JnjdmKSUceyZ8txTuiOumPbSYEBuZIPxE7tJ2nwGz
 H5xsSfLhzvZhUwbapUlJ6S4=
X-Google-Smtp-Source: ABhQp+TBGvWmWmTTOdtvVfBbUN6QvgqAmgDlXZp68GrGiUeVHa12CY/3wTR7NfNLMtvaGGtdu1VQJQ==
X-Received: by 10.200.8.53 with SMTP id u50mr14348709qth.106.1508169455612;
 Mon, 16 Oct 2017 08:57:35 -0700 (PDT)
Received: from bka-iMac.local.gnu.org (ool-2f1481cf.dyn.optonline.net.
 [47.20.129.207])
 by smtp.gmail.com with ESMTPSA id p64sm4698787qkd.67.2017.10.16.08.57.34
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 16 Oct 2017 08:57:34 -0700 (PDT)
From: Bob Weiner <rsw@HIDDEN>
To: 28620 <at> debbugs.gnu.org
Subject: Re: bug#28620: (PARTIAL SOLUTION) Mouse drag event records wrong
 window for release when crossing frames
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
Date: Mon, 16 Oct 2017 11:57:33 -0400
In-Reply-To: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 (Robert Weiner's message of "Wed, 27 Sep 2017 11:44:06 -0400")
Message-ID: <m0mv4r13wy.rsw@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) 27.0.50, InfoDock 4.0.8
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: martin rudalics <rudalics@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

Robert Weiner <rsw@HIDDEN> writes:

> With Emacs 25.3 under MacOS 10.12, a drag with mouse-1 depressed from
> the text area of frame F1 to the text area of frame F2 improperly
> generates a drag event whose (posn-window (event-end <event>)) shows
> F1 rather than F2.
>
> Note that for a drag between frames, posn-window should return a frame
> (according to the Elisp manual but not its own doc string).  The bug is
> that the event itself records the wrong frame (the depress frame rather
> than the release frame).
>
> I have confirmed this with Emacs 25.2 under Windows 7 as well.

I have this fixed and working nicely for the GNU Hyperbole package,
which does extensive mouse drag handling.  Hyperbole can now drag buffer
menu items, dired items, and buffers themselves across frames and
display them in any window that receives a release event.  It can also
tell whether the topmost application window at the point of release was
an Emacs frame or a window of another application (for macOS windowing
only), so drags can start in Emacs and end outside.

But this required a good bit of code that I include below just
so you can see what was required.  It would be much simpler once the
drag event release C code in Emacs is improved based upon this work to
at least return the actual window of drag release.

Bob

----------
Code from forthcoming Hyperbole 6.0.2e pre-release (the Python script
at the end will be converted to Objective-C at some point):


(defvar action-key-depress-args nil
  "List of mouse event args from most recent depress of the Action Key.")
(defvar assist-key-depress-args nil
  "List of mouse event args from most recent depress of the Assist Key.")

(defvar action-key-release-args nil
  "List of mouse event args from most recent release of the Action Key.")
(defvar assist-key-release-args nil
  "List of mouse event args from most recent release of the Assist Key.")

(defvar action-key-depress-window nil
  "The last window in which the Action Key was depressed or nil.
This is set to nil when the depress is on an inactive minibuffer.")
(defvar assist-key-depress-window nil
  "The last window in which the Assist Key was depressed or nil.
This is set to nil when the depress is on an inactive minibuffer.")
(defvar action-key-release-window nil
  "The last window in which the Action Key was released or nil.")
(defvar assist-key-release-window nil
  "The last window in which the Assist Key was released or nil.")

(defvar action-key-depress-position nil
  "The last screen position at which the Action Key was depressed or nil.")
(defvar assist-key-depress-position nil
  "The last screen position at which the Assist Key was depressed or nil.")


(defun hmouse-key-release-args-emacs (event)
  "For GNU Emacs, return a possibly modified version of EVENT as a list.
For mouse drags and double and triple clicks, remove any depress location,
compute the actual release location and include that."
  (if (integerp event)
      (list event)
    (let ((ev-type-str (and (listp event) (symbol-name (car event)))))
      (if (or (and ev-type-str
		   (string-match "\\(double\\|triple\\)-mouse" ev-type-str))
	      (not (= (length event) 3)))
	  event
	(let ((pos (event-end event))
	      coords window-and-char-coords)
	  (when (and ev-type-str (string-match "drag-mouse" ev-type-str)
		     ;; end of drag event; If drag crossed frames, the location
		     ;; will contain the frame of the depress point and
		     ;; some relative coordinates; change these to the window of
		     ;; release and window's character coordinates if within a window
		     ;; and to nil if outside of Emacs (as best we can tell).
		     (framep (posn-window pos)))
	    (setq window-and-char-coords (hmouse-window-coordinates event)
		  window (car window-and-char-coords)
		  coords (cadr window-and-char-coords))
	    ;; Modify the values in the event-end structure even if no
	    ;; valid window was found.
	    (setcar pos window)
	    (setcar (nthcdr 2 pos) coords)))
	;; Remove depress coordinates and send only original release coordinates.
	(list (car event) (nth 2 event))))))

(defun hmouse-window-coordinates (&optional event)
  "Return a list (window (x-chars . y-chars)) for optional EVENT.
Always ignores EVENT coordinates and uses current mouse position.
The area of the EVENT is utilized. If EVENT is not given and the
free variable `assist-flag' is non-nil, EVENT is set to
`assist-key-release-args', otherwise, `action-key-release-args'.

The coordinates x-chars and y-chars are relative character
coordinates within the window.  If POSITION is not in a live
window, return nil.  Considers all windows on the selected frame's display."
  (interactive)
  (unless (eventp event)
    (setq event (if assist-flag assist-key-release-args action-key-release-args)))
  (let* ((position (mouse-absolute-pixel-position))
	 (pos-x (car position))
	 (pos-y (cdr position))
	 (window (hmouse-window-at-absolute-pixel-position position t))
	 (edges (when (window-live-p window) (window-edges window t t t)))
	 left top right bottom
	 frame)
    (when edges
      (setq left   (nth 0 edges)
	    top    (nth 1 edges)
	    right  (nth 2 edges)
	    bottom (nth 3 edges))
      (when (or (and event (eq (posn-area (event-start event)) 'mode-line))
		(and (>= pos-x left) (<= pos-x right)
		     (>= pos-y top)  (<= pos-y bottom)))
	;; If position is in a live window, compute position's character
	;; coordinates within the window and return the window with these
	;; coordinates.
	(setq frame (window-frame window)
	      pos-x (round (/ (- pos-x left) (frame-char-width frame)))
	      pos-y (round (/ (- pos-y top)  (+ (frame-char-height frame)
						(hmouse-vertical-line-spacing frame)))))))
    (when (called-interactively-p 'interactive)
      (message "%s at %s coordinates (%s . %s)"
	       (if edges window "No live Emacs window")
	       (if frame "character" "absolute pixel")
	       pos-x pos-y))
    (when edges (list window (cons pos-x pos-y)))))

(defvar hmouse-verify-release-window-flag t
  "When non-nil under the macOS window system, verifies the application of top-most window.
Forces a window system check at a screen position that the top-most
window there is an Emacs frame or treats the location as outside Emacs,
even though an Emacs frame may be below the top-most window.

See function `hmouse-window-at-absolute-pixel-position' for more details.")

(defun hmouse-window-at-absolute-pixel-position (&optional position release-flag)
  "Return the top-most Emacs window at optional POSITION ((x . y) in absolute pixels) or mouse position.
If POSITION is not in a window, return nil.  Considers all windows on
the same display as the selected frame.

If optional RELEASE-FLAG is non-nil, this is part of a Smart Key
release computation, so optimize window selection based on the depress
window already computed.

If the selected frame is a graphical macOS window and
`hmouse-verity-release-window-flag' is non-nil, then return the
top-most Emacs window only if it is the top-most application window at
the position (not below another application's window)."
  (interactive)
  (setq position (or position (mouse-absolute-pixel-position)))
  ;; Proper top-to-bottom listing of frames is available only in Emacs
  ;; 26 and above.  For prior versions, the ordering of the frames
  ;; returned is not guaranteed, so the frame whose window is returned
  ;; may not be the uppermost.
  (let* ((top-to-bottom-frames (if (fboundp 'frame-list-z-order)
				   (frame-list-z-order)
				 (frame-list)))
	 (pos-x (car position))
	 (pos-y (cdr position))
	 edges left top right bottom
	 frame
	 in-frame
	 window)
    ;; First find top-most frame containing position.
    (while (and (not in-frame) top-to-bottom-frames)
      (setq frame (car top-to-bottom-frames)
	    top-to-bottom-frames (cdr top-to-bottom-frames))
      ;; Check that in-frame is valid with frame-live-p since under macOS
      ;; when position is outside a frame, in-frame could be invalid and
      ;; frame-visible-p would trigger an error in that case.
      (when (and (frame-live-p frame) (frame-visible-p frame))
	(setq edges (frame-edges frame)
	      left   (nth 0 edges)
	      top    (nth 1 edges)
	      right  (nth 2 edges)
	      bottom (nth 3 edges))
	(when (and (>= pos-x left) (<= pos-x right)
		   (>= pos-y top)  (<= pos-y bottom))
	  (setq in-frame frame))))
    ;; If in-frame is found, find which of its windows contains
    ;; position and return that.  The window-at call below requires
    ;; character coordinates relative to in-frame, so compute them.
    (when in-frame
      (let ((depress-position (and release-flag (if assist-flag
						    assist-key-depress-position
						  action-key-depress-position)))
	    (depress-window  (and release-flag (if assist-flag
						   assist-key-depress-window
						 action-key-depress-window))))
	(if (and release-flag depress-window (equal position depress-position))
	    ;; This was a click, so we know that the frame of the click
	    ;; is topmost on screen or the mouse events would not have
	    ;; been routed to Emacs.  Reuse saved window of depress rather
	    ;; then running possibly expensive computation to find the
	    ;; topmost application window.
	    (setq window depress-window)
	  (let ((char-x (/ (- pos-x left) (frame-char-width in-frame)))
		(line-y (/ (- pos-y top) (+ (frame-char-height in-frame)
					    (hmouse-vertical-line-spacing in-frame)))))
	    (setq window (window-at char-x line-y in-frame)))
	  ;;
	  ;; Even if in-frame is found, under click-to-focus external window
	  ;; managers, Emacs may have received the drag release event when
	  ;; in-frame was covered by an external application's window.
	  ;; Emacs presently has no way to handle this.  However, for the
	  ;; macOS window system only, Hyperbole has a Python script, topwin, which
	  ;; computes the application of the topmost window at the point of release.
	  ;; If that is Emacs, then we have the right window and nothing need be
	  ;; done; otherwise, set window to nil and return.
	  ;;
	  (when (and hmouse-verify-release-window-flag
		     window (eq (window-system) 'ns))
	    (let ((topwin (executable-find "topwin"))
		  (case-fold-search t)
		  topmost-app)
	      (when (and topwin (file-executable-p topwin))
		(setq topmost-app (shell-command-to-string
				   (format "topwin %d %d" pos-x pos-y)))
		(cond ((string-match "emacs" topmost-app)) ; In an Emacs frame, do nothing.
		      ((or (equal topmost-app "")
			   ;; Any non-Emacs app window
			   (string-match "\\`\\[" topmost-app))
		       ;; Outside of any Emacs frame
		       (setq window nil))
		      (t		; topwin error message
		       ;; Setup of the topwin script is somewhat complicated,
		       ;; so don't trigger an error just because of it.  But
		       ;; display a message so the user knows something happened
		       ;; when topwin encounters an error.
		       (message "(Hyperbole): topwin Python script error: %s" topmost-app)))))))))

    (when (called-interactively-p 'interactive)
      (message "%s at absolute pixel position %s"
	       (or window "No Emacs window") position))
    window))

;; Based on code from subr.el.
(defun hmouse-vertical-line-spacing (frame)
  "Return any extra vertical spacing in pixels between text lines or 0 if none."
  (let ((spacing (when (display-graphic-p frame)
                   (or (with-current-buffer (window-buffer (frame-selected-window frame))
                         line-spacing)
		       (frame-parameter frame 'line-spacing)))))
    (cond ((floatp spacing)
	   (setq spacing (truncate (* spacing (frame-char-height frame)))))
	  ((null spacing)
	   (setq spacing 0)))
    spacing))

------
#!python2
#
# SUMMARY:      topwin: Outputs the [application name] of the topmost window at mouse screen position or nothing if none
# USAGE:        <script> <x-screen-coordinate> <y-screen-coordinate>
#
# REQUIRES:     macOS window system and the python2 and the PyObjC libraries available here: https://pythonhosted.org/pyobjc/install.html
#
# AUTHOR:       Bob Weiner <rsw@HIDDEN>
# ORIG-DATE:    14-Oct-17 at 16:21:53
#
# Copyright (C) 2017  Free Software Foundation, Inc.
# See the "HY-COPY" file for license information.
#
# DESCRIPTION:  
# DESCRIP-END.

import Quartz
from sys import argv, exit

if len(argv) < 3:
    print "%s: ERROR - Call with 2 numeric arguments, X and Y representing an absolute screen position" % argv[0]
    exit(1)

x = int(argv[1]); y = int(argv[2])

# Return the first window only that x,y falls within since the windows are listed in z-order (top of stack to bottom)
def filter_and_print_top_window(x, y):
    win_x = win_y = win_width = win_height = 0

    for v in Quartz.CGWindowListCopyWindowInfo( Quartz.kCGWindowListOptionOnScreenOnly | Quartz.kCGWindowListExcludeDesktopElements, Quartz.kCGNullWindowID ):
        val = v.valueForKey_
        bounds_val = val('kCGWindowBounds').valueForKey_
        
        # If item has a non-zero WindowLayer, it is not an app and is probably system-level, so skip it.
        if not val('kCGWindowIsOnscreen') or val('kCGWindowLayer'):
            continue

        win_x = int(bounds_val('X')); win_y = int(bounds_val('Y'))
        win_width = int(bounds_val('Width')); win_height = int(bounds_val('Height'))

        if win_x <= x and x < win_x + win_width and win_y <= y and y < win_y + win_height:
            print ('[' + ((val('kCGWindowOwnerName') or '') + ']')).encode('utf8')
            # Add this line back in if you need to see the specific window within the app at the given position.
            # + ('' if val('kCGWindowName') is None else (' ' + val('kCGWindowName') or '')) \

            break

# Filter to just the topmost window at (x,y) screen coordinates and print the bracketed [window name], if any.
filter_and_print_top_window(x, y)





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 15:11:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 16 11:11:43 2017
Received: from localhost ([127.0.0.1]:43989 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e473P-0001as-Jx
	for submit <at> debbugs.gnu.org; Mon, 16 Oct 2017 11:11:43 -0400
Received: from mail-qt0-f172.google.com ([209.85.216.172]:47193)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rswgnu@HIDDEN>) id 1e473M-0001ae-E3
 for 28620 <at> debbugs.gnu.org; Mon, 16 Oct 2017 11:11:40 -0400
Received: by mail-qt0-f172.google.com with SMTP id z50so32308764qtj.4
 for <28620 <at> debbugs.gnu.org>; Mon, 16 Oct 2017 08:11:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:subject:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=HUINbFV68No7mC/PAbj57IgLV+6RmE3AoY6ZudIllDI=;
 b=WDOM+OUiVIdwK4TBHJnSywdfubKLgVd0GAsVS88vnuN2Yw0gI9qUkKAwFH7sC2fSzc
 e0knEut9K7JvUm6JLFwXpqVDh6UUctdBqq/gHBZTJOUQrXMtXSFvstefSOrEME5FPch+
 a/jnLjgOEk0ykWPu4xeyI4ylv9Of0uDb8bUdCNGfMW8Ky9GKZOHCDYeSAUFx9M/3TtbP
 GqFnwrv+pzWaIjANeQmH8UvDNvZ3fV5BztcwU8VSqWMo4C12YsNvKy3ktXe/USh2/QGC
 M0Rh+6BqrgsaOadUnR9VhSqrk1CRiUFE/6PHS3e37nTJTXbVhIi+aaG1h0/IEqu12cfB
 lakw==
X-Gm-Message-State: AMCzsaVirZQeMMWmyRT2Uz/oW5Q7Pl8mXmDlKjDHausOOzKRtF1YlxPY
 qpRHt5s1nik9T9XM+98vwbtXbw==
X-Google-Smtp-Source: AOwi7QALM4VwWoSBF07bQrzJ6JkWg6vwzMR+eo3fYSPlgjmmVlGCOZc4m3RPpHW7NEbHeDl1Gu4v/A==
X-Received: by 10.200.45.28 with SMTP id n28mr15192692qta.100.1508166694952;
 Mon, 16 Oct 2017 08:11:34 -0700 (PDT)
Received: from bka-iMac.local.gnu.org (ool-2f1481cf.dyn.optonline.net.
 [47.20.129.207])
 by smtp.gmail.com with ESMTPSA id t34sm4978670qtb.79.2017.10.16.08.11.34
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Mon, 16 Oct 2017 08:11:34 -0700 (PDT)
From: Bob Weiner <rsw@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 28620 <at> debbugs.gnu.org
Subject: Re: Emacs bug#28620: (PARTIAL SOLUTION) mouse-position wrong on macOS
 and Windows 7 after mouse-1 click
Date: Mon, 16 Oct 2017 11:11:33 -0400
In-Reply-To: <CA+OMD9gVr1Gk_gtDoF-bnCfG=5c5h1NJVg4VXRN8v7RqokCB9g@HIDDEN>
 (Robert Weiner's message of "Sat, 30 Sep 2017 17:56:47 -0400")
Message-ID: <m0po9n161m.rsw_-_@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) 27.0.50, InfoDock 4.0.8
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 28620
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

Robert Weiner <rsw@HIDDEN> writes:

I wrote:
>
> =E2=80=8BThe issue, to recap, is that I can't find a function that
> will report the window that a mouse release button event
> occurs in if the depress and release are in different frames
> (for Emacs 25).
>
> In fact, the release event (drag event) contains the wrong
> frame (that of the depress rather than the release).  The wrong=20
> frame is also reported by mouse-position and mouse-pixel-position,
> so window-at can't be used either.

The following is a temporary fix for the mouse-position and
mouse-pixel-position part of the problem.  Something needs to be fixed
in the original functions in the C code, though.  -- Bob

;; From mouse-position:
;;    f =3D SELECTED_FRAME ();
;;    XSETFRAME (lispy_dummy, f);
;;  It seems like the XSETFRAME macro is not properly copying the value of =
f on initial frame selection under the macOS window system.
;;  The problem occurs on other systems as well, e.g. Emacs 25.2 under Wind=
ows 7.
;;  The function below is a temporary fix for this.
(setq mouse-position-function
      (lambda (frame-x-dot-y)
	"Under macOS, mouse-position and mouse-pixel-position sometimes fail to re=
turn the selected-frame (returning the prior frame instead); fix that here."
	(setcar frame-x-dot-y (selected-frame))
	frame-x-dot-y))





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 15 Oct 2017 09:40:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 15 05:40:34 2017
Received: from localhost ([127.0.0.1]:40953 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e3fPO-0005Ls-3A
	for submit <at> debbugs.gnu.org; Sun, 15 Oct 2017 05:40:34 -0400
Received: from mout.gmx.net ([212.227.17.21]:59063)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e3fPM-0005Lc-DT
 for 28620 <at> debbugs.gnu.org; Sun, 15 Oct 2017 05:40:32 -0400
Received: from [192.168.1.100] ([46.125.250.23]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mc9U3-1dmPV201Tz-00JYNJ; Sun, 15
 Oct 2017 11:40:15 +0200
Message-ID: <59E32CFA.5080405@HIDDEN>
Date: Sun, 15 Oct 2017 11:40:10 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: rswgnu@HIDDEN
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN> <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
In-Reply-To: <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:vGSCNXEr076weuVQ0zJ86pjQVruB39e8tO3HEk0QXCMbM5hSb2G
 5U+crDvWY5zydQJZjvHVu5b18NhIDZEvdKZoNSbR62o4TrNLgivSY41sQEgn6rLBRI+/ZNK
 pyX/pilycgG/YrPcvHHjekRhQl6zTkm5PNwU2xczmoFyBWxyhtcgh7L85+RUa0LWO8MbDrD
 S04BButiIDjjh5J0hp3CA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:5QbZCc0juLQ=:SN1jc99XkNIQQf+FLB+zMS
 xsIoJYovJ/aniRyrbhvYgsWBHbJVsTxQSIv3dWsV3BYFXpBWP4zvWTxjjHegcQ3MvYe/r7ZpN
 MIkbRiCPZCzoMqy3Ga3qZoBJxhSTGXbjTsNzBuzEgyfhD5OikmcYdnobnTBMPszMQQkLWB/GU
 nAy6xn/YwN5W0rlF9bAQXhrJEFU+O1a4PNJpPJr0BZH1yvVeAE39qaAcLPebDfdFsnb1rBqua
 lQNKLs/GqmVxSwmg5beKDC64Yh3/W1Ieui2sLXLWg0QIY4xx4Dd4oYPHO+3PbonrqEYwvc3gb
 83lZLjCUpF3mVaSE/8hVsZ9lArlBCrgjiIqrOJuw7VNu1Fio6E9w/PEpiDwL0/otEMAi7W5Rk
 1knsYZUS0O6tmX4CNZUKbu/QFWzDf31Y+Xvx/dQ+IS+M4rBTeV+ZqBFRF8P467dcXcmFM6hiY
 JF0w6vSdC6MqpuqliWy5M0OXXNQyIvSr9tPtKyUX73BoThtuLxbUZI2DIdgRD4Vt7HPApfopl
 BMSW/jnLyJFErYMoCjR3H+lhakd9RWLmZMS+3Xs9gE/B+Bu4oYWfz+GVs86RO04tmpN51615w
 AuVCBju+hP+ioM7qA53XC/6/7EFZgE5oTGiCE9Jo0bOi8TQtEScgXFHeUZApcPjq8Rtwj4WTl
 ITfHy41hQvSpUiG0tqE2UU7dx1wc+IOGjRUlBWJHKYfzS27XTX63AAGpONc4ZyLVKXeXKZ56n
 vU5BL8Bs28CTqK4wxVPEeBWSAuQU2Y9+qKPKIJYK70gXoGrNaHISsEROCCjOTy2PuBf0nv+Ov
 xQMT/WC9cGjbuAD2uiL1PhkxvKdIm3vMpjgLWZ8fQHfZLcyRWqOhBk/n86/unvh2SfG3KS2
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 > =E2=80=8BOk, that indicates that drag-and-drop from Emacs to external =
applications
 > is unlikely but it still leaves the issue of recognizing whether a dra=
g
 > release event maps to an Emacs frame or not (when the frame is covered=
 by
 > an external app's window).  I already have code that recognizes this i=
n
 > Lisp; we should make it a primitive so the drag release code in Emacs =
could
 > report more useful and accurate information in drag release events.

Even if the Emacs frame is covered by another application's frame,
nothing prevents us from having that covered Emacs frame accept the
drop.  We could even give frames a "no-accept-drops" parameter and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

 > I guess you are saying that Emacs drag events must start and end withi=
n
 > Emacs frames.  I think about it a bit differently.  Since the mouse ca=
n
 > move in and out of Emacs frames and release events can occur (in logic=
al
 > Z-ordered OS window space) outside of Emacs, yet still register with E=
macs
 > (when the release occurs within the geometry of a frame but the frame =
is
 > covered by another app's window), I think Emacs event handling should
 > return different information when the release frame is not the topmost=

 > OS-level window at the point of release.  Then handler code could disp=
atch
 > as necessary.

But to be useful, that "handler code" must be written and such code must
follow a standard interface for the OS used.  Consider the trivial task
that one Emacs instance wants to drop some text to a second Emacs
instance.  How would we trigger the drop event on that second instance?

 > =E2=80=8BEach window has a 'visible' attribute.  Are you saying this i=
s not
 > accurate these days?=E2=80=8B

Yes.  The GTK manual says that

   Modern composited windowing systems with pervasive transparency make
   it impossible to track the visibility of a window reliably,

 >> (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to ret=
urn all windows on
 >> =E2=80=8B=E2=80=8B
 >> your system
 >
 >
 > =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=
=8Bthat would supply
 > that information given what you have said?

At least for top-level windows.  This will work as long a child windows
are fully contained by their parents which IIUC is not necessarily true
for macOS systems.

 >> and (2) a function would be needed to get the attributes of
 >> =E2=80=8B=E2=80=8B
 >> those windows.
 >
 >
 > =E2=80=8B2 seems straightforward.

How accurate these attributes will be depends on the windowing system
used.  Look at how hard frame_geometry occasionally works to just get
the real screen estate of an Emacs frame.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 15 Oct 2017 03:32:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 14 23:32:14 2017
Received: from localhost ([127.0.0.1]:40831 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e3Zew-0002Ut-GK
	for submit <at> debbugs.gnu.org; Sat, 14 Oct 2017 23:32:14 -0400
Received: from eggs.gnu.org ([208.118.235.92]:60388)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e3Zev-0002Uf-4H
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 23:32:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e3Zek-0002jz-SS
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 23:32:07 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60873)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e3Zek-0002jk-Pc
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 23:32:02 -0400
Received: from mail-qk0-f170.google.com ([209.85.220.170]:44185)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e3Zek-0002ym-Cj
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 23:32:02 -0400
Received: by mail-qk0-f170.google.com with SMTP id r64so9215122qkc.1
 for <28620 <at> debbugs.gnu.org>; Sat, 14 Oct 2017 20:32:02 -0700 (PDT)
X-Gm-Message-State: AMCzsaXHm2PyTpKw48rOQkWKgbU+wA2SHUGAN3ozcGKwioGyOTnvhpcv
 nlVR8nkzyEDXRV5Chi2E1amebvT8i3HrFRhWJqY=
X-Google-Smtp-Source: ABhQp+Q6l32MDdFLmSfK59VsADSR7VqDFt9csogjA8XeYRioYcjuHBzDLwpG1BgRLzPIQ+tJZamxWAIY3EdOGu1QalA=
X-Received: by 10.55.124.198 with SMTP id x189mr8664833qkc.40.1508038321909;
 Sat, 14 Oct 2017 20:32:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 20:31:31 -0700 (PDT)
In-Reply-To: <CA+OMD9jiBHzeSTjsVTMu0qdETCkGfwD2+MQKNYfAS5kLUDyzvw@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
 <CA+OMD9jiBHzeSTjsVTMu0qdETCkGfwD2+MQKNYfAS5kLUDyzvw@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Sat, 14 Oct 2017 23:31:31 -0400
X-Gmail-Original-Message-ID: <CA+OMD9gfNy3JRg+HrHvbzj2b20N=L-gcJgvc-9R+YFQfrwUOmA@HIDDEN>
Message-ID: <CA+OMD9gfNy3JRg+HrHvbzj2b20N=L-gcJgvc-9R+YFQfrwUOmA@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="94eb2c0626227c3719055b8d88ca"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--94eb2c0626227c3719055b8d88ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 14, 2017 at 2:47 PM, Robert Weiner <rsw@HIDDEN> wrote:

> On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <rsw@HIDDEN> wrote:
>
>> it still leaves the issue of recognizing whether a drag release event
>> maps to an Emacs frame or not (when the frame is covered by an external
>> app's window).
>>
>
=E2=80=8BI have written a Python script that can be used to get this answer=
.  (It
uses the Python-to-Objective-C bridge library that exposes the relevant Mac
APIs to Python)=E2=80=8B.  The script  takes two arguments, X and Y screen =
pixel
coordinates, gets a list of all visible application windows in Z-order and
then prints the application name of the first window that intersects the
(X,Y) position, if any.  If that window is an Emacs frame, we have a match
and otherwise, we don't.

This is a short script that really needs to be recoded into an Objective-C
function that can be exposed to Emacs Lisp.  If anyone who is familiar with
macOS Objective-C code would want to work with me on this, email me and
I'll provide the Python code.  It is only about 28 lines.  -- Bob

--94eb2c0626227c3719055b8d88ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Sat, Oct 14, 2=
017 at 2:47 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family=
:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw=
@gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:=
</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div style=3D"=
font-family:monospace,monospace"><span style=3D"font-family:arial,sans-seri=
f">On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner </span><span dir=3D"ltr" =
style=3D"font-family:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" t=
arget=3D"_blank">rsw@HIDDEN</a>&gt;</span><span style=3D"font-family:arial=
,sans-serif"> wrote:</span><br></div></span><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div style=3D"font-family:monospace,monospace">it still leaves=
 the issue of recognizing whether a drag release event maps to an Emacs fra=
me or not (when the frame is covered by an external app&#39;s window).</div=
></div></blockquote></span></div></div></div></blockquote><div><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=
=8BI have written a Python script that can be used to get this answer.=C2=
=A0 (It uses the Python-to-Objective-C bridge library that exposes the rele=
vant Mac APIs to Python)=E2=80=8B.=C2=A0 The script=C2=A0 takes two argumen=
ts, X and Y screen pixel coordinates, gets a list of all visible applicatio=
n windows in Z-order and then prints the application name of the first wind=
ow that intersects the (X,Y) position, if any.=C2=A0 If that window is an E=
macs frame, we have a match and otherwise, we don&#39;t.</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">This is a s=
hort script that really needs to be recoded into an Objective-C function th=
at can be exposed to Emacs Lisp.=C2=A0 If anyone who is familiar with macOS=
 Objective-C code would want to work with me on this, email me and I&#39;ll=
 provide the Python code.=C2=A0 It is only about 28 lines.=C2=A0 -- Bob</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:monospace,monospa=
ce"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,m=
onospace"><br></div></div></div></div>

--94eb2c0626227c3719055b8d88ca--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 18:48:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 14 14:48:20 2017
Received: from localhost ([127.0.0.1]:40509 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e3RTw-0000cK-0m
	for submit <at> debbugs.gnu.org; Sat, 14 Oct 2017 14:48:20 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e3RTu-0000c1-1U
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 14:48:18 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e3RTl-00067x-Eh
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 14:48:12 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48710)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e3RTl-00067V-BR
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 14:48:09 -0400
Received: from mail-qk0-f177.google.com ([209.85.220.177]:49919)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e3RTl-0000oX-16
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 14:48:09 -0400
Received: by mail-qk0-f177.google.com with SMTP id q83so5484540qke.6
 for <28620 <at> debbugs.gnu.org>; Sat, 14 Oct 2017 11:48:08 -0700 (PDT)
X-Gm-Message-State: AMCzsaUl6CtJZalzmpg3s9q23L/kAEpzUiAQrxy2pZwVxq0lm23Dfbfy
 jFVvrNCQn7wpsT+rA8qYM54lfKruvPS6skCoKxY=
X-Google-Smtp-Source: AOwi7QBbTvpc29+y6ffpNZEo82mbM+j5wJx0bOGKpagCaTZ16JeNX9OkDR6ews8+UthA+PnVqDfH7iBT1Qrm7klzaSU=
X-Received: by 10.55.12.130 with SMTP id 124mr7395300qkm.186.1508006888463;
 Sat, 14 Oct 2017 11:48:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 11:47:37 -0700 (PDT)
In-Reply-To: <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
 <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Sat, 14 Oct 2017 14:47:37 -0400
X-Gmail-Original-Message-ID: <CA+OMD9jiBHzeSTjsVTMu0qdETCkGfwD2+MQKNYfAS5kLUDyzvw@HIDDEN>
Message-ID: <CA+OMD9jiBHzeSTjsVTMu0qdETCkGfwD2+MQKNYfAS5kLUDyzvw@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a114d6da0e7e13f055b863632"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a114d6da0e7e13f055b863632
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <rsw@HIDDEN> wrote:

> it still leaves the issue of recognizing whether a drag release event map=
s
> to an Emacs frame or not (when the frame is covered by an external app's
> window).  I already have code that recognizes this in Lisp; we should mak=
e
> it a primitive so the drag release code in Emacs could report more useful
> and accurate information in drag release events.
>

=E2=80=8BI misspoke.  I have code that detects when the release falls outsi=
de of
the bounds of any Emacs frame.  However, when the release event is over an
Emacs frame that is covered by another application's window, we don't yet
have any information to tell us that, so I cannot detect it yet.  That is
the problem we are discussing how to solve in a general way.

Bob
=E2=80=8B

--001a114d6da0e7e13f055b863632
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Sat, Oct 14, 2=
017 at 1:16 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family=
:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw=
@gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:=
</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:monos=
pace,monospace">it still leaves the issue of recognizing whether a drag rel=
ease event maps to an Emacs frame or not (when the frame is covered by an e=
xternal app&#39;s window).=C2=A0 I already have code that recognizes this i=
n Lisp; we should make it a primitive so the drag release code in Emacs cou=
ld report more useful and accurate information in drag release events.<br><=
/div></div></blockquote><div><br></div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">=E2=80=8BI misspoke.=C2=A0 I have code=
 that detects when the release falls outside of the bounds of any Emacs fra=
me.=C2=A0 However, when the release event is over an Emacs frame that is co=
vered by another application&#39;s window, we don&#39;t yet have any inform=
ation to tell us that, so I cannot detect it yet.=C2=A0 That is the problem=
 we are discussing how to solve in a general way.</div><div class=3D"gmail_=
default" style=3D"font-family:monospace,monospace"><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">Bob</div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8B</di=
v></div></div></div>

--001a114d6da0e7e13f055b863632--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 17:17:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 14 13:17:37 2017
Received: from localhost ([127.0.0.1]:40464 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e3Q48-0006jP-To
	for submit <at> debbugs.gnu.org; Sat, 14 Oct 2017 13:17:37 -0400
Received: from eggs.gnu.org ([208.118.235.92]:52425)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e3Q47-0006jB-BY
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 13:17:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e3Q3y-0001PX-Vj
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 13:17:30 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47825)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e3Q3y-0001PF-Rr
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400
Received: from mail-qk0-f169.google.com ([209.85.220.169]:51469)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e3Q3y-0001ig-FJ
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 13:17:26 -0400
Received: by mail-qk0-f169.google.com with SMTP id 17so8428116qkq.8
 for <28620 <at> debbugs.gnu.org>; Sat, 14 Oct 2017 10:17:26 -0700 (PDT)
X-Gm-Message-State: AMCzsaU73sO9Jy7bTlav+8Y3evvg9+KPFCNBwoV3Hd6hzKS0sKDczg/7
 XQb0TkMe3iTjNW/0XE2lKpArXzlYWFaq0Bwk5Fc=
X-Google-Smtp-Source: AOwi7QBVw1cGLvjksPfEmnHVllT55wzOxW+SZ2kwxRR0e37+i/qVB2OzP/SCFzXohYC4w2KT2SOEygwxxMe+5Lg9VEM=
X-Received: by 10.55.12.130 with SMTP id 124mr7145855qkm.186.1508001445921;
 Sat, 14 Oct 2017 10:17:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Sat, 14 Oct 2017 10:16:55 -0700 (PDT)
In-Reply-To: <59E1CC55.2090400@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
 <59E1CC55.2090400@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Sat, 14 Oct 2017 13:16:55 -0400
X-Gmail-Original-Message-ID: <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
Message-ID: <CA+OMD9iRrcU0YOA8rDDDTAVP=S2gUrrrQkcRv+u2HA_1vQNL-Q@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a114d6da08149f4055b84f226"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a114d6da08149f4055b84f226
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Martin:

Thanks for commenting on this and sharing some of your extensive knowledge
on window event handling and Emacs.

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <rudalics@HIDDEN> wrote:

> > =E2=80=8BI think it is a feature that Emacs receives an event for this =
but a
> defect
> > that it can't distinguish when f2 is atop an external window or not and
> > thus whether the event was actually directed at f2 or not.
>
> =E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it'=
s no defect.
> If it were not internal, Emacs would have to be either able to poll the
> other window's application as to whether it supports dropping an Emacs
> internal string or convert that string to some appropriate coding that
> other applications understand.  Neither of these has been done yet and
> it will be non-trivial to do that for our various platforms.


=E2=80=8BOk, that indicates that drag-and-drop from Emacs to external appli=
cations
is unlikely but it still leaves the issue of recognizing whether a drag
release event maps to an Emacs frame or not (when the frame is covered by
an external app's window).  I already have code that recognizes this in
Lisp; we should make it a primitive so the drag release code in Emacs could
report more useful and accurate information in drag release events.

I guess you are saying that Emacs drag events must start and end within
Emacs frames.  I think about it a bit differently.  Since the mouse can
move in and out of Emacs frames and release events can occur (in logical
Z-ordered OS window space) outside of Emacs, yet still register with Emacs
(when the release occurs within the geometry of a frame but the frame is
covered by another app's window), I think Emacs event handling should
return different information when the release frame is not the topmost
OS-level window at the point of release.  Then handler code could dispatch
as necessary.

I already have Lisp code doing useful things with such information
(presently, I have to adjust the drag release event information).  So I
know it would be helpful to have this as default Emacs event reporting
behavior.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though a=
s you
> note,
> =E2=80=8B=E2=80=8B
> > it is an issue there too.
> =E2=80=8B=E2=80=8B
> > The application-level window managers must have a z-ordering for all
> =E2=80=8B=E2=80=8B
> > windows in order to be able to select and raise windows when they are
> =E2=80=8B=E2=80=8B
> > behind others.  So you are saying that they don't publish this
> information
> =E2=80=8B=E2=80=8B
> > in any useful way that Emacs can obtain, right?
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> All I can say is that when you nowadays try to obtain information on
> =E2=80=8B=E2=80=8B
> whether a window is really visible under X, chances are that you don't
> =E2=80=8B=E2=80=8B
> g
> =E2=80=8B=E2=80=8B
> e
> =E2=80=8B=E2=80=8B
> t
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> i
> =E2=80=8B=E2=80=8B
> t
> =E2=80=8B=E2=80=8B
> .


=E2=80=8BEach window has a 'visible' attribute.  Are you saying this is not
accurate these days?=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B

> =E2=80=8B
>   Querying the z-order will only tell you something like "window
> =E2=80=8B=E2=80=8B
> Y cannot obscure window X because it's lower in the z-order".


=E2=80=8BWe just want to know when given a screen position whether an Emacs=
 frame
is topmost at that position or not.=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8B

> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> > Part of the issue is that the macOS window manager uses click-to-focus,
> so
> =E2=80=8B=E2=80=8B
> > the release event of the drag does not switch focus to the application
> =E2=80=8B=E2=80=8B
> > whose window the release falls upon.
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> As Stefan already mentioned earlier: With a drag operation usually no
> =E2=80=8B=E2=80=8B
> focus shifting occurs anyway.


For the interactive things I am doing, I find that selecting the window of
mouse release is always best but I agree it is not necessary in all
instances.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B
> > However, in drag-n-drop operations,
> =E2=80=8B=E2=80=8B
> > the window manager automatically switches focus to any compatible
> =E2=80=8B=E2=80=8B
> > application that the mouse moves over (after a delay) so that the right
> =E2=80=8B=E2=80=8B
> > application receives the drop (based on Z-order).
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> It's completely up to the window manager which polls the application(s)
> =E2=80=8B=E2=80=8B
> whether they are ready to receive the object to drop.  Emacs is not
> =E2=80=8B=E2=80=8B
> involved in that process.  It would be involved only to tell whether it
> =E2=80=8B=E2=80=8B
> would accept such a string when it's the target of a drop.


=E2=80=8BI understand that.  I was just noting that there is an example of =
a drag
release event handler that selects the window of release as a standard part
of its operation.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> > Mouse wheel events are also delivered to the topmost Z-order window
> without
> =E2=80=8B=E2=80=8B
> > either raising the window or switching focus.
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> Mouse wheel events are completely different and highly window system
> =E2=80=8B=E2=80=8B
> dependent.  Sometimes they get caught before Emacs sees them at all and
> =E2=80=8B=E2=80=8B
> get transformed to scroll bar thumb drag events to the owner of the
> =E2=80=8B=E2=80=8B
> scroll bar nearest to the mouse cursor at the time the wheel gets
> =E2=80=8B=E2=80=8B
> scrolled.


=E2=80=8BAgain, I was just providing context of what might be possible base=
d on
other event handling that occurs already in Emacs under macOS.=E2=80=8B

=E2=80=8B=E2=80=8B
>
> =E2=80=8B
> =E2=80=8B=E2=80=8B
> > So the window manager always knows where it should deliver
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> ... it never "knows".  Some make better guesses and some make worse ...


=E2=80=8BOn macOS the scroll wheel events seem to go to the right window 10=
0% of
the time from what I have seen.=E2=80=8B

=E2=80=8B=E2=80=8B
>
> =E2=80=8B
> =E2=80=8B=E2=80=8B
> > What would the pseudo-code
> =E2=80=8B=E2=80=8B
> > look like to check whether or not an Emacs frame was uppermost at the
> point
> =E2=80=8B=E2=80=8B
> > of mouse release?
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to return =
all windows on
> =E2=80=8B=E2=80=8B
> your system


=E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth=
at would supply
that information given what you have said?
=E2=80=8B=E2=80=8B=E2=80=8B

> =E2=80=8B=E2=80=8B
> and (2) a function would be needed to get the attributes of
> =E2=80=8B=E2=80=8B
> those windows.


=E2=80=8B2 seems straightforward.

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

--001a114d6da08149f4055b84f226
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">Martin:</span></d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><=
span style=3D"font-family:arial,sans-serif"><br></span></div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace"><span style=3D"fon=
t-family:arial,sans-serif">Thanks for commenting on this and sharing some o=
f your extensive knowledge on window event handling and Emacs.</span></div>=
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><spa=
n style=3D"font-family:arial,sans-serif"><br></span></div><div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace"><span style=3D"font-f=
amily:arial,sans-serif">On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics </=
span><span dir=3D"ltr" style=3D"font-family:arial,sans-serif">&lt;<a href=
=3D"mailto:rudalics@HIDDEN" target=3D"_blank">rudalics@HIDDEN</a>&gt;</span=
><span style=3D"font-family:arial,sans-serif"> wrote:</span><br></div><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span class=3D"">&gt; =E2=80=8BI think it is a feature that Emacs rece=
ives an event for this but a defect<br>
&gt; that it can&#39;t distinguish when f2 is atop an external window or no=
t and<br>
&gt; thus whether the event was actually directed at f2 or not.<br>
<br></span>
=E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it&#3=
9;s no defect.<br>
If it were not internal, Emacs would have to be either able to poll the<br>
other window&#39;s application as to whether it supports dropping an Emacs<=
br>
internal string or convert that string to some appropriate coding that<br>
other applications understand.=C2=A0 Neither of these has been done yet and=
<br>
it will be non-trivial to do that for our various platforms.</blockquote><d=
iv><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace">=E2=80=8BOk, that indicates that drag-and-drop from Emacs to exter=
nal applications is unlikely but it still leaves the issue of recognizing w=
hether a drag release event maps to an Emacs frame or not (when the frame i=
s covered by an external app&#39;s window).=C2=A0 I already have code that =
recognizes this in Lisp; we should make it a primitive so the drag release =
code in Emacs could report more useful and accurate information in drag rel=
ease events.</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace">I guess you are saying that Emacs drag events must star=
t and end within Emacs frames.=C2=A0 I think about it a bit differently.=C2=
=A0 Since the mouse can move in and out of Emacs frames and release events =
can occur (in logical Z-ordered OS window space) outside of Emacs, yet stil=
l register with Emacs (when the release occurs within the geometry of a fra=
me but the frame is covered by another app&#39;s window), I think Emacs eve=
nt handling should return different information when the release frame is n=
ot the topmost OS-level window at the point of release.=C2=A0 Then handler =
code could dispatch as necessary.</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace">I already have Lisp code doing u=
seful things with such information (presently, I have to adjust the drag re=
lease event information).=C2=A0 So I know it would be helpful to have this =
as default Emacs event reporting behavior.</div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace"><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span class=3D""><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; =E2=80=8BJust FYI, I am using the m=
acOS window manager, not X, though as you note,<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; it is an issue there too.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; The application-level window manage=
rs must have a z-ordering for all<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; windows in order to be able to sele=
ct and raise windows when they are<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; behind others.=C2=A0 So you are say=
ing that they don&#39;t publish this information<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; in any useful way that Emacs can ob=
tain, right?<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>All I can say is that when you nowadays =
try to obtain information on<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>whether a window is really visible under=
 X, chances are that you don&#39;t<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>g<div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>e<di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:=
inline">=E2=80=8B=E2=80=8B</div>t<div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div> <div c=
lass=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inl=
ine">=E2=80=8B=E2=80=8B</div>i<div class=3D"gmail_default" style=3D"font-fa=
mily:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>t<div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline=
">=E2=80=8B=E2=80=8B</div>.</blockquote><div><br></div><div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace">=E2=80=8BEach windo=
w has a &#39;visible&#39; attribute.=C2=A0 Are you saying this is not accur=
ate these days?=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace,monospace">=E2=80=8B=E2=80=8B=E2=80=8B</div></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace;display:inline">=E2=80=8B</div>=C2=A0 Querying the z-order =
will only tell you something like &quot;window<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>Y cannot obscure window X because it&#39=
;s lower in the z-order&quot;.</blockquote><div><br></div><div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BWe ju=
st want to know when given a screen position whether an Emacs frame is topm=
ost at that position or not.=E2=80=8B</div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B=E2=80=8B</div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D""><div class=3D"gmail_defa=
ult" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><br><div class=3D"gmail_default" style=3D"font-family:monospace=
,monospace;display:inline">=E2=80=8B=E2=80=8B</div>&gt; Part of the issue i=
s that the macOS window manager uses click-to-focus, so<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; the release event of the drag does =
not switch focus to the application<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; whose window the release falls upon=
.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>As Stefan already mentioned earlier: Wit=
h a drag operation usually no<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>focus shifting occurs anyway.</blockquot=
e><div><br></div><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">For the interactive things I am doing, I find that selecting t=
he window of mouse release is always best but I agree it is not necessary i=
n all instances.</div><div class=3D"gmail_default" style=3D"font-family:mon=
ospace,monospace"><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
><div class=3D"gmail_default" style=3D"font-family:monospace,monospace;disp=
lay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B</div>&gt; However, in drag-n-drop operations,<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; the window manager automatically sw=
itches focus to any compatible<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; application that the mouse moves ov=
er (after a delay) so that the right<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; application receives the drop (base=
d on Z-order).<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>It&#39;s completely up to the window man=
ager which polls the application(s)<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>whether they are ready to receive the ob=
ject to drop.=C2=A0 Emacs is not<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>involved in that process.=C2=A0 It would=
 be involved only to tell whether it<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>would accept such a string when it&#39;s=
 the target of a drop.</blockquote><div><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace">=E2=80=8BI understand that.=
=C2=A0 I was just noting that there is an example of a drag release event h=
andler that selects the window of release as a standard part of its operati=
on.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline"=
>=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; Mouse wheel events are also deliver=
ed to the topmost Z-order window without<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; either raising the window or switch=
ing focus.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>Mouse wheel events are completely differ=
ent and highly window system<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>dependent.=C2=A0 Sometimes they get caug=
ht before Emacs sees them at all and<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>get transformed to scroll bar thumb drag=
 events to the owner of the<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>scroll bar nearest to the mouse cursor a=
t the time the wheel gets<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>scrolled.</blockquote><div><br></div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=
=8BAgain, I was just providing context of what might be possible based on o=
ther event handling that occurs already in Emacs under macOS.=E2=80=8B</div=
><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D""><div class=3D"gmail_=
default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=
=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>&gt; So the wi=
ndow manager always knows where it should deliver<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>... it never &quot;knows&quot;.=C2=A0 So=
me make better guesses and some make worse ...</blockquote><div><br></div><=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=
=80=8BOn macOS the scroll wheel events seem to go to the right window 100% =
of the time from what I have seen.=E2=80=8B</div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace,monospace"><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><span class=3D""><div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>&gt; What woul=
d the pseudo-code<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; look like to check whether or not a=
n Emacs frame was uppermost at the point<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; of mouse release?<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>(1) =E2=80=98frame-list-z-order=E2=80=99=
 would have to be able to return all windows on<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>your system</blockquote><div><br></div><=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8BIs it likely we could build a multi-platform primitive =E2=80=8Bth=
at would supply that information given what you have said?</div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8B=E2=
=80=8B=E2=80=8B</div></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div>and (2) a function would be needed to get the attribut=
es of<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>those windows.</blockquote><div><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8B2 seems straightforward.</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace">Bob</div></div><div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B</d=
iv><br></div></div>

--001a114d6da08149f4055b84f226--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 14 Oct 2017 08:35:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 14 04:35:57 2017
Received: from localhost ([127.0.0.1]:38762 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e3HvJ-0002oG-9F
	for submit <at> debbugs.gnu.org; Sat, 14 Oct 2017 04:35:57 -0400
Received: from mout.gmx.net ([212.227.15.19]:61254)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e3HvH-0002nu-GG
 for 28620 <at> debbugs.gnu.org; Sat, 14 Oct 2017 04:35:56 -0400
Received: from [192.168.1.100] ([46.125.249.56]) by mail.gmx.com (mrgmx002
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MNYxW-1eARql10H4-007ECU; Sat, 14
 Oct 2017 10:35:37 +0200
Message-ID: <59E1CC55.2090400@HIDDEN>
Date: Sat, 14 Oct 2017 10:35:33 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: rswgnu@HIDDEN
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
 <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
In-Reply-To: <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:IUE2y/Q7pThXyl6N6OX+L1muBSGkK+jLGGHuk26FhqetWDYQb8G
 An+YdPufIXGO5rRWabqRC432V9A88MAnrZw65zYp5H9UzNZVfHsg1LUpqG585mToD5Amzlf
 sLDHPUK2HzAx4TYfQDLMEPBPXI1hlGEK0kFkEVbLlvkC3xh9TcQXVIJ4ny8twCcbztAJd40
 B2id7guybHvrg7oVPooTw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:yOHegrsvI44=:ksk3BdDBFEvNFP7cMExKK/
 xeVXEumdO8BXbxTqNUNwca/8625iHv5YbTL4+cDIweID13uDp8Chdmug0qsJkkdB5RzX9f0Np
 JJl8MkaZQtJgRXGD57LQbwBDxgdoc1EAUyd0HXs1GREywtio4SaVkuBgW+BwEGGWhLRL87bBq
 9euG3gowS6eikPFw6NxG/vYrrwLTBwCObM+vGrz+KQwFP+bAQR5sr22JMzoVZLoizC3TdbYWx
 XFLEkruTmw1ryHjqBAQn1qtvgrBQXNjTNLOcdzwPKF7Hm/lyEqOqnTFiGofaYMeiED6D+9d4L
 4Y8N/mDN1zbPkT3Osli3Z4efaIGbzdRIGAtUfj398va3pvU7GUB4rhl+wFEnu1aIp6IHnRrqL
 XRK+cvE/67fVdCo3D2dB/VMRtxNaVUuATj+1BDcI06mIhhZ6jq1AZqqXZ7XCfAIWCXOvkNis7
 tKifpK80MMbIZ2yJctfTyLh23yaw+KA+2kNmq2Wpx2EL0yVWETXSwhUeVa7xwO3RjunzelVxA
 dpSygFe53RS0AZFWHAq/47zRbBI1jwHoUt7szGahPJlSxg6PBHJ8f9cDvm84WO1X1zhT70TaT
 NbgTux3KoR12lxYOX0pTIxcqlESAxGckGCRcpQTMeSilqQUd2t11bhMTFkMtD4U/1UCiPYuAj
 oXykBLoZVeOPzyjb1NUdhT6E4ZonrtyWk8QCbm/l2TZU9ImRXFRf5YlnBezuaN9+fo0nWI+un
 3EMQw7kVU4mB2qSTILfp4uNZs2RpasKCcYBMmfLQoqiO6/QfPb8LMFrTm47RV7Lxrtoqx92pL
 7DoTTL9AQfHhZWC1C9+HYwjTcKhwp47YRrUx6ftUxEeTz5QQiQig2o5wt0Pas6ik+M9NsXZ
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)

 > =E2=80=8BI think it is a feature that Emacs receives an event for this=
 but a defect
 > that it can't distinguish when f2 is atop an external window or not an=
d
 > thus whether the event was actually directed at f2 or not.

=E2=80=98mouse-drag-region=E2=80=99 is an Emacs internal function, so it'=
s no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs
internal string or convert that string to some appropriate coding that
other applications understand.  Neither of these has been done yet and
it will be non-trivial to do that for our various platforms.

 > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though =
as you note,
 > it is an issue there too.
 > The application-level window managers must have a z-ordering for all
 > windows in order to be able to select and raise windows when they are
 > behind others.  So you are saying that they don't publish this informa=
tion
 > in any useful way that Emacs can obtain, right?

All I can say is that when you nowadays try to obtain information on
whether a window is really visible under X, chances are that you don't
get it.  Querying the z-order will only tell you something like "window
Y cannot obscure window X because it's lower in the z-order".

 > Part of the issue is that the macOS window manager uses click-to-focus=
, so
 > the release event of the drag does not switch focus to the application=

 > whose window the release falls upon.

As Stefan already mentioned earlier: With a drag operation usually no
focus shifting occurs anyway.

 > However, in drag-n-drop operations,
 > the window manager automatically switches focus to any compatible
 > application that the mouse moves over (after a delay) so that the righ=
t
 > application receives the drop (based on Z-order).

It's completely up to the window manager which polls the application(s)
whether they are ready to receive the object to drop.  Emacs is not
involved in that process.  It would be involved only to tell whether it
would accept such a string when it's the target of a drop.

 > Mouse wheel events are also delivered to the topmost Z-order window wi=
thout
 > either raising the window or switching focus.

Mouse wheel events are completely different and highly window system
dependent.  Sometimes they get caught before Emacs sees them at all and
get transformed to scroll bar thumb drag events to the owner of the
scroll bar nearest to the mouse cursor at the time the wheel gets
scrolled.

 > So the window manager always knows where it should deliver

=2E.. it never "knows".  Some make better guesses and some make worse ...=


 > What would the pseudo-code
 > look like to check whether or not an Emacs frame was uppermost at the =
point
 > of mouse release?

(1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to return =
all windows on
your system and (2) a function would be needed to get the attributes of
those windows.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 13:09:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 12 09:09:13 2017
Received: from localhost ([127.0.0.1]:35006 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e2dEf-0006vc-Cg
	for submit <at> debbugs.gnu.org; Thu, 12 Oct 2017 09:09:13 -0400
Received: from eggs.gnu.org ([208.118.235.92]:51389)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e2dEd-0006vN-Lb
 for 28620 <at> debbugs.gnu.org; Thu, 12 Oct 2017 09:09:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e2dEU-0006AU-B3
 for 28620 <at> debbugs.gnu.org; Thu, 12 Oct 2017 09:09:06 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42553)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e2dEU-0006AE-66
 for 28620 <at> debbugs.gnu.org; Thu, 12 Oct 2017 09:09:02 -0400
Received: from mail-qt0-f169.google.com ([209.85.216.169]:43793)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e2dET-0005MT-T1
 for 28620 <at> debbugs.gnu.org; Thu, 12 Oct 2017 09:09:01 -0400
Received: by mail-qt0-f169.google.com with SMTP id j58so2365490qtj.0
 for <28620 <at> debbugs.gnu.org>; Thu, 12 Oct 2017 06:09:01 -0700 (PDT)
X-Gm-Message-State: AMCzsaWsVqXCmgf7FJxPKssqwDR84Z+K5bMCPgA3PaIA5KxLNtrZcLhF
 gs8ESAJvQsdqo55Xi73BAeF5bRdZMKlE9+HDvRc=
X-Google-Smtp-Source: ABhQp+T91ZbPv/4NHPxsgmBtpuZPhoOEvEdQdv8UQRWYXFA80zNjMmalIEt1oeSrd0mllW2cNs4oDaTRyKHk8oyQXzo=
X-Received: by 10.200.54.220 with SMTP id b28mr3262346qtc.186.1507813741503;
 Thu, 12 Oct 2017 06:09:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Thu, 12 Oct 2017 06:08:30 -0700 (PDT)
In-Reply-To: <59DF2260.5030204@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
 <59DF2260.5030204@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Thu, 12 Oct 2017 09:08:30 -0400
X-Gmail-Original-Message-ID: <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
Message-ID: <CA+OMD9i5a6VYjYpxHPY5ZV_ev+i=15KJcgVVa=Ey4JYSvRaC-Q@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a113755ca73294c055b593e36"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, Alan Third <alan@HIDDEN>,
 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a113755ca73294c055b593e36
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 12, 2017 at 4:05 AM, martin rudalics <rudalics@HIDDEN> wrote:

> > So if I have 2 frames, f1 and f2, and a Chrome web browser window that =
is
> > atop f2, then if I drag from f1 into Chrome above f2, my drag release
> code
> > reports that the release window is in f2 rather than nil, as it should
> be.
> > I am on macOS which uses click to focus, so Emacs still gets the releas=
e
> > event since Chrome has not been selected with a click.
>
> I would call this a feature: f2 is probably the one meaningful target of
> your operation at that screen position.


=E2=80=8BI think it is a feature that Emacs receives an event for this but =
a defect
that it can't distinguish when f2 is atop an external window or not and
thus whether the event was actually directed at f2 or not.

=E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> > Is there any way to deal with external window z-order layering such tha=
t
> =E2=80=8B=E2=80=8B
> > one can tell within Emacs whether the topmost OS-level window at an
> =E2=80=8B=E2=80=8B
> > absolute mouse position is an Emacs frame or not?
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> Not really.  Compositing window managers on X no more allow to track the
> =E2=80=8B=E2=80=8B
> visibility of windows reliably.  So while we can discern the visibility
> =E2=80=8B=E2=80=8B
> of our own (window manager) windows based on what we store in their
> =E2=80=8B=E2=80=8B
> asscociated frames' 'visible' slots, we can't do that for windows of
> =E2=80=8B=E2=80=8B
> other applications.  And processing whatever else XGetWindowAttributes
> =E2=80=8B=E2=80=8B
> returns for another application's window might not be trivial either.
>

=E2=80=8BJust FYI, I am using the macOS window manager, not X, though as yo=
u note,
it is an issue there too.
The application-level window managers must have a z-ordering for all
windows in order to be able to select and raise windows when they are
behind others.  So you are saying that they don't publish this information
in any useful way that Emacs can obtain, right?

Part of the issue is that the macOS window manager uses click-to-focus, so
the release event of the drag does not switch focus to the application
whose window the release falls upon.  However, in drag-n-drop operations,
the window manager automatically switches focus to any compatible
application that the mouse moves over (after a delay) so that the right
application receives the drop (based on Z-order).

Mouse wheel events are also delivered to the topmost Z-order window without
either raising the window or switching focus.

So the window manager always knows where it should deliver at least two
kinds of events and maybe one of those types of events could be used to
help Emacs know whether a release event was over one of its frames or over
the window of an another application.

=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> It should be poss
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> ible to do what you want on Windows (where the debugger
> =E2=80=8B=E2=80=8B
> also notifies you
> =E2=80=8B=E2=80=8B
> when an Emacs frame is obscured) though.

=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BWell, one platform would be a good start.=E2=80=8B  What =
would the pseudo-code
look like to check whether or not an Emacs frame was uppermost at the point
of mouse release?

Thanks,

Bob

--001a113755ca73294c055b593e36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Thu, Oct 12, 2=
017 at 4:05 AM, martin rudalics </span><span dir=3D"ltr" style=3D"font-fami=
ly:arial,sans-serif">&lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blan=
k">rudalics@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-seri=
f"> wrote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; So if I have 2 f=
rames, f1 and f2, and a Chrome web browser window that is<br>
&gt; atop f2, then if I drag from f1 into Chrome above f2, my drag release =
code<br>
&gt; reports that the release window is in f2 rather than nil, as it should=
 be.<br>
&gt; I am on macOS which uses click to focus, so Emacs still gets the relea=
se<br>
&gt; event since Chrome has not been selected with a click.<br>
<br></span>
I would call this a feature: f2 is probably the one meaningful target of<br=
>
your operation at that screen position.</blockquote><div><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BI t=
hink it is a feature that Emacs receives an event for this but a defect tha=
t it can&#39;t distinguish when f2 is atop an external window or not and th=
us whether the event was actually directed at f2 or not.</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace"><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D""><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; Is there any way to deal with exter=
nal window z-order layering such that<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; one can tell within Emacs whether t=
he topmost OS-level window at an<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; absolute mouse position is an Emacs=
 frame or not?<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br></span>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>Not really.=C2=A0 Compositing window man=
agers on X no more allow to track the<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>visibility of windows reliably.=C2=A0 So=
 while we can discern the visibility<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>of our own (window manager) windows base=
d on what we store in their<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>asscociated frames&#39; &#39;visible&#39=
; slots, we can&#39;t do that for windows of<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>other applications.=C2=A0 And processing=
 whatever else XGetWindowAttributes<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>returns for another application&#39;s wi=
ndow might not be trivial either.<br></blockquote><div><br></div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BJust =
FYI, I am using the macOS window manager, not X, though as you note, it is =
an issue there too.</div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace">The application-level window managers must have a z-or=
dering for all windows in order to be able to select and raise windows when=
 they are behind others.=C2=A0 So you are saying that they don&#39;t publis=
h this information in any useful way that Emacs can obtain, right?</div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">P=
art of the issue is that the macOS window manager uses click-to-focus, so t=
he release event of the drag does not switch focus to the application whose=
 window the release falls upon.=C2=A0 However, in drag-n-drop operations, t=
he window manager automatically switches focus to any compatible applicatio=
n that the mouse moves over (after a delay) so that the right application r=
eceives the drop (based on Z-order).</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace">Mouse wheel events are also del=
ivered to the topmost Z-order window without either raising the window or s=
witching focus.</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace">So the window manager always knows where it should d=
eliver at least two kinds of events and maybe one of those types of events =
could be used to help Emacs know whether a release event was over one of it=
s frames or over the window of an another application.</div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace"><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div class=3D"gmail_default" style=3D"font-family:mon=
ospace,monospace;display:inline">=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>It should be poss<div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace;display:inline">=E2=80=8B=E2=80=8B</div>ible to do what you want on =
Windows (where the debugger<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>also notifies you <div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=
=E2=80=8B</div>when an Emacs frame is obscured) though.</blockquote><div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=
=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace">=E2=80=8B=E2=80=8BWell, one platform would be a good start.=
=E2=80=8B=C2=A0 What would the pseudo-code look like to check whether or no=
t an Emacs frame was uppermost at the point of mouse release?</div></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
Thanks,</div><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace"><br></div><div class=3D"gmail_default" style=3D"font-family:monosp=
ace,monospace">Bob</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace"><br></div></div></div></div>

--001a113755ca73294c055b593e36--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 08:06:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 12 04:06:23 2017
Received: from localhost ([127.0.0.1]:34828 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e2YVb-0005bv-4M
	for submit <at> debbugs.gnu.org; Thu, 12 Oct 2017 04:06:23 -0400
Received: from mout.gmx.net ([212.227.15.15]:59073)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e2YVZ-0005bh-0z
 for 28620 <at> debbugs.gnu.org; Thu, 12 Oct 2017 04:06:21 -0400
Received: from [192.168.1.100] ([46.125.250.116]) by mail.gmx.com (mrgmx001
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MHoWj-1dyzjN0JJd-003eCA; Thu, 12
 Oct 2017 10:06:04 +0200
Message-ID: <59DF2260.5030204@HIDDEN>
Date: Thu, 12 Oct 2017 10:05:52 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: rswgnu@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 
 Alan Third <alan@HIDDEN>, 28620 <at> debbugs.gnu.org
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
In-Reply-To: <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:svhNR9CoxT8yHB5Tg+GMOjo6s2y0PSH5nzoxVlqlRWXAZY9S1qb
 d/8C8TpyxcaAl3bJmavKIyhy6vKbSuNf1ysuKx1OpK3qncSvUQ5JUFXOApb/evkJTzo+ibj
 bOSBuvQzGL06XVCkdG7lHtlqI7BMmRuFH/JvI2QMJGHDT72jUxExmcrjUGwok0KLX1yc/Rb
 V3Rmn/fQJpKCxUE++mFmQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:lVNrpQNU9MI=:k5/5hqyCdqZhtn6/XrNZe1
 4AqWN319mHmc2LrQxeJvwUKcAYmP3kGtb98PguGgSuIR3ER3m7jYzI6bCTx/s/ID9l1GsKi/M
 ivRgv80amnZcl8hsMggnEBfMclT4PR2tYog+z5Tk+riQFqszDta8BKqoUSTG6T4z4t5CeoXfa
 g6YhKc+rsR8D/DSv+vp1EIuv8KLgq6dHTPtXQ1EXUT3hi/5Y5SmuvHVWWi/dXDwIYJFQDjFIa
 kME8l0yA3M/8pJnC2Nm0Tog9sMNZU9u2lkyAMVBqj1PKFvnpFpVP+YwslRgpyyxsyPsBr0KGZ
 UmJohGSCRN6JVZqllP+tnqqBr96y+7lH4y3c3ZoWZ69ZOQMCgMPToTcbmX4OVO7Xm3tbxPFa8
 M6UuuhXKPT92tl42d6nIsFfEwLcLhSeFIsTU5kJNTZo49RotxAwGPEcFjU2b6+4+FtjH2+5zC
 yFsMIM+iW9wAIDyX0cDtKqH4uR07AlHl0qY+DomyjUzP2jPjy/X4RprdaiaYsRsT7G1aK5msU
 uwmuAgq9coDAeot8PPWshYVbEkxspWrd2RthyOIhN84apcuKIztgLWOqYtULj+AzZXreu/51m
 TT2isZNIur9QxLtJK5G+/H75JdgcV7vV3twZi0UEE+rR0oMZIrIG93zCIQUs0pDdlabg7mVQV
 bggooToyztumOwIZjK1KhvYNEJz1xNZS9lFZyv16gDTYCKVmma6gHfd5X8yYdoXerZ8SLHrZj
 zbvqPLC7E8+/Mt0zl7+kJcWP92vEoewq0g9yczncj2h2jPzdutzK8unj0odvFynYhJIUY3ghG
 F/AiS7mITTlORM4EhrW8dvjpIllPXjvq+F6lS0QyOKkmIutDoeDiflbMEYR7BhX0ZXrdDOK
X-Spam-Score: 4.9 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > So if I have 2 frames, f1 and f2, and a Chrome web browser
 window that is > atop f2, then if I drag from f1 into Chrome above f2, my
 drag release code > reports that the release window is in f2 rather than
 nil, as it should be. > I am on macOS which uses click to focus, so Emacs
 still gets the release > event since Chrome has not been selected with a
 click. [...] 
 Content analysis details:   (4.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
 [46.125.250.116 listed in dnsbl.sorbs.net]
 0.5 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
 [212.227.15.15 listed in dnsbl.sorbs.net]
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [46.125.250.116 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
 trust [212.227.15.15 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
 (rudalics[at]gmx.at)
X-Debbugs-Envelope-To: 28620
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 4.9 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > So if I have 2 frames, f1 and f2, and a Chrome web browser
    window that is > atop f2, then if I drag from f1 into Chrome above f2, my
    drag release code > reports that the release window is in f2 rather than
   nil, as it should be. > I am on macOS which uses click to focus, so Emacs
   still gets the release > event since Chrome has not been selected with a click.
    [...] 
 
 Content analysis details:   (4.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  1.5 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                             [46.125.250.116 listed in dnsbl.sorbs.net]
  0.5 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                             [212.227.15.15 listed in dnsbl.sorbs.net]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [46.125.250.116 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at http://www.dnswl.org/, low
                             trust
                             [212.227.15.15 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail provider
                             (rudalics[at]gmx.at)

 > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
 > atop f2, then if I drag from f1 into Chrome above f2, my drag release code
 > reports that the release window is in f2 rather than nil, as it should be.
 > I am on macOS which uses click to focus, so Emacs still gets the release
 > event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

 > Is there any way to deal with external window z-order layering such that
 > one can tell within Emacs whether the topmost OS-level window at an
 > absolute mouse position is an Emacs frame or not?

Not really.  Compositing window managers on X no more allow to track the
visibility of windows reliably.  So while we can discern the visibility
of our own (window manager) windows based on what we store in their
asscociated frames' 'visible' slots, we can't do that for windows of
other applications.  And processing whatever else XGetWindowAttributes
returns for another application's window might not be trivial either.

It should be possible to do what you want on Windows (where the debugger
also notifies you when an Emacs frame is obscured) though.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 01:47:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 11 21:47:58 2017
Received: from localhost ([127.0.0.1]:34664 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e2SbO-00025P-B4
	for submit <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:47:58 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53005)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e2SbM-00025C-NV
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:47:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e2SbE-0001AF-IT
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:47:51 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34847)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e2SbE-00019r-Ea
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:47:48 -0400
Received: from mail-qt0-f170.google.com ([209.85.216.170]:54536)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e2SbE-0004Lh-1U
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:47:48 -0400
Received: by mail-qt0-f170.google.com with SMTP id z19so10868519qtg.11
 for <28620 <at> debbugs.gnu.org>; Wed, 11 Oct 2017 18:47:47 -0700 (PDT)
X-Gm-Message-State: AMCzsaWPdUg+Ng9MEpQULzHAmnqvpW2KhnThJ+0DCIJ+K8s+n+Y9X8pr
 xNa6jgdLoeUNa7r3/vzQzd0abqjt/kPY2pcKRB0=
X-Google-Smtp-Source: ABhQp+T99ACZy8SK37n4DVmQqcaOXn7We11LL3jThnrd9aAuHAEcX3pc74EDzEzRde8U+cMUElMFoq7SFjwxQ0XcYoU=
X-Received: by 10.55.25.85 with SMTP id k82mr1210955qkh.223.1507772867597;
 Wed, 11 Oct 2017 18:47:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.37.243 with HTTP; Wed, 11 Oct 2017 18:47:16 -0700 (PDT)
In-Reply-To: <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
 <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 11 Oct 2017 21:47:16 -0400
X-Gmail-Original-Message-ID: <CA+OMD9j_J8OYgnhDMp4Ejy3J7PvJv5DTr8VONy5tfd_rg0UcuQ@HIDDEN>
Message-ID: <CA+OMD9j_J8OYgnhDMp4Ejy3J7PvJv5DTr8VONy5tfd_rg0UcuQ@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: Eli Zaretskii <eliz@HIDDEN>, martin rudalics <rudalics@HIDDEN>,
 Alan Third <alan@HIDDEN>, 28620 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="001a11473a842cdc0f055b4fba30"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a11473a842cdc0f055b4fba30
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 11, 2017 at 9:35 PM, Robert Weiner <rsw@HIDDEN> wrote:

>
> Is there any way to deal with external window z-order layering such that
> one can tell within Emacs whether the topmost OS-level window at an
> absolute mouse position is an Emacs frame or not?
>

=E2=80=8BOne idea is to expand frame-list-z-order with a 2nd optional argum=
ent of
all-display-windows-flag which when non-nil would include all of the
OS-level windows in the returned list.  Maybe a new object type or
frame-variant is needed for this.  Then just add another function that
returns the edge coordinates for such windows and we could account for them
in any z-ordering computations.  What do you think?

Bob
=E2=80=8B

--001a11473a842cdc0f055b4fba30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 11, 2=
017 at 9:35 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family=
:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw=
@gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:=
</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:monos=
pace,monospace"><br></div><div style=3D"font-family:monospace,monospace">Is=
 there any way to deal with external window z-order layering such that one =
can tell within Emacs whether the topmost OS-level window at an absolute mo=
use position is an Emacs frame or not?</div></div></blockquote><div><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8BOne idea is to expand frame-list-z-order with a 2nd optional argum=
ent of all-display-windows-flag which when non-nil would include all of the=
 OS-level windows in the returned list.=C2=A0 Maybe a new object type or fr=
ame-variant is needed for this.=C2=A0 Then just add another function that r=
eturns the edge coordinates for such windows and we could account for them =
in any z-ordering computations.=C2=A0 What do you think?</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">Bob</div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=
=8B</div></div></div></div>

--001a11473a842cdc0f055b4fba30--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 01:35:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 11 21:35:56 2017
Received: from localhost ([127.0.0.1]:34656 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e2SPj-0001mg-IS
	for submit <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:35:56 -0400
Received: from eggs.gnu.org ([208.118.235.92]:48243)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e2SPi-0001mR-4F
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:35:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e2SPZ-00023q-M6
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:35:48 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34724)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e2SPZ-00023Z-Gy
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:35:45 -0400
Received: from mail-qt0-f181.google.com ([209.85.216.181]:51698)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e2SPZ-00016d-3F
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 21:35:45 -0400
Received: by mail-qt0-f181.google.com with SMTP id q4so10838649qtq.8
 for <28620 <at> debbugs.gnu.org>; Wed, 11 Oct 2017 18:35:45 -0700 (PDT)
X-Gm-Message-State: AMCzsaXo1a2lcF4F/7ck/iRtzSKsRApnnz6WRV5Eq9P6PGd9EeN0uzq2
 e8dGy6HuNo6khz2cFQ6mSzJaWRnNEOY3LWB/GA4=
X-Google-Smtp-Source: AOwi7QD5fp18DoOQHTnPnieU70l4vkimlqewJOgNxJ0fYEYJhgr005d0NvWxEBFN/sLrMwbPbAdybcykEqxN0/Mnees=
X-Received: by 10.200.48.74 with SMTP id g10mr1368275qte.121.1507772144632;
 Wed, 11 Oct 2017 18:35:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 11 Oct 2017 18:35:13 -0700 (PDT)
In-Reply-To: <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
 <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 11 Oct 2017 21:35:13 -0400
X-Gmail-Original-Message-ID: <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
Message-ID: <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: Eli Zaretskii <eliz@HIDDEN>, martin rudalics <rudalics@HIDDEN>,
 Alan Third <alan@HIDDEN>, 28620 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="001a113a0518154d2a055b4f8f22"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a113a0518154d2a055b4f8f22
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I now have drags working across frames (after manipulating the drag button
release event data to include the proper window and coordinates, though
only in Lisp right now).  As shown in the last message, I also have a
function that finds the proper Emacs window given some display
coordinates.  The only remaining problem seems to be that none of this
accounts for external application windows that may be obscuring an Emacs
frame.

So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
atop f2, then if I drag from f1 into Chrome above f2, my drag release code
reports that the release window is in f2 rather than nil, as it should be.
I am on macOS which uses click to focus, so Emacs still gets the release
event since Chrome has not been selected with a click.

Is there any way to deal with external window z-order layering such that
one can tell within Emacs whether the topmost OS-level window at an
absolute mouse position is an Emacs frame or not?

Thanks,

Bob


On Wed, Oct 11, 2017 at 2:49 PM, Robert Weiner <rsw@HIDDEN> wrote:

> On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <rsw@HIDDEN> wrote:
>
>>
>> =E2=80=8BMartin wrote:=E2=80=8B
>>
>>> Take the position of the event-end (if it's a frame) and translate it
>>> into absolute screen coordinates (the Elisp manual should give you
>>> enough clues to do that).  Or, try =E2=80=98mouse-absolute-pixel-positi=
on=E2=80=99 - it
>>> should give you the screen position of the mouse at that time so you ca=
n
>>> ignore the event completely.
>>>
>>> Then walk all your windows and compare that position with whatever
>>> =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window. =
 If you have two
>>> or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare=
 the result
>>> against those windows' frames.  No hands, IMHO.
>>> =E2=80=8B=E2=80=8B
>>>
>> =E2=80=8B=E2=80=8B
>
> =E2=80=8B  Eli wrote:
>     =E2=80=8B=E2=80=8B
> Why cannot you compute the frame at button release using the a
> =E2=80=8B=E2=80=8B
> lgorithm
>          proposed by Martin, given the mouse position at button release?=
=E2=80=8B
>
>
>>
>>> =E2=80=8B=E2=80=8B
>>>
>> I w
>> =E2=80=8B=E2=80=8B
>> rote:
>>   =E2=80=8B
>> =E2=80=8B=E2=80=8B
>> frame-list-z-order is Emacs 26 only; I need something that works with
>> older versions.=E2=80=8B
>> =E2=80=8B=E2=80=8B
>> =E2=80=8B=E2=80=8B
>> I'll see if I can make this work under Emacs 26 and then we can
>> contemplate a solution that would apply to earlier versions.
>> =E2=80=8B=E2=80=8B
>> Thanks for the reminder.  It does still seem to me that there should be =
a
>> function that takes a mouse position and returns
>> =E2=80=8B=E2=80=8B
>> the top-most Emacs window that the position is in or nil.  I'll work on
>> it.
>>
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function.  It was easi=
er than I expected thanks
> to Martin's pointers.  Now how can we make this work (replacing
> frame-list-z-order) for Emacs versions prior to 26?  -- Bob
>
> (defun window-at-absolute-pixel-position (&optional position)
>   "Return the top-most Emacs window at optional POSITION ((X . Y) in
> pixels) or mouse position.
> If POSITION is not in a window, return nil.  Considers all windows on the
> the same terminal
> display as the selected frame."
>   (interactive)
>   (setq position (or position (mouse-absolute-pixel-position)))
>   (let* ((top-to-bottom-frames (frame-list-z-order))
> (pos-x (car position))
> (pos-y (cdr position))
> edges left top right bottom
> frame
> in-frame
> window)
>     ;; First find top-most frame containing position.
>     (while (and (not in-frame) top-to-bottom-frames)
>       (setq frame (car top-to-bottom-frames)
>     top-to-bottom-frames (cdr top-to-bottom-frames))
>       ;; Check that in-frame is valid with frame-live-p since under macOS
>       ;; when position is outside a frame, in-frame could be invalid and
>       ;; frame-visible-p would trigger an error in that case.
>       (when (and (frame-live-p frame) (frame-visible-p frame))
> (setq edges (frame-edges frame)
>       left   (nth 0 edges)
>       top    (nth 1 edges)
>       right  (nth 2 edges)
>       bottom (nth 3 edges))
> (when (and (>=3D pos-x left) (<=3D pos-x right)
>    (>=3D pos-y top)  (<=3D pos-y bottom))
>   (setq in-frame frame))))
>     ;; If in-frame is found, find which of its windows contains
>     ;; position and return that.  The window-at call below requires
>     ;; character coordinates relative to in-frame, so compute them.
>     (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
>   pos-y (/ (- pos-y top) (frame-char-height in-frame))
>   window (window-at pos-x pos-y in-frame))
>     (if (called-interactively-p 'interactive)
>   (message "%s at absolute pixel position %s"
>    (or window "No Emacs window") position))
>     window))
>

--001a113a0518154d2a055b4f8f22
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">I now have drags working across frames (after manipulating the=
 drag button release event data to include the proper window and coordinate=
s, though only in Lisp right now).=C2=A0 As shown in the last message, I al=
so have a function that finds the proper Emacs window given some display co=
ordinates.=C2=A0 The only remaining problem seems to be that none of this a=
ccounts for external application windows that may be obscuring an Emacs fra=
me.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace">So if I have 2 frames, f1 and f2, and a Chrome web browser windo=
w that is atop f2, then if I drag from f1 into Chrome above f2, my drag rel=
ease code reports that the release window is in f2 rather than nil, as it s=
hould be.=C2=A0 I am on macOS which uses click to focus, so Emacs still get=
s the release event since Chrome has not been selected with a click.</div><=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"=
>Is there any way to deal with external window z-order layering such that o=
ne can tell within Emacs whether the topmost OS-level window at an absolute=
 mouse position is an Emacs frame or not?</div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace">Thanks,</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">Bob</div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
 Oct 11, 2017 at 2:49 PM, Robert Weiner <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:rsw@HIDDEN" target=3D"_blank">rsw@HIDDEN</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace"><span style=3D=
"font-family:arial,sans-serif">On Wed, Oct 11, 2017 at 1:16 PM, Robert Wein=
er </span><span dir=3D"ltr" style=3D"font-family:arial,sans-serif">&lt;<a h=
ref=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw@HIDDEN</a>&gt;</span><spa=
n style=3D"font-family:arial,sans-serif"> wrote:</span><br></div></span><di=
v class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"m_-36275705455078702gmail-m_-2807733671338235013gmail-m_681535470529625=
443h5"><div style=3D"font-family:monospace,monospace"><br></div></div></div=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><div style=3D"f=
ont-family:monospace,monospace">=E2=80=8BMartin wrote:=E2=80=8B</div></div>=
<div style=3D"font-family:monospace,monospace"><span class=3D"m_-3627570545=
5078702gmail-m_-2807733671338235013gmail-m_681535470529625443m_633570120196=
9505853gmail-im" style=3D"font-family:arial,sans-serif;font-size:12.8px"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">Take the position of the ev=
ent-end (if it&#39;s a frame) and translate it<br>into absolute screen coor=
dinates (the Elisp manual should give you<br>enough clues to do that).=C2=
=A0 Or, try =E2=80=98mouse-absolute-pixel-position<wbr>=E2=80=99 - it<br>sh=
ould give you the screen position of the mouse at that time so you can<br>i=
gnore the event completely.<br><br>Then walk all your windows and compare t=
hat position with whatever<br>=E2=80=98window-absolute-pixel-edges=E2=80=99=
 returns for that window.=C2=A0 If you have two<br>or more positives, run =
=E2=80=98frame-list-z-order=E2=80=99 and compare the result<br>against thos=
e windows&#39; frames.=C2=A0 No hands, IMHO.<div class=3D"gmail_default" st=
yle=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</=
div></blockquote></span></div></div></div></div></blockquote><div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline=
">=E2=80=8B=E2=80=8B</div>=C2=A0</div></span><span class=3D""><div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inlin=
e">=E2=80=8B=C2=A0 Eli wrote:</div></div><span style=3D"font-size:12.8px"><=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa=
y:inline">=C2=A0 =C2=A0 =E2=80=8B=E2=80=8B</div>Why cannot you compute the =
frame at button release using the a<div class=3D"gmail_default" style=3D"fo=
nt-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>lgori=
thm</span><br style=3D"font-size:12.8px"><div><div class=3D"gmail_default" =
style=3D"font-family:monospace,monospace;display:inline"><span style=3D"fon=
t-size:12.8px;font-family:arial,sans-serif">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0proposed by Martin, given the mouse position at button release?</span>=
=E2=80=8B</div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><d=
iv style=3D"font-family:monospace,monospace"><span class=3D"m_-362757054550=
78702gmail-m_-2807733671338235013gmail-m_681535470529625443m_63357012019695=
05853gmail-im" style=3D"font-family:arial,sans-serif;font-size:12.8px"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:smal=
l">=C2=A0<div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace;display:inline">=E2=80=8B=E2=80=8B</div></span></blockquote></span></di=
v></div></div></div></blockquote></span><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote"><div style=3D"font-family:monospace,monospace"><span class=3D"m_=
-36275705455078702gmail-m_-2807733671338235013gmail-m_681535470529625443m_6=
335701201969505853gmail-im" style=3D"font-family:arial,sans-serif;font-size=
:12.8px"><div></div><div>I w<div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>rote:</div><=
/span><span class=3D""><div style=3D"font-size:12.8px">=C2=A0 =E2=80=8B<div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:i=
nline">=E2=80=8B=E2=80=8B</div>frame-list-z-order is Emacs 26 only; I need =
something that works with older versions.=E2=80=8B</div><div style=3D"font-=
size:12.8px"><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace">=E2=80=8B=E2=80=8B</div></div><div style=3D"font-size:12.8px"><div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:i=
nline">=E2=80=8B=E2=80=8B</div>I&#39;ll see if I can make this work under E=
macs 26 and then we can contemplate a solution that would apply to earlier =
versions.</div><div style=3D"font-size:12.8px"><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=
=8B</div>Thanks for the reminder.=C2=A0 It does still seem to me that there=
 should be a function that takes a mouse position and returns</div><div sty=
le=3D"font-size:12.8px"><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>the top-most Ema=
cs window that the position is in or nil.=C2=A0 I&#39;ll work on it.</div><=
/span></div></div></div></div></blockquote><div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B</div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8B=
=E2=80=8B=E2=80=8BAnd now there is such a function.=C2=A0 It was easier tha=
n I expected thanks to Martin&#39;s pointers.=C2=A0 Now how can we make thi=
s work (replacing frame-list-z-order) for Emacs versions prior to 26?=C2=A0=
 -- Bob</div></div><div class=3D"gmail_default" style=3D"font-family:monosp=
ace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace"><div class=3D"gmail_default"><div class=3D"gmail_defau=
lt"><div class=3D"gmail_default"><div class=3D"gmail_default">(defun window=
-at-absolute-pixel-<wbr>position (&amp;optional position)</div><div class=
=3D"gmail_default">=C2=A0 &quot;Return the top-most Emacs window at optiona=
l POSITION ((X . Y) in pixels) or mouse position.</div><div class=3D"gmail_=
default">If POSITION is not in a window, return nil.=C2=A0 Considers all wi=
ndows on the the same terminal</div><div class=3D"gmail_default">display as=
 the selected frame.&quot;</div><div class=3D"gmail_default">=C2=A0 (intera=
ctive)</div><div class=3D"gmail_default">=C2=A0 (setq position (or position=
 (mouse-absolute-pixel-<wbr>position)))</div><div class=3D"gmail_default">=
=C2=A0 (let* ((top-to-bottom-frames (frame-list-z-order))</div><div class=
=3D"gmail_default"><span style=3D"white-space:pre-wrap">	</span> (pos-x (ca=
r position))</div><div class=3D"gmail_default"><span style=3D"white-space:p=
re-wrap">	</span> (pos-y (cdr position))</div><div class=3D"gmail_default">=
<span style=3D"white-space:pre-wrap">	</span> edges left top right bottom</=
div><div class=3D"gmail_default"><span style=3D"white-space:pre-wrap">	</sp=
an> frame</div><div class=3D"gmail_default"><span style=3D"white-space:pre-=
wrap">	</span> in-frame</div><div class=3D"gmail_default"><span style=3D"wh=
ite-space:pre-wrap">	</span> window)</div><div class=3D"gmail_default">=C2=
=A0 =C2=A0 ;; First find top-most frame containing position.</div><div clas=
s=3D"gmail_default">=C2=A0 =C2=A0 (while (and (not in-frame) top-to-bottom-=
frames)</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 (setq frame =
(car top-to-bottom-frames)</div><div class=3D"gmail_default"><span style=3D=
"white-space:pre-wrap">	</span>=C2=A0 =C2=A0 top-to-bottom-frames (cdr top-=
to-bottom-frames))</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 ;=
; Check that in-frame is valid with frame-live-p since under macOS</div><di=
v class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 ;; when position is outside =
a frame, in-frame could be invalid and</div><div class=3D"gmail_default">=
=C2=A0 =C2=A0 =C2=A0 ;; frame-visible-p would trigger an error in that case=
.</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 (when (and (frame-=
live-p frame) (frame-visible-p frame))</div><div class=3D"gmail_default"><s=
pan style=3D"white-space:pre-wrap">	</span>(setq edges (frame-edges frame)<=
/div><div class=3D"gmail_default"><span style=3D"white-space:pre-wrap">	</s=
pan>=C2=A0 =C2=A0 =C2=A0 left=C2=A0 =C2=A0(nth 0 edges)</div><div class=3D"=
gmail_default"><span style=3D"white-space:pre-wrap">	</span>=C2=A0 =C2=A0 =
=C2=A0 top=C2=A0 =C2=A0 (nth 1 edges)</div><div class=3D"gmail_default"><sp=
an style=3D"white-space:pre-wrap">	</span>=C2=A0 =C2=A0 =C2=A0 right=C2=A0 =
(nth 2 edges)</div><div class=3D"gmail_default"><span style=3D"white-space:=
pre-wrap">	</span>=C2=A0 =C2=A0 =C2=A0 bottom (nth 3 edges))</div><div clas=
s=3D"gmail_default"><span style=3D"white-space:pre-wrap">	</span>(when (and=
 (&gt;=3D pos-x left) (&lt;=3D pos-x right)</div><div class=3D"gmail_defaul=
t"><span style=3D"white-space:pre-wrap">		</span>=C2=A0 =C2=A0(&gt;=3D pos-=
y top)=C2=A0 (&lt;=3D pos-y bottom))</div><div class=3D"gmail_default"><spa=
n style=3D"white-space:pre-wrap">	</span>=C2=A0 (setq in-frame frame))))</d=
iv><div class=3D"gmail_default">=C2=A0 =C2=A0 ;; If in-frame is found, find=
 which of its windows contains</div><div class=3D"gmail_default">=C2=A0 =C2=
=A0 ;; position and return that.=C2=A0 The window-at call below requires</d=
iv><div class=3D"gmail_default">=C2=A0 =C2=A0 ;; character coordinates rela=
tive to in-frame, so compute them.</div><div class=3D"gmail_default">=C2=A0=
 =C2=A0 (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))</div><di=
v class=3D"gmail_default"><span style=3D"white-space:pre-wrap">	</span>=C2=
=A0 pos-y (/ (- pos-y top) (frame-char-height in-frame))</div><div class=3D=
"gmail_default"><span style=3D"white-space:pre-wrap">	</span>=C2=A0 window =
(window-at pos-x pos-y in-frame))</div><div class=3D"gmail_default">=C2=A0 =
=C2=A0 (if (called-interactively-p &#39;interactive)</div><div class=3D"gma=
il_default"><span style=3D"white-space:pre-wrap">	</span>=C2=A0 (message &q=
uot;%s at absolute pixel position %s&quot;</div><div class=3D"gmail_default=
"><span style=3D"white-space:pre-wrap">		</span>=C2=A0 =C2=A0(or window &qu=
ot;No Emacs window&quot;) position))</div><div class=3D"gmail_default">=C2=
=A0 =C2=A0 window))</div></div></div></div></div></div></div>
</div>
</blockquote></div><br></div>

--001a113a0518154d2a055b4f8f22--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 11 Oct 2017 18:50:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 11 14:50:28 2017
Received: from localhost ([127.0.0.1]:34457 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e2M5M-0004a1-7M
	for submit <at> debbugs.gnu.org; Wed, 11 Oct 2017 14:50:28 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58818)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e2M5K-0004Zn-Bg
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 14:50:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e2M5B-00005k-Sn
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 14:50:21 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56514)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e2M5B-00005P-Jb
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 14:50:17 -0400
Received: from mail-qt0-f178.google.com ([209.85.216.178]:56301)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e2M5B-0004XK-3d
 for 28620 <at> debbugs.gnu.org; Wed, 11 Oct 2017 14:50:17 -0400
Received: by mail-qt0-f178.google.com with SMTP id x54so8173834qth.12
 for <28620 <at> debbugs.gnu.org>; Wed, 11 Oct 2017 11:50:16 -0700 (PDT)
X-Gm-Message-State: AMCzsaXl2Vof+XAN06wxQGSi8ObQXsxaU3zSbzzp5V3F/I7DtuxPU1E1
 2ez+IQ9tMSoLfdSWYKRgQIIysodHM7Jrm2ujbOo=
X-Google-Smtp-Source: AOwi7QC5n5oqbLxy6Lw/DYibWjJQspkcUbhmDMHkQwhVptCyHNLm85s1AuWNIOdklMDKFFZ8yqIclSNVLQqeM/jvEMs=
X-Received: by 10.237.59.249 with SMTP id s54mr1059338qte.34.1507747816493;
 Wed, 11 Oct 2017 11:50:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 11 Oct 2017 11:49:45 -0700 (PDT)
In-Reply-To: <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <83vajwytja.fsf@HIDDEN>
 <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@HIDDEN>
 <83poa4yqyq.fsf@HIDDEN>
 <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@HIDDEN>
 <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@HIDDEN>
 <83376qouoj.fsf@HIDDEN>
 <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 11 Oct 2017 14:49:45 -0400
X-Gmail-Original-Message-ID: <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
Message-ID: <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: Eli Zaretskii <eliz@HIDDEN>, martin rudalics <rudalics@HIDDEN>,
 Alan Third <alan@HIDDEN>, 28620 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="94eb2c0e6e320355b2055b49e551"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--94eb2c0e6e320355b2055b49e551
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <rsw@HIDDEN> wrote:

>
> =E2=80=8BMartin wrote:=E2=80=8B
>
>> Take the position of the event-end (if it's a frame) and translate it
>> into absolute screen coordinates (the Elisp manual should give you
>> enough clues to do that).  Or, try =E2=80=98mouse-absolute-pixel-positio=
n=E2=80=99 - it
>> should give you the screen position of the mouse at that time so you can
>> ignore the event completely.
>>
>> Then walk all your windows and compare that position with whatever
>> =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window.  =
If you have two
>> or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare =
the result
>> against those windows' frames.  No hands, IMHO.
>> =E2=80=8B=E2=80=8B
>>
> =E2=80=8B=E2=80=8B

=E2=80=8B  Eli wrote:
    =E2=80=8B=E2=80=8B
Why cannot you compute the frame at button release using the a
=E2=80=8B=E2=80=8B
lgorithm
         proposed by Martin, given the mouse position at button release?=E2=
=80=8B


>
>> =E2=80=8B=E2=80=8B
>>
> I w
> =E2=80=8B=E2=80=8B
> rote:
>   =E2=80=8B
> =E2=80=8B=E2=80=8B
> frame-list-z-order is Emacs 26 only; I need something that works with
> older versions.=E2=80=8B
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> I'll see if I can make this work under Emacs 26 and then we can
> contemplate a solution that would apply to earlier versions.
> =E2=80=8B=E2=80=8B
> Thanks for the reminder.  It does still seem to me that there should be a
> function that takes a mouse position and returns
> =E2=80=8B=E2=80=8B
> the top-most Emacs window that the position is in or nil.  I'll work on i=
t.
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function.  It was easier=
 than I expected thanks
to Martin's pointers.  Now how can we make this work (replacing
frame-list-z-order) for Emacs versions prior to 26?  -- Bob

(defun window-at-absolute-pixel-position (&optional position)
  "Return the top-most Emacs window at optional POSITION ((X . Y) in
pixels) or mouse position.
If POSITION is not in a window, return nil.  Considers all windows on the
the same terminal
display as the selected frame."
  (interactive)
  (setq position (or position (mouse-absolute-pixel-position)))
  (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (car position))
(pos-y (cdr position))
edges left top right bottom
frame
in-frame
window)
    ;; First find top-most frame containing position.
    (while (and (not in-frame) top-to-bottom-frames)
      (setq frame (car top-to-bottom-frames)
    top-to-bottom-frames (cdr top-to-bottom-frames))
      ;; Check that in-frame is valid with frame-live-p since under macOS
      ;; when position is outside a frame, in-frame could be invalid and
      ;; frame-visible-p would trigger an error in that case.
      (when (and (frame-live-p frame) (frame-visible-p frame))
(setq edges (frame-edges frame)
      left   (nth 0 edges)
      top    (nth 1 edges)
      right  (nth 2 edges)
      bottom (nth 3 edges))
(when (and (>=3D pos-x left) (<=3D pos-x right)
   (>=3D pos-y top)  (<=3D pos-y bottom))
  (setq in-frame frame))))
    ;; If in-frame is found, find which of its windows contains
    ;; position and return that.  The window-at call below requires
    ;; character coordinates relative to in-frame, so compute them.
    (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
  pos-y (/ (- pos-y top) (frame-char-height in-frame))
  window (window-at pos-x pos-y in-frame))
    (if (called-interactively-p 'interactive)
  (message "%s at absolute pixel position %s"
   (or window "No Emacs window") position))
    window))

--94eb2c0e6e320355b2055b49e551
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 11, 2=
017 at 1:16 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family=
:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw=
@gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:=
</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail-m_-2807733671338235013gmail-m_681535470529625443h5"><div style=
=3D"font-family:monospace,monospace"><br></div></div></div><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><div style=3D"font-family:monosp=
ace,monospace">=E2=80=8BMartin wrote:=E2=80=8B</div></div><div style=3D"fon=
t-family:monospace,monospace"><span class=3D"gmail-m_-2807733671338235013gm=
ail-m_681535470529625443m_6335701201969505853gmail-im" style=3D"font-family=
:arial,sans-serif;font-size:12.8px"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Take the position of the event-end (if it&#39;s a frame) and tra=
nslate it<br>into absolute screen coordinates (the Elisp manual should give=
 you<br>enough clues to do that).=C2=A0 Or, try =E2=80=98mouse-absolute-pix=
el-position<wbr>=E2=80=99 - it<br>should give you the screen position of th=
e mouse at that time so you can<br>ignore the event completely.<br><br>Then=
 walk all your windows and compare that position with whatever<br>=E2=80=98=
window-absolute-pixel-edges=E2=80=99 returns for that window.=C2=A0 If you =
have two<br>or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and=
 compare the result<br>against those windows&#39; frames.=C2=A0 No hands, I=
MHO.<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;d=
isplay:inline">=E2=80=8B=E2=80=8B</div></blockquote></span></div></div></di=
v></div></blockquote><div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0</div><d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace,monospace;di=
splay:inline">=E2=80=8B=C2=A0 Eli wrote:</div></div><span style=3D"font-siz=
e:12.8px"><div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace;display:inline">=C2=A0 =C2=A0 =E2=80=8B=E2=80=8B</div>Why cannot you c=
ompute the frame at button release using the a<div class=3D"gmail_default" =
style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B=
</div>lgorithm</span><br style=3D"font-size:12.8px"><div><div class=3D"gmai=
l_default" style=3D"font-family:monospace,monospace;display:inline"><span s=
tyle=3D"font-size:12.8px;font-family:arial,sans-serif">=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0proposed by Martin, given the mouse position at button releas=
e?</span>=E2=80=8B</div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><div style=3D"font-family:monospace,monospace"><span class=3D"gmail-=
m_-2807733671338235013gmail-m_681535470529625443m_6335701201969505853gmail-=
im" style=3D"font-family:arial,sans-serif;font-size:12.8px"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><span style=3D"font-size:small">=C2=A0<d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace;display=
:inline">=E2=80=8B=E2=80=8B</div></span></blockquote></span></div></div></d=
iv></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div st=
yle=3D"font-family:monospace,monospace"><span class=3D"gmail-m_-28077336713=
38235013gmail-m_681535470529625443m_6335701201969505853gmail-im" style=3D"f=
ont-family:arial,sans-serif;font-size:12.8px"><div></div><div>I w<div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline"=
>=E2=80=8B=E2=80=8B</div>rote:</div></span><div style=3D"font-size:12.8px">=
=C2=A0 =E2=80=8B<div class=3D"gmail_default" style=3D"font-family:monospace=
,monospace;display:inline">=E2=80=8B=E2=80=8B</div>frame-list-z-order is Em=
acs 26 only; I need something that works with older versions.=E2=80=8B</div=
><div style=3D"font-size:12.8px"><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">=E2=80=8B=E2=80=8B</div></div><div style=3D"fo=
nt-size:12.8px"><div class=3D"gmail_default" style=3D"font-family:monospace=
,monospace;display:inline">=E2=80=8B=E2=80=8B</div>I&#39;ll see if I can ma=
ke this work under Emacs 26 and then we can contemplate a solution that wou=
ld apply to earlier versions.</div><div style=3D"font-size:12.8px"><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inlin=
e">=E2=80=8B=E2=80=8B</div>Thanks for the reminder.=C2=A0 It does still see=
m to me that there should be a function that takes a mouse position and ret=
urns</div><div style=3D"font-size:12.8px"><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</di=
v>the top-most Emacs window that the position is in or nil.=C2=A0 I&#39;ll =
work on it.</div></div></div></div></div></blockquote><div><div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B</=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8B=E2=80=8B=E2=80=8BAnd now there is such a function.=C2=A0 It was e=
asier than I expected thanks to Martin&#39;s pointers.=C2=A0 Now how can we=
 make this work (replacing frame-list-z-order) for Emacs versions prior to =
26?=C2=A0 -- Bob</div></div><div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><div class=3D"gmail_default"><div class=3D"gm=
ail_default"><div class=3D"gmail_default"><div class=3D"gmail_default">(def=
un window-at-absolute-pixel-position (&amp;optional position)</div><div cla=
ss=3D"gmail_default">=C2=A0 &quot;Return the top-most Emacs window at optio=
nal POSITION ((X . Y) in pixels) or mouse position.</div><div class=3D"gmai=
l_default">If POSITION is not in a window, return nil.=C2=A0 Considers all =
windows on the the same terminal</div><div class=3D"gmail_default">display =
as the selected frame.&quot;</div><div class=3D"gmail_default">=C2=A0 (inte=
ractive)</div><div class=3D"gmail_default">=C2=A0 (setq position (or positi=
on (mouse-absolute-pixel-position)))</div><div class=3D"gmail_default">=C2=
=A0 (let* ((top-to-bottom-frames (frame-list-z-order))</div><div class=3D"g=
mail_default"><span style=3D"white-space:pre">	</span> (pos-x (car position=
))</div><div class=3D"gmail_default"><span style=3D"white-space:pre">	</spa=
n> (pos-y (cdr position))</div><div class=3D"gmail_default"><span style=3D"=
white-space:pre">	</span> edges left top right bottom</div><div class=3D"gm=
ail_default"><span style=3D"white-space:pre">	</span> frame</div><div class=
=3D"gmail_default"><span style=3D"white-space:pre">	</span> in-frame</div><=
div class=3D"gmail_default"><span style=3D"white-space:pre">	</span> window=
)</div><div class=3D"gmail_default">=C2=A0 =C2=A0 ;; First find top-most fr=
ame containing position.</div><div class=3D"gmail_default">=C2=A0 =C2=A0 (w=
hile (and (not in-frame) top-to-bottom-frames)</div><div class=3D"gmail_def=
ault">=C2=A0 =C2=A0 =C2=A0 (setq frame (car top-to-bottom-frames)</div><div=
 class=3D"gmail_default"><span style=3D"white-space:pre">	</span>=C2=A0 =C2=
=A0 top-to-bottom-frames (cdr top-to-bottom-frames))</div><div class=3D"gma=
il_default">=C2=A0 =C2=A0 =C2=A0 ;; Check that in-frame is valid with frame=
-live-p since under macOS</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =
=C2=A0 ;; when position is outside a frame, in-frame could be invalid and</=
div><div class=3D"gmail_default">=C2=A0 =C2=A0 =C2=A0 ;; frame-visible-p wo=
uld trigger an error in that case.</div><div class=3D"gmail_default">=C2=A0=
 =C2=A0 =C2=A0 (when (and (frame-live-p frame) (frame-visible-p frame))</di=
v><div class=3D"gmail_default"><span style=3D"white-space:pre">	</span>(set=
q edges (frame-edges frame)</div><div class=3D"gmail_default"><span style=
=3D"white-space:pre">	</span>=C2=A0 =C2=A0 =C2=A0 left=C2=A0 =C2=A0(nth 0 e=
dges)</div><div class=3D"gmail_default"><span style=3D"white-space:pre">	</=
span>=C2=A0 =C2=A0 =C2=A0 top=C2=A0 =C2=A0 (nth 1 edges)</div><div class=3D=
"gmail_default"><span style=3D"white-space:pre">	</span>=C2=A0 =C2=A0 =C2=
=A0 right=C2=A0 (nth 2 edges)</div><div class=3D"gmail_default"><span style=
=3D"white-space:pre">	</span>=C2=A0 =C2=A0 =C2=A0 bottom (nth 3 edges))</di=
v><div class=3D"gmail_default"><span style=3D"white-space:pre">	</span>(whe=
n (and (&gt;=3D pos-x left) (&lt;=3D pos-x right)</div><div class=3D"gmail_=
default"><span style=3D"white-space:pre">		</span>=C2=A0 =C2=A0(&gt;=3D pos=
-y top)=C2=A0 (&lt;=3D pos-y bottom))</div><div class=3D"gmail_default"><sp=
an style=3D"white-space:pre">	</span>=C2=A0 (setq in-frame frame))))</div><=
div class=3D"gmail_default">=C2=A0 =C2=A0 ;; If in-frame is found, find whi=
ch of its windows contains</div><div class=3D"gmail_default">=C2=A0 =C2=A0 =
;; position and return that.=C2=A0 The window-at call below requires</div><=
div class=3D"gmail_default">=C2=A0 =C2=A0 ;; character coordinates relative=
 to in-frame, so compute them.</div><div class=3D"gmail_default">=C2=A0 =C2=
=A0 (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))</div><div cl=
ass=3D"gmail_default"><span style=3D"white-space:pre">	</span>=C2=A0 pos-y =
(/ (- pos-y top) (frame-char-height in-frame))</div><div class=3D"gmail_def=
ault"><span style=3D"white-space:pre">	</span>=C2=A0 window (window-at pos-=
x pos-y in-frame))</div><div class=3D"gmail_default">=C2=A0 =C2=A0 (if (cal=
led-interactively-p &#39;interactive)</div><div class=3D"gmail_default"><sp=
an style=3D"white-space:pre">	</span>=C2=A0 (message &quot;%s at absolute p=
ixel position %s&quot;</div><div class=3D"gmail_default"><span style=3D"whi=
te-space:pre">		</span>=C2=A0 =C2=A0(or window &quot;No Emacs window&quot;)=
 position))</div><div class=3D"gmail_default">=C2=A0 =C2=A0 window))</div><=
/div></div></div></div></div></div>
</div>

--94eb2c0e6e320355b2055b49e551--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 5 Oct 2017 00:39:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 20:39:20 2017
Received: from localhost ([127.0.0.1]:49509 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzuC8-0003h1-4w
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 20:39:20 -0400
Received: from eggs.gnu.org ([208.118.235.92]:48073)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzuC6-0003gn-UL
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 20:39:19 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzuBx-0002Yw-Ct
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 20:39:13 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40127)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzuBx-0002Yo-A6
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 20:39:09 -0400
Received: from mail-qt0-f177.google.com ([209.85.216.177]:53930)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzuBx-0003oE-1J
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 20:39:09 -0400
Received: by mail-qt0-f177.google.com with SMTP id 47so22561400qts.10
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 17:39:08 -0700 (PDT)
X-Gm-Message-State: AMCzsaVjHMNxnHgaly61RHzi4EX5W4A0+OOkVeSbpNdPRte1kehbEIVc
 2TBcYtMVRqTArnurblYwMmhRAJrJyEbgc/rxRVU=
X-Google-Smtp-Source: AOwi7QBfw4XfVjN82yckSkORz3XYVZdTrdjBX+7K7mKrmaeF9WpsEP+psAm5+sSGJiPFHYFvgZefadFCbkHKyrYkj14=
X-Received: by 10.200.26.65 with SMTP id q1mr29618373qtk.186.1507163948605;
 Wed, 04 Oct 2017 17:39:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 17:38:38 -0700 (PDT)
In-Reply-To: <20171004220901.GA52814@HIDDEN>
References: <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
 <20171004185900.GA52514@HIDDEN>
 <CA+OMD9hB+jQysWDOwGfLs+AY=8o5Ubj=Dmrtfo2BXs2mnPBxdA@HIDDEN>
 <20171004220901.GA52814@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 4 Oct 2017 20:38:38 -0400
X-Gmail-Original-Message-ID: <CA+OMD9ityLppcuLXvsHire7TAth5z2HXpYPySoX+qbiybY5zKA@HIDDEN>
Message-ID: <CA+OMD9ityLppcuLXvsHire7TAth5z2HXpYPySoX+qbiybY5zKA@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="f403045d6da0c6666b055ac1f3c8"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--f403045d6da0c6666b055ac1f3c8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 4, 2017 at 6:09 PM, Alan Third <alan@HIDDEN> wrote:

>
> Yes. You can=E2=80=99t modify emacsframe because it=E2=80=99s an instance=
 variable.
> You=E2=80=99ll need to modify whatever is using it to set the frame in th=
e
> emacs event.
>
> So, assuming the code you=E2=80=99re modifying is calling EV_TRAILER, for=
 now,
> replace the call to EV_TRAILER with it=E2=80=99s contents:
>
>     XSETFRAME (emacs_event->frame_or_window, emacsframe);
>     EV_TRAILER2 (e);
>
> and work from there.
>

=E2=80=8BStill doesn't seem to work if that code is used at the end of mous=
eDown
(called by mouseUp).
Could you test any of your ideas?  It would probably speed the process up
if you have a bit of time.

Bob

--f403045d6da0c6666b055ac1f3c8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 4, 20=
17 at 6:09 PM, Alan Third </span><span dir=3D"ltr" style=3D"font-family:ari=
al,sans-serif">&lt;<a href=3D"mailto:alan@HIDDEN" target=3D"_blank">ala=
n@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wr=
ote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D""><br>
</span>Yes. You can=E2=80=99t modify emacsframe because it=E2=80=99s an ins=
tance variable.<br>
You=E2=80=99ll need to modify whatever is using it to set the frame in the<=
br>
emacs event.<br>
<br>
So, assuming the code you=E2=80=99re modifying is calling EV_TRAILER, for n=
ow,<br>
replace the call to EV_TRAILER with it=E2=80=99s contents:<br>
<br>
=C2=A0 =C2=A0 XSETFRAME (emacs_event-&gt;frame_or_window, emacsframe);<br>
=C2=A0 =C2=A0 EV_TRAILER2 (e);<br>
<br>
and work from there.<br></blockquote><div><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace">=E2=80=8BStill doesn&#39;t =
seem to work if that code is used at the end of mouseDown (called by mouseU=
p).</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">Could you test any of your ideas?=C2=A0 It would probably speed the pr=
ocess up if you have a bit of time.</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace">Bob</div></div></div></div>

--f403045d6da0c6666b055ac1f3c8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 22:09:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 18:09:14 2017
Received: from localhost ([127.0.0.1]:49436 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzrqs-0008OG-1J
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 18:09:14 -0400
Received: from mail-wm0-f53.google.com ([74.125.82.53]:43154)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <athird@HIDDEN>) id 1dzrqo-0008Nz-LL
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 18:09:13 -0400
Received: by mail-wm0-f53.google.com with SMTP id m72so15835362wmc.0
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 15:09:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20161025;
 h=sender:date:from:to:cc:subject:message-id:references:mime-version
 :content-disposition:content-transfer-encoding:in-reply-to
 :user-agent; bh=AhOMM8hRJFDQdk5UfRUrCwSUfLZxj6dCQv0QEoOvt0A=;
 b=dSQdjWqno6igUPrY2mbPIsF6yUihjKfmJSXohwUZ4Fi1YZwbZrhQBu6P0EPq6tCG+5
 LZutIvt+PB6sKTllHFuTlKcIm331IuE3evCWZz6nC87roFWmoCIEAO8Zyshry2AJAscQ
 0K/7z2Sn0DlFbGaoKOglvtUC5B5oaNFtr+Cgzja4wMh/KinrZrzTHJuX7oo/tOuqFfhe
 UY+WPzGvKmYoSv+xHfEFKCjquy10Vnui5LAqCph2xbZ9k+liAzR6mitZmRLND8Vo0SZd
 S1d59H1y31h0ulDjHK3jyYa1ZphKRZ9Yji66LP/f/rB/IEQvBKSb7jnv53p8IofjupRA
 fQ5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
 :references:mime-version:content-disposition
 :content-transfer-encoding:in-reply-to:user-agent;
 bh=AhOMM8hRJFDQdk5UfRUrCwSUfLZxj6dCQv0QEoOvt0A=;
 b=n8qr5iGcOpaFWbjZwtAfoIz18cBIaSC7TCrOjha2rrr9X9KwB90HZywcOFtLvdkwCM
 6bxaf3dCIAnpzjF12PZsPCAv1GXhc41iZtYFVYVAB6gmvH26+grkyaPy9vnt21YdQT+A
 dqFEyER8BJKnPimWcwlG4Jf8yp8xHCA6HGZlv+Nu+iMg2j4WCj37hQQDeqovOVLcEmA/
 QJ0wMdGlymA20XOYYEu9AwGwG06+S5l556WkVvkExiSdahatDPstk2c6gRvmqgaAM9lL
 3eaykQc40BpIghEUYqpqdzuY6DPg2FFyIjc8ugVQpc1NF8XKCGWV7gJy4KWN7ds3HVbW
 nHtA==
X-Gm-Message-State: AMCzsaVzWD5gIafZHV4+9dvJV6mtL36KizAHIpChAHS4Pk2sHKu8wM8n
 xBSukyypP1/ytGSqo40ohEo=
X-Google-Smtp-Source: AOwi7QBeqamZndyxfI8F2iDK2HIg+Eyt78SHssaylToLKhP8bYOdnoxkMxVQ+FqySnN1dT/K/rqs8Q==
X-Received: by 10.28.208.129 with SMTP id h123mr9611794wmg.25.1507154944915;
 Wed, 04 Oct 2017 15:09:04 -0700 (PDT)
Received: from breton.holly.idiocy.org
 (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org.
 [2001:8b0:3f8:8129:ad89:e054:5c6:3eca])
 by smtp.gmail.com with ESMTPSA id 193sm13310108wmh.47.2017.10.04.15.09.03
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Oct 2017 15:09:03 -0700 (PDT)
Date: Wed, 4 Oct 2017 23:09:01 +0100
From: Alan Third <alan@HIDDEN>
To: rswgnu@HIDDEN
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag
 event records wrong release window
Message-ID: <20171004220901.GA52814@HIDDEN>
References: <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
 <20171004185900.GA52514@HIDDEN>
 <CA+OMD9hB+jQysWDOwGfLs+AY=8o5Ubj=Dmrtfo2BXs2mnPBxdA@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+OMD9hB+jQysWDOwGfLs+AY=8o5Ubj=Dmrtfo2BXs2mnPBxdA@HIDDEN>
User-Agent: Mutt/1.9.0 (2017-09-02)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On Wed, Oct 04, 2017 at 04:07:56PM -0400, Robert Weiner wrote:
> On Wed, Oct 4, 2017 at 2:59 PM, Alan Third <alan@HIDDEN> wrote:
> 
> >
> > It looks like there’s maybe a neater way to get the current frame
> > under the mouse...
> >
> >     Lisp_Object frame = Qnil;
> >     NSWindow *w = [NSApp windowWithWindowNumber:
> >                          [NSWindow windowNumberAtPoint:[NSEvent
> > mouseLocation]
> >                            belowWindowWithWindowNumber:0]];
> >     if (w != nil)
> >       XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe);
> >
> >
> The ​mouseDown​ function (called by the various mouseUp functions) uses
> `emacsframe' to set the appropriate frame.
> How does the above modify emacsframe?  Doesn't XSETFRAME just set the value
> of the local `frame'?

Yes. You can’t modify emacsframe because it’s an instance variable.
You’ll need to modify whatever is using it to set the frame in the
emacs event.

So, assuming the code you’re modifying is calling EV_TRAILER, for now,
replace the call to EV_TRAILER with it’s contents:

    XSETFRAME (emacs_event->frame_or_window, emacsframe);
    EV_TRAILER2 (e);

and work from there.

-- 
Alan Third




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 20:12:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 16:12:26 2017
Received: from localhost ([127.0.0.1]:49278 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzq1p-0005SW-UR
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:12:26 -0400
Received: from eggs.gnu.org ([208.118.235.92]:42282)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzq1n-0005SH-Us
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:12:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzq1f-00079Y-NW
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:12:18 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36470)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzq1f-00079B-KM
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:12:15 -0400
Received: from mail-qt0-f170.google.com ([209.85.216.170]:45621)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzq1f-0008Jh-6E
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:12:15 -0400
Received: by mail-qt0-f170.google.com with SMTP id k1so10564423qti.2
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 13:12:15 -0700 (PDT)
X-Gm-Message-State: AMCzsaUzBwX3cjAs6GxQFLkMjaFJlwXhL8UV9J/opVdKmAcRmOep5tv4
 q9Rrt3u4AwRRufFgKQy0pbd6iT6tZUmZwYE37pM=
X-Google-Smtp-Source: AOwi7QBnaDobC9TdHzJQoIuwAi1kIMhiJDoBHOWRiK+jdZAVB7v4UZwuJK9LzNBexVQmGSnCXx1vMqwU4Vvzxx7tzyA=
X-Received: by 10.200.26.65 with SMTP id q1mr28751245qtk.186.1507147934772;
 Wed, 04 Oct 2017 13:12:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 13:11:44 -0700 (PDT)
In-Reply-To: <CA+OMD9hH7DXgte_uXmOJCz=ToTPaSe_P4EvWHkUXrskRJkhpzg@HIDDEN>
References: <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
 <20171004185900.GA52514@HIDDEN>
 <CA+OMD9hH7DXgte_uXmOJCz=ToTPaSe_P4EvWHkUXrskRJkhpzg@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 4 Oct 2017 16:11:44 -0400
X-Gmail-Original-Message-ID: <CA+OMD9iNsGPMM2xwcKDf=4b856Nm9QcuKF0cW1M7jptSK93Btg@HIDDEN>
Message-ID: <CA+OMD9iNsGPMM2xwcKDf=4b856Nm9QcuKF0cW1M7jptSK93Btg@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="f403045d6da046b1a2055abe3998"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--f403045d6da046b1a2055abe3998
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 4, 2017 at 3:30 PM, Robert Weiner <rsw@HIDDEN> wrote:

> Hi Alan:
>
>>
>> =E2=80=8B=E2=80=8B
>> It looks like there=E2=80=99s maybe a neater way to get the current fram=
e
>> =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=8BAs is, this didn't seem to have any effect.

Bob
=E2=80=8B

--f403045d6da046b1a2055abe3998
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 4, 20=
17 at 3:30 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family:=
arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw@=
gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:<=
/span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family:monosp=
ace,monospace">Hi Alan:</div><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>It looks like there=E2=80=99s maybe a neater way to get the cur=
rent frame<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>under the mouse...<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil;<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=C2=A0 =C2=A0 NSWindow *w =3D [NSApp windowWithWindowNumber:<br=
>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=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 windowNumberAtPoint:[NSEvent mouseLoca=
tion]<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=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=A0belowWindowWithWindowNumber:<wbr>0]];<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=C2=A0 =C2=A0 if (w !=3D nil)<br>
<div style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, ((EmacsView *)[w delegat=
e])-&gt;emacsframe);<br></blockquote></span></div></div></div></blockquote>=
<div><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace">=E2=80=8BAs is, this didn&#39;t seem to have any effect.</div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></=
div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
Bob</div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">=E2=80=8B</div></div></div></div>

--f403045d6da046b1a2055abe3998--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 20:08:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 16:08:38 2017
Received: from localhost ([127.0.0.1]:49274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzpyA-0005MI-B2
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:08:38 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41340)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzpy8-0005M4-B7
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:08:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzpy0-0003VV-2J
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:08:31 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36298)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzpxz-0003VN-Uo
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:08:27 -0400
Received: from mail-qt0-f177.google.com ([209.85.216.177]:53991)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzpxz-0007wV-LT
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 16:08:27 -0400
Received: by mail-qt0-f177.google.com with SMTP id 47so21503369qts.10
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 13:08:27 -0700 (PDT)
X-Gm-Message-State: AMCzsaUd4VrdhB2NjyQ58i+9YXiwqsQybtFElJ3oQnvchRfOJy/akI+B
 GNMDLoIfHteIG6F8iUTXexnYRoP1+FT6f89R2hs=
X-Google-Smtp-Source: AOwi7QBzueAXurmG2KGvfM+05u0ftX/jxndcMU6+4urbZLiSyYSgunoMUO3+qjEG5pSgeTd+Zg7yWHEY+BYGFDmZcXU=
X-Received: by 10.200.57.29 with SMTP id s29mr31435484qtb.309.1507147707257;
 Wed, 04 Oct 2017 13:08:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 13:07:56 -0700 (PDT)
In-Reply-To: <20171004185900.GA52514@HIDDEN>
References: <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
 <20171004185900.GA52514@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 4 Oct 2017 16:07:56 -0400
X-Gmail-Original-Message-ID: <CA+OMD9hB+jQysWDOwGfLs+AY=8o5Ubj=Dmrtfo2BXs2mnPBxdA@HIDDEN>
Message-ID: <CA+OMD9hB+jQysWDOwGfLs+AY=8o5Ubj=Dmrtfo2BXs2mnPBxdA@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11418c4eb72a06055abe2b17"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a11418c4eb72a06055abe2b17
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 4, 2017 at 2:59 PM, Alan Third <alan@HIDDEN> wrote:

>
> It looks like there=E2=80=99s maybe a neater way to get the current frame
> under the mouse...
>
>     Lisp_Object frame =3D Qnil;
>     NSWindow *w =3D [NSApp windowWithWindowNumber:
>                          [NSWindow windowNumberAtPoint:[NSEvent
> mouseLocation]
>                            belowWindowWithWindowNumber:0]];
>     if (w !=3D nil)
>       XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe);
>
>
The =E2=80=8BmouseDown=E2=80=8B function (called by the various mouseUp fun=
ctions) uses
`emacsframe' to set the appropriate frame.
How does the above modify emacsframe?  Doesn't XSETFRAME just set the value
of the local `frame'?

Bob

--001a11418c4eb72a06055abe2b17
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 4, 20=
17 at 2:59 PM, Alan Third </span><span dir=3D"ltr" style=3D"font-family:ari=
al,sans-serif">&lt;<a href=3D"mailto:alan@HIDDEN" target=3D"_blank">ala=
n@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wr=
ote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
It looks like there=E2=80=99s maybe a neater way to get the current frame<b=
r>
under the mouse...<br>
<br>
=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil;<br>
=C2=A0 =C2=A0 NSWindow *w =3D [NSApp windowWithWindowNumber:<br>
=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 windowNumberAtPoint:[NSEvent mouseLocation]<br>
=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=A0belowWindowWithWindowNumber:0]<wbr>];<br>
=C2=A0 =C2=A0 if (w !=3D nil)<br>
=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, ((EmacsView *)[w delegate])-&gt;emac=
sframe);<br>
<br></blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-=
family:monospace,monospace">The =E2=80=8BmouseDown=E2=80=8B function (calle=
d by the various mouseUp functions) uses `emacsframe&#39; to set the approp=
riate frame.</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace">How does the above modify emacsframe?=C2=A0 Doesn&#39;t XSETF=
RAME just set the value of the local `frame&#39;?</div><div class=3D"gmail_=
default" style=3D"font-family:monospace,monospace"><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">Bob</div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div></d=
iv><br></div></div>

--001a11418c4eb72a06055abe2b17--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 19:31:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 15:31:29 2017
Received: from localhost ([127.0.0.1]:49213 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzpOC-0004L5-Fh
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 15:31:29 -0400
Received: from eggs.gnu.org ([208.118.235.92]:59482)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzpO9-0004Ks-FS
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 15:31:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzpO0-00063K-Qh
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 15:31:20 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35590)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzpO0-000639-N9
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400
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 <rsw@HIDDEN>) id 1dzpO0-00087K-Bc
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 15:31:16 -0400
Received: by mail-qk0-f170.google.com with SMTP id n5so10352680qke.11
 for <28620 <at> 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)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 12:30:45 -0700 (PDT)
In-Reply-To: <20171004185900.GA52514@HIDDEN>
References: <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
 <20171004185900.GA52514@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 4 Oct 2017 15:30:45 -0400
X-Gmail-Original-Message-ID: <CA+OMD9hH7DXgte_uXmOJCz=ToTPaSe_P4EvWHkUXrskRJkhpzg@HIDDEN>
Message-ID: <CA+OMD9hH7DXgte_uXmOJCz=ToTPaSe_P4EvWHkUXrskRJkhpzg@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="001a113fe9f0b52294055abda692"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.5 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

--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 <alan@HIDDEN> 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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">Hi Alan:</div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">Thanks for your thoughts on this.</div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Oct 4, 2017 at 2=
:59 PM, Alan Third <span dir=3D"ltr">&lt;<a href=3D"mailto:alan@HIDDEN"=
 target=3D"_blank">alan@HIDDEN</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><span class=3D"">On Wed, Oct 04, 2017 at 01:26:18PM -0400, =
Robert Weiner wrote:<br><br>
&gt; =E2=80=8BSo how is it that Emacs processes a drag event when the mouse=
 button is<br>
&gt; released in the new frame if it never sees the mouseUp (drag release)<=
br>
&gt; event?=E2=80=8B=C2=A0 If I drag across frames, on mouseUp, the key bin=
ding associated<br>
&gt; with mouseUp (mouse-1 as opposed to down-mouse-1 is run).<br>
<br>
</span>The NSEvent is delivered to the EmacsView belonging to the frame whe=
re<br>
the drag was initiated. I don=E2=80=99t think there=E2=80=99s anything we c=
an do to<br>
change that.<br></blockquote><div><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:monospace,monospace">=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?</div><div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace">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?</div><div =
class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div=
><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">If =
so, why can&#39;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?</div><div class=3D"gmail_default" style=3D"font-fami=
ly:monospace,monospace"><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<span class=3D""><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; The mouse wheel code is also h=
andled in <div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace;display:inline">=E2=80=8B=E2=80=8B</div>mouseDown, the difference is<b=
r>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; that macOS always sends the mo=
use whe<div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e;display:inline">=E2=80=8B=E2=80=8B</div>el event to the emacs frame under=
<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; the mouse pointer, whereas the=
 mouse cli<div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace;display:inline">=E2=80=8B=E2=80=8B</div>ck event is not sent when the<=
br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; frame is not already key (i.e.=
 selected).<div class=3D"gmail_default" style=3D"font-family:monospace,mono=
space;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline"></div></span></blockquote><div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BOk, I un=
derstand that now.=E2=80=8B</div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">=E2=80=8B=E2=80=8B=E2=80=8B</div></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><span class=3D""><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B</div>&gt; =E2=80=8BCan you show some sample code that would make mac=
OS send the mouse drag<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; release event to the frame under th=
e mouse pointer just as the scroll wheel<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
> <div class=3D"gmail_default" style=3D"font-family:monospace,monospace;dis=
play:inline">=E2=80=8B=E2=80=8B</div>c<div class=3D"gmail_default" style=3D=
"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>o<=
div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa=
y:inline">=E2=80=8B=E2=80=8B</div>d<div class=3D"gmail_default" style=3D"fo=
nt-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>e<div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:i=
nline">=E2=80=8B=E2=80=8B</div> <div class=3D"gmail_default" style=3D"font-=
family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>d<div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inli=
ne">=E2=80=8B=E2=80=8B</div>o<div class=3D"gmail_default" style=3D"font-fam=
ily:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>e<div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline"=
>=E2=80=8B=E2=80=8B</div>s<div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>.<div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace;display:inline">=
=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
</span><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e;display:inline">=E2=80=8B=E2=80=8B</div>I don=E2=80=99t believe it=E2=80=
=99s possible. As I described before we=E2=80=99d have to do<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>something like:<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 [...] get a list of NSWind=
ows, iterate over them to find out which<br>
<span class=3D""><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 one the m=
ouse pointer is over, convert that NSWindow back to an Emacs<br>
</span><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 frame, and [return =
it].<br>
<span class=3D""><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; AFAICT Emacs does the right th=
ing here, exactly the same thing as<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; every other macOS app.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt;<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; =E2=80=8BAs Eli noted, this does no=
t happen under MS Windows.</span></blockquote><div><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">=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&#39;ll have to talk to Eli about=
 this.</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace">=E2=80=8B</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><s=
pan class=3D""><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace;display:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 I want to have<div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace;display:i=
nline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline=
">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=
=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; behavior that allows for drags acro=
ss frames.=C2=A0 The present code does not,<div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</d=
iv><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; so whether it is consistent with Ma=
c UI guidelines, it is not useful for<div class=3D"gmail_default" style=3D"=
font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br=
>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; that purpose.=C2=A0 I would like yo=
ur help in figuring out how to enable su<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
>ch<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; behavior as you seem to understand =
the macOS event flow well.<div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
</span><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e;display:inline">=E2=80=8B=E2=80=8B</div>But which behaviour? I can=E2=80=
=99t work out exactly what we=E2=80=99re talking ab<div class=3D"gmail_defa=
ult" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div>out<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>here. Are you trying to get cross=E2=80=
=90frame dragging working</blockquote><div><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace">=E2=80=8BYes.=E2=80=8B</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class=3D"gm=
ail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div>or <div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>are you<div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace;display:inline=
">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace;display:inline">=E2=
=80=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail=
_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=
=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace;display:inline">=E2=80=8B=E2=80=8B</div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=
=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>genuinely concerned that Emacs doesn=E2=
=80=99t receive a click event when the<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>frame is selected using the mouse? These=
 seem like two different<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>things to me.<br></blockquote><div><br><=
/div><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"=
>=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.</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<span class=3D""><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; There=E2=80=99s nothing fancy =
here, emacsframe is an instance variable<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; &gt; associated with the EmacsView =
that macOS sends the mouse <div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div>event to.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
> =E2=80=8BSo show me how and where I could set that variable to the frame =
of the<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
> mouse position at the point of mouseUp=E2=80=8B and I will test it and le=
t people<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt;<div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
> know if it works.<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
</span>F<div class=3D"gmail_default" style=3D"font-family:monospace,monospa=
ce;display:inline">=E2=80=8B=E2=80=8B</div>ns_frame_list_z_order in nsfns.m=
 does some of what=E2=80=99s described<br>
a<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;disp=
lay:inline">=E2=80=8B=E2=80=8B</div>bove... But...<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>It looks like there=E2=80=99s maybe a ne=
ater way to get the current frame<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>under the mouse...<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 Lisp_Object frame =3D Qnil=
;<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 NSWindow *w =3D [NSApp win=
dowWithWindowNumber:<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=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]<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=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]<wbr>];<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 if (w !=3D nil)<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 =C2=A0 XSETFRAME (frame, (=
(EmacsView *)[w delegate])-&gt;emacsframe);<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>I=E2=80=99ve not tested this, so it may =
not work at all. Note that [NSEvent<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>mouseLocation] returns an NSPoint indica=
ting where the mouse is *right<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>now*. It would probably be more sensible=
 to use any co=E2=80=90ordinates<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>provided by the event itself.<br></block=
quote><div><br></div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace">If the coordinates represent the location of the mouseUp e=
vent rather than mouseDown (of which I&#39;m not sure), then why couldn&#39=
;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.</div><div class=
=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace">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.</div><div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">Bo=
b</div></div></div></div>

--001a113fe9f0b52294055abda692--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 18:59:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 14:59:12 2017
Received: from localhost ([127.0.0.1]:49205 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzosx-0003YY-OZ
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 14:59:12 -0400
Received: from mail-wm0-f53.google.com ([74.125.82.53]:57089)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <athird@HIDDEN>) id 1dzosv-0003YL-IM
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 14:59:10 -0400
Received: by mail-wm0-f53.google.com with SMTP id l68so11216829wmd.5
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 11:59:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20161025;
 h=sender:date:from:to:cc:subject:message-id:references:mime-version
 :content-disposition:content-transfer-encoding:in-reply-to
 :user-agent; bh=BDM5OzNuT5AKydOWrVaGBDzgpunHeB65zmc7uSIYe74=;
 b=JbCyFW53s+JmMVMAuWuOeM80QLpBa5J48ZIWC/3G7WdztAHcXPjn7/JD9wxta1Olsx
 AAOF5AOaFkM30lQzhuw4853kfvGVoYIGrqDsnhqU/3qOlpE9K5zlNptoP2AtjixXg4S/
 rKCUfEae0j/Q6j7VuW+1Xf2X/3cDqMPb0FcBW5W+e/eK6YTvvehjmFbOcY2G/jtSD2y7
 qw4chOcOP5LnxfkICLEsftmnsiRnQV7XelXpVODWA9wpRPDAWLAvq6EJUyeVvLZcVcqf
 szm9YFlmbhsZMwMeRK3QX3SmT7aZHGiOWKUVvLauDWz+wOFqzizqFc3LFZcaK9cdxcfd
 1nog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
 :references:mime-version:content-disposition
 :content-transfer-encoding:in-reply-to:user-agent;
 bh=BDM5OzNuT5AKydOWrVaGBDzgpunHeB65zmc7uSIYe74=;
 b=sWhmB4NmtBidyjY7oupnV4Ekmv94TctwPMNWWUF6Tx3ZOn1BAPS96eeziZizIkwcVS
 38e+sp/bySfyJs6Azc30TT38VY9nx0NS8ZQn1nwR0YKcOBL0JJ0WSNIkbCHJMVHdrA2L
 +HM35Qwg76ATgdcpTKVlgcFUoKP/YaOr/22/2Bvs6Dj69RxDnUjPmfB182/wuHWlsxZu
 WTRQlCz0J+f67rBNMj65sLR+jJM0uRZ3gucJZpXysgXBmwVyKxYxxrlbVWFowB/WVu99
 EzIxgLO+mq9ze/Qf/rheQgfdlw61cYSILi/6dxdCvK9smR5JOefXR3pxzRYn5HbgGW9Q
 rpoA==
X-Gm-Message-State: AHPjjUjAkDLoVraY6JvihsaSQNg5FIyZrJG7ViAe+P1SjuAb/nr9K/UD
 uzDl7VqXd/q5FeuG357DLXg=
X-Google-Smtp-Source: AOwi7QBIeDl7NnP7zlsYueGvIIzb2+cEhZ3DhxlSuo4U3XrXscTjJU/QZ4b/zTHzlgB1VxqSmN4dsg==
X-Received: by 10.28.107.17 with SMTP id g17mr18354981wmc.58.1507143543396;
 Wed, 04 Oct 2017 11:59:03 -0700 (PDT)
Received: from breton.holly.idiocy.org
 (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org.
 [2001:8b0:3f8:8129:ad89:e054:5c6:3eca])
 by smtp.gmail.com with ESMTPSA id b11sm151549wrd.91.2017.10.04.11.59.02
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Oct 2017 11:59:02 -0700 (PDT)
Date: Wed, 4 Oct 2017 19:59:00 +0100
From: Alan Third <alan@HIDDEN>
To: rswgnu@HIDDEN
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag
 event records wrong release window
Message-ID: <20171004185900.GA52514@HIDDEN>
References: <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
 <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
User-Agent: Mutt/1.9.0 (2017-09-02)
X-Spam-Score: 0.2 (/)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

On Wed, Oct 04, 2017 at 01:26:18PM -0400, Robert Weiner wrote:
> On Wed, Oct 4, 2017 at 12:30 PM, Alan Third <alan@HIDDEN> wrote:
> 
> > On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote:
> > > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@HIDDEN> wrote:
> > > > As far as I can tell ns_mouse_position returns the frame stored in
> > > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown,
> > however:
> > > >
> > > >     If the user clicks a view that isn’t in the key window, by default
> > > >     the window is brought forward and made key, but the mouse event is
> > > >     not dispatched.
> > > >
> > >
> > > ​What does "the mouse event is not dispatched mean"?  Does it mean Emacs
> > > never sees the event?  Maybe Emacs sees only that the window has been
> > > selected by the window manager and based on that switches to the selected
> > > window of the frame?
> >
> > Precisely that.
> >
> 
> ​So 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?​  If I drag across frames, on mouseUp, the key binding associated
> 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’t think there’s anything we can do to
change that.

> > The mouse wheel code is also handled in mouseDown, the difference is
> > that macOS always sends the mouse wheel event to the emacs frame under
> > the mouse pointer, whereas the mouse click event is not sent when the
> > frame is not already key (i.e. selected).
> >
> 
> ​Can you show some sample code that would make macOS send the mouse drag
> release event to the frame under the mouse pointer just as the scroll wheel
> code does.  I have looked at this mouseUp code in nsterm.m but cannot get
> it to do this.  I have managed to inject a focus in event to the mouseUp​
> function and make its event frame the key frame (selected frame) but its
> event frame is the wrong one (it always has the frame of the mouseDown
> event).

I don’t believe it’s possible. As I described before we’d have to do
something like:

    [...] get a list of NSWindows, iterate over them to find out which
    one the mouse pointer is over, convert that NSWindow back to an Emacs
    frame, and [return it].

> > AFAICT Emacs does the right thing here, exactly the same thing as
> > every other macOS app.
> >
> ​As Eli noted, this does not happen under MS Windows.  I want to have
> behavior that allows for drags across frames.  The present code does not,
> so whether it is consistent with Mac UI guidelines, it is not useful for
> that purpose.  I would like your help in figuring out how to enable such
> behavior as you seem to understand the macOS event flow well.

But which behaviour? I can’t work out exactly what we’re talking about
here. Are you trying to get cross‐frame dragging working or are you
genuinely concerned that Emacs doesn’t receive a click event when the
frame is selected using the mouse? These seem like two different
things to me.

> > There’s nothing fancy here, emacsframe is an instance variable
> > associated with the EmacsView that macOS sends the mouse event to.
> 
> 
> ​So show me how and where I could set that variable to the frame of the
> mouse position at the point of mouseUp​ and I will test it and let people
> know if it works.

Fns_frame_list_z_order in nsfns.m does some of what’s described
above... But...

It looks like there’s maybe a neater way to get the current frame
under the mouse...

    Lisp_Object frame = Qnil;
    NSWindow *w = [NSApp windowWithWindowNumber:
                         [NSWindow windowNumberAtPoint:[NSEvent mouseLocation]
                           belowWindowWithWindowNumber:0]];
    if (w != nil)
      XSETFRAME (frame, ((EmacsView *)[w delegate])->emacsframe);

I’ve not tested this, so it may not work at all. Note that [NSEvent
mouseLocation] returns an NSPoint indicating where the mouse is *right
now*. It would probably be more sensible to use any co‐ordinates
provided by the event itself.
-- 
Alan Third




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 17:27:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 13:27:01 2017
Received: from localhost ([127.0.0.1]:49159 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dznRl-0007uP-1x
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 13:27:01 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54081)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dznRi-0007uA-FS
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 13:26:58 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dznRa-0005Wk-0p
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 13:26:53 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33008)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dznRZ-0005Wc-Sz
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400
Received: from mail-qt0-f178.google.com ([209.85.216.178]:53721)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dznRZ-0006LD-Cg
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 13:26:49 -0400
Received: by mail-qt0-f178.google.com with SMTP id 47so20585291qts.10
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 10:26:49 -0700 (PDT)
X-Gm-Message-State: AMCzsaVnoHrpegU4jC7wo6gEwiQRbxWlF2AmJJVL6ksGgohKNcQpzpz+
 MLgT5MyLlaMrc6Yjv3rP6v7an7AlhoWye9XQ0Jw=
X-Google-Smtp-Source: AOwi7QCicMr+ISpzwx0y5z4V6BStQUDvr6lhRiWapCstPTKQLNibE2PB53zKKtAzfNa+UE9V60lkoGBDnN1Ll9I0zEQ=
X-Received: by 10.200.44.118 with SMTP id e51mr12545752qta.171.1507138008873; 
 Wed, 04 Oct 2017 10:26:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Wed, 4 Oct 2017 10:26:18 -0700 (PDT)
In-Reply-To: <20171004163048.GA52414@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
 <20171004163048.GA52414@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 4 Oct 2017 13:26:18 -0400
X-Gmail-Original-Message-ID: <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
Message-ID: <CA+OMD9jXzeenG10d28BfkJy_DgF=1aQUj7FdHOBL4d9BhTy7kA@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11405bcea581eb055abbe968"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.5 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

--001a11405bcea581eb055abbe968
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 4, 2017 at 12:30 PM, Alan Third <alan@HIDDEN> wrote:

> On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote:
> > On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@HIDDEN> wrote:
> > > As far as I can tell ns_mouse_position returns the frame stored in
> > > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown,
> however:
> > >
> > >     If the user clicks a view that isn=E2=80=99t in the key window, b=
y default
> > >     the window is brought forward and made key, but the mouse event i=
s
> > >     not dispatched.
> > >
> >
> > =E2=80=8BWhat does "the mouse event is not dispatched mean"?  Does it m=
ean Emacs
> > never sees the event?  Maybe Emacs sees only that the window has been
> > selected by the window manager and based on that switches to the select=
ed
> > window of the frame?
>
> Precisely that.
>

=E2=80=8BSo how is it that Emacs processes a drag event when the mouse butt=
on 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 assoc=
iated
with mouseUp (mouse-1 as opposed to down-mouse-1 is run).

=E2=80=8B=E2=80=8B
>
> > =E2=80=8BThe mouse wheel code manages to scroll the proper window that =
the mouse
> is
> > over, even across overlapping frames where the window the mouse is over
> is
> > in a frame that is partially behind another frame.  And this happens
> > without without any click events.  This could be utilized in the click
> > event code to get this right somehow.
>
> The mouse wheel code is also handled in mouseDown, the difference is
> that macOS always sends the mouse wheel event to the emacs frame under
> the mouse pointer, whereas the mouse click event is not sent when the
> frame is not already key (i.e. selected).
>

=E2=80=8BCan you show some sample code that would make macOS send the mouse=
 drag
release event to the frame under the mouse pointer just as the scroll wheel
code does.  I have looked at this mouseUp code in nsterm.m but cannot get
it to do this.  I have managed to inject a focus in event to the mouseUp=E2=
=80=8B
function and make its event frame the key frame (selected frame) but its
event frame is the wrong one (it always has the frame of the mouseDown
event).

=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.  I want to ha=
ve
behavior that allows for drags across frames.  The present code does not,
so whether it is consistent with Mac UI guidelines, it is not useful for
that purpose.  I would like your help in figuring out how to enable such
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=E2=80=8B
> > It looks like the EV_TRAILER macro call at the end of the nsterm.c
> =E2=80=8B=E2=80=8B
> > mouseDown function (which is also called by mouseUp) sets the frame use=
d
> =E2=80=8B=E2=80=8B
> > for mouse button down, up and scroll wheel events from the variable
> =E2=80=8B=E2=80=8B
> > emacsframe.  Somehow the value of emacsframe must be set differently fo=
r
> =E2=80=8B=E2=80=8B
> > mouse up events than it is for mouse wheel events since they end up wit=
h
> =E2=80=8B=E2=80=8B
> > different frames for the same mouse positions.
>
=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
> associated with the EmacsView that macOS sends the mouse event to.


=E2=80=8BSo show me how and where I could set that variable to the frame of=
 the
mouse position at the point of mouseUp=E2=80=8B and I will test it and let =
people
know if it works.

Thanks,

Bob

--001a11405bcea581eb055abbe968
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Wed, Oct 4, 20=
17 at 12:30 PM, Alan Third </span><span dir=3D"ltr" style=3D"font-family:ar=
ial,sans-serif">&lt;<a href=3D"mailto:alan@HIDDEN" target=3D"_blank">al=
an@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> w=
rote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D"">On Tue, Oct 03, 2017 at 08=
:15:53PM -0400, Robert Weiner wrote:<br>
&gt; On Tue, Oct 3, 2017 at 6:40 PM, Alan Third &lt;<a href=3D"mailto:alan@=
idiocy.org">alan@HIDDEN</a>&gt; wrote:<br>
</span><span class=3D"">&gt; &gt; As far as I can tell ns_mouse_position re=
turns the frame stored in<br>
&gt; &gt; dpyinfo-&gt;last_mouse_frame, which is set by EmacsView::mouseDow=
n, however:<br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0If the user clicks a view that isn=E2=80=99t i=
n the key window, by default<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0the window is brought forward and made key, bu=
t the mouse event is<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0not dispatched.<br>
&gt; &gt;<br>
&gt;<br>
&gt; =E2=80=8BWhat does &quot;the mouse event is not dispatched mean&quot;?=
=C2=A0 Does it mean Emacs<br>
&gt; never sees the event?=C2=A0 Maybe Emacs sees only that the window has =
been<br>
&gt; selected by the window manager and based on that switches to the selec=
ted<br>
&gt; window of the frame?<br>
<br>
</span>Precisely that.<br></blockquote><div><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">=E2=80=8BSo how is it tha=
t 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=C2=A0 If=
 I drag across frames, on mouseUp, the key binding associated with mouseUp =
(mouse-1 as opposed to down-mouse-1 is run).</div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace,monospace"><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D""><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
&gt; =E2=80=8BThe mouse wheel code manages to scroll the proper window that=
 the mouse is<br>
&gt; over, even across overlapping frames where the window the mouse is ove=
r is<br>
&gt; in a frame that is partially behind another frame.=C2=A0 And this happ=
ens<br>
&gt; without without any click events.=C2=A0 This could be utilized in the =
click<br>
&gt; event code to get this right somehow.<br>
<br>
</span>The mouse wheel code is also handled in mouseDown, the difference is=
<br>
that macOS always sends the mouse wheel event to the emacs frame under<br>
the mouse pointer, whereas the mouse click event is not sent when the<br>
frame is not already key (i.e. selected).<br></blockquote><div><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=
=8BCan you show some sample code that would make macOS send the mouse drag =
release event to the frame under the mouse pointer just as the scroll wheel=
 code does.=C2=A0 I have looked at this mouseUp code in nsterm.m but cannot=
 get it to do this.=C2=A0 I have managed to inject a focus in event to the =
mouseUp=E2=80=8B function and make its event frame the key frame (selected =
frame) but its event frame is the wrong one (it always has the frame of the=
 mouseDown event).</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace"><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>AFAICT Emacs does the right thing here, =
exactly the same thing as<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>every other macOS app.<div class=3D"gmai=
l_default" style=3D"font-family:monospace,monospace;display:inline">=E2=80=
=8B=E2=80=8B</div><br></blockquote><div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=8B</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BAs Eli no=
ted, this does not happen under MS Windows.=C2=A0 I want to have behavior t=
hat allows for drags across frames.=C2=A0 The present code does not, so whe=
ther it is consistent with Mac UI guidelines, it is not useful for that pur=
pose.=C2=A0 I would like your help in figuring out how to enable such behav=
ior as you seem to understand the macOS event flow well.</div><div class=3D=
"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8B=E2=80=
=8B=E2=80=8B</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace;display:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; It looks like the EV_TRAILER macro =
call at the end of the nsterm.c<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; mouseDown function (which is also c=
alled by mouseUp) sets the frame used<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; for mouse button down, up and scrol=
l wheel events from the variable<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; emacsframe.=C2=A0 Somehow the value=
 of emacsframe must be set differently for<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; mouse up events than it is for mous=
e wheel events since they end up with<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>&gt; different frames for the same mouse=
 positions.<br></span></blockquote><div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace;display:inline">=E2=80=8B=E2=80=8B</div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span><div class=3D"gmail_default" style=3D"font-family:monospace,monospac=
e;display:inline">=E2=80=8B=E2=80=8B</div>There=E2=80=99s nothing fancy her=
e, emacsframe is an instance variable<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>associated with the EmacsView that macOS=
 sends the mouse event to.</blockquote><div><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">=E2=80=8BSo show me how a=
nd where I could set that variable to the frame of the mouse position at th=
e point of mouseUp=E2=80=8B and I will test it and let people know if it wo=
rks.</div><div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace=
,monospace">Thanks,</div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace">Bob</div><div class=3D"gmail_default" style=3D"f=
ont-family:monospace,monospace"><br></div></div><br></div></div>

--001a11405bcea581eb055abbe968--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 16:31:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 04 12:31:00 2017
Received: from localhost ([127.0.0.1]:49123 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzmZY-0006Yg-1f
	for submit <at> debbugs.gnu.org; Wed, 04 Oct 2017 12:31:00 -0400
Received: from mail-wm0-f45.google.com ([74.125.82.45]:46704)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <athird@HIDDEN>) id 1dzmZW-0006YS-ME
 for 28620 <at> debbugs.gnu.org; Wed, 04 Oct 2017 12:30:59 -0400
Received: by mail-wm0-f45.google.com with SMTP id m72so24054778wmc.1
 for <28620 <at> debbugs.gnu.org>; Wed, 04 Oct 2017 09:30:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20161025;
 h=sender:date:from:to:cc:subject:message-id:references:mime-version
 :content-disposition:content-transfer-encoding:in-reply-to
 :user-agent; bh=qOH+FYwMKGIfhWJKiiw2IBBwgM/+BWxzVUilNCwgCCs=;
 b=JFvetoP24BNvxwL0jV5uDmGHQ2FE3ksUTYO16AuzGWmUbI26Ba5fTh5kGlPaiZW3Rz
 YaQy+ATa+QjHl9Eu4bferHnHY3L3rWkfw4S9ySPD+6RtPah9VT+YR2qls/fjJ0KYnGs6
 4vKd6qNVuq+GK0tplXayy1cin2Se4bjTmQkN5dGjbCojqaMmwnMtROHij/SbsDLxlXhs
 1C5DyJTMYBdvuB328HF4lGq5iapBGGUNFtyuWT6c1566CBDZ2sd29fkHJeKpDMBfZelV
 YtnTUZVl2X7wEQK98vCVt0U+Jx3Ylp3d6vphH85J1pN3hnRa+HrHbPjM7oEOSuM3Bp6Q
 XZVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
 :references:mime-version:content-disposition
 :content-transfer-encoding:in-reply-to:user-agent;
 bh=qOH+FYwMKGIfhWJKiiw2IBBwgM/+BWxzVUilNCwgCCs=;
 b=g7rVpHNS1z79zqxYIqf4z86aQU37OEvuZJeJD1ArJE3mynhFer7pCARx19DrVoY4be
 Xod/liJdNIBmK5nLVY89hDFbS6DF4DLEiHbSXn6lN0iQU+DSY451AQ5o6+/AglOhbLcY
 5AHU6pkstpIt3BaAy3mJKcy1XQsBbkgj3oEdQH9IbTO+posTy2HS1vN93g3QuEuzWXEN
 lYzQ6a/oCaNVl0JE+d/AAqEWmfcVjE+Yy0C3rTcfAi/+QNJrWxCS6WKuMHwyYDfA2FwR
 5MUfwmhKlJhnjMGDVVJFetsK4lvVVaSQ/NOTLyJ7aNlNjjDCi+JI21jnlhwlFwBpO0rg
 cl1A==
X-Gm-Message-State: AHPjjUh8g/2TIAKs1t9OHx8R5m+4ChgZ7TkebryP2/nSB67Je906KcPh
 N/kgEwmM8ld7sIrmG4MQO5c=
X-Google-Smtp-Source: AOwi7QDbaT5Yz9DlnIoi1iUX9hZNYj2s0LEVwiRAkTMj7dlRhfznFMUTKcomhQNAxYT2uX0INVMYtg==
X-Received: by 10.28.148.67 with SMTP id w64mr14921673wmd.132.1507134652797;
 Wed, 04 Oct 2017 09:30:52 -0700 (PDT)
Received: from breton.holly.idiocy.org
 (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org.
 [2001:8b0:3f8:8129:ad89:e054:5c6:3eca])
 by smtp.gmail.com with ESMTPSA id f188sm9067795wme.21.2017.10.04.09.30.51
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 04 Oct 2017 09:30:51 -0700 (PDT)
Date: Wed, 4 Oct 2017 17:30:48 +0100
From: Alan Third <alan@HIDDEN>
To: rswgnu@HIDDEN
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag
 event records wrong release window
Message-ID: <20171004163048.GA52414@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN>
 <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
 <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
User-Agent: Mutt/1.9.0 (2017-09-02)
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

On Tue, Oct 03, 2017 at 08:15:53PM -0400, Robert Weiner wrote:
> On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@HIDDEN> wrote:
> > As far as I can tell ns_mouse_position returns the frame stored in
> > dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however:
> >
> >     If the user clicks a view that isn’t in the key window, by default
> >     the window is brought forward and made key, but the mouse event is
> >     not dispatched.
> >
> 
> ​What does "the mouse event is not dispatched mean"?  Does it mean Emacs
> never sees the event?  Maybe Emacs sees only that the window has been
> selected by the window manager and based on that switches to the selected
> window of the frame?

Precisely that.

> ​The mouse wheel code manages to scroll the proper window that the mouse is
> over, even across overlapping frames where the window the mouse is over is
> in a frame that is partially behind another frame.  And this happens
> without without any click events.  This could be utilized in the click
> event code to get this right somehow.

The mouse wheel code is also handled in mouseDown, the difference is
that macOS always sends the mouse wheel event to the emacs frame under
the mouse pointer, whereas the mouse click event is not sent when the
frame is not already key (i.e. selected).

AFAICT Emacs does the right thing here, exactly the same thing as
every other macOS app.

> It looks like the EV_TRAILER macro call at the end of the nsterm.c
> mouseDown function (which is also called by mouseUp) sets the frame used
> for mouse button down, up and scroll wheel events from the variable
> emacsframe.  Somehow the value of emacsframe must be set differently for
> mouse up events than it is for mouse wheel events since they end up with
> different frames for the same mouse positions.

There’s nothing fancy here, emacsframe is an instance variable
associated with the EmacsView that macOS sends the mouse event to.

-- 
Alan Third




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 4 Oct 2017 00:16:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 20:16:36 2017
Received: from localhost ([127.0.0.1]:47050 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzXMa-00071F-Ik
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 20:16:36 -0400
Received: from eggs.gnu.org ([208.118.235.92]:53661)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzXMY-0006vY-SA
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 20:16:35 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzXMO-00027F-Oz
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 20:16:29 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46182)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzXMO-00026w-Kv
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400
Received: from mail-qt0-f172.google.com ([209.85.216.172]:48675)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzXMO-0006j4-92
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 20:16:24 -0400
Received: by mail-qt0-f172.google.com with SMTP id d13so15605330qta.5
 for <28620 <at> debbugs.gnu.org>; Tue, 03 Oct 2017 17:16:24 -0700 (PDT)
X-Gm-Message-State: AMCzsaVKFDhDcjlnLX9Tng8yUTtahOqwo2GahRTn0N41d7UapdPLUZtw
 QJo401J8jdsMlZjwdRFkPLOcZiowqpPtQxBNUoQ=
X-Google-Smtp-Source: AOwi7QCO/kFGH5Om2FJ5lgs9Z6LLA4vHEhxbnytuxIeJN7N4t5/u+17OVQcHq360BXjDfmUsi4xHc5FII2j5jFklTDY=
X-Received: by 10.200.34.167 with SMTP id f36mr25633144qta.173.1507076183850; 
 Tue, 03 Oct 2017 17:16:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 17:15:53 -0700 (PDT)
In-Reply-To: <20171003224017.GA51637@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <20171003224017.GA51637@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Tue, 3 Oct 2017 20:15:53 -0400
X-Gmail-Original-Message-ID: <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
Message-ID: <CA+OMD9j2_rw8X+wDjYaoAfYMO7wT28qJJeSraCZhfht6C6uC5A@HIDDEN>
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
To: Alan Third <alan@HIDDEN>
Content-Type: multipart/alternative; boundary="001a11404ff69685c0055aad840b"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a11404ff69685c0055aad840b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 3, 2017 at 6:40 PM, Alan Third <alan@HIDDEN> wrote:

> On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote:
> > This happens consistently in testing.  This must be a bug in
> mouse-position
> > for macOS, right?  Why would (mouse-position) still report f1 when f2 i=
s
> > the selected frame?  Maybe this is why I am seeing the wrong frame on
> drag
> > releases too.
>
> As far as I can tell ns_mouse_position returns the frame stored in
> dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however:
>
>     If the user clicks a view that isn=E2=80=99t in the key window, by de=
fault
>     the window is brought forward and made key, but the mouse event is
>     not dispatched.
>

=E2=80=8BWhat does "the mouse event is not dispatched mean"?  Does it mean =
Emacs
never sees the event?  Maybe Emacs sees only that the window has been
selected by the window manager and based on that switches to the selected
window of the frame?

> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
>         https://developer.apple.com/library/content/documentation/
> Cocoa/Conceptual/EventOverview/HandlingMouseEvents/
> HandlingMouseEvents.html
> =E2=80=8B=E2=80=8B
>
> =E2=80=8B=E2=80=8B
> My guess is that ns_mouse_position needs to get a list of NSWindows,
> =E2=80=8B=E2=80=8B
> iterate over them to find out which one the mouse pointer is over,
> =E2=80=8B=E2=80=8B
> convert that NSWindow back to an Emacs frame, and set *fp to it before
> =E2=80=8B=E2=80=8B
> returning.
>

=E2=80=8BThe mouse wheel code manages to scroll the proper window that the =
mouse is
over, even across overlapping frames where the window the mouse is over is
in a frame that is partially behind another frame.  And this happens
without without any click events.  This could be utilized in the click
event code to get this right somehow.

It looks like the EV_TRAILER macro call at the end of the nsterm.c
mouseDown function (which is also called by mouseUp) sets the frame used
for mouse button down, up and scroll wheel events from the variable
emacsframe.  Somehow the value of emacsframe must be set differently for
mouse up events than it is for mouse wheel events since they end up with
different frames for the same mouse positions.

Bob

--001a11404ff69685c0055aad840b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Tue, Oct 3, 20=
17 at 6:40 PM, Alan Third </span><span dir=3D"ltr" style=3D"font-family:ari=
al,sans-serif">&lt;<a href=3D"mailto:alan@HIDDEN" target=3D"_blank">ala=
n@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wr=
ote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Tue, Oct 03, 2017 at 02:21:43PM -0400, Ro=
bert Weiner wrote:<br>
&gt; This happens consistently in testing.=C2=A0 This must be a bug in mous=
e-position<br>
&gt; for macOS, right?=C2=A0 Why would (mouse-position) still report f1 whe=
n f2 is<br>
&gt; the selected frame?=C2=A0 Maybe this is why I am seeing the wrong fram=
e on drag<br>
&gt; releases too.<br>
<br>
As far as I can tell ns_mouse_position returns the frame stored in<br>
dpyinfo-&gt;last_mouse_frame, which is set by EmacsView::mouseDown, however=
:<br>
<br>
=C2=A0 =C2=A0 If the user clicks a view that isn=E2=80=99t in the key windo=
w, by default<br>
=C2=A0 =C2=A0 the window is brought forward and made key, but the mouse eve=
nt is<br>
=C2=A0 =C2=A0 not dispatched.<br></blockquote><div><br></div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BWhat does=
 &quot;the mouse event is not dispatched mean&quot;?=C2=A0 Does it mean Ema=
cs never sees the event?=C2=A0 Maybe Emacs sees only that the window has be=
en selected by the window manager and based on that switches to the selecte=
d window of the frame?</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"h=
ttps://developer.apple.com/library/content/documentation/Cocoa/Conceptual/E=
ventOverview/HandlingMouseEvents/HandlingMouseEvents.html" rel=3D"noreferre=
r" target=3D"_blank">https://developer.apple.com/<wbr>library/content/docum=
entation/<wbr>Cocoa/Conceptual/<wbr>EventOverview/<wbr>HandlingMouseEvents/=
<wbr>HandlingMouseEvents.html</a><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div><br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>My guess is that ns_mouse_position needs=
 to get a list of NSWindows,<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>iterate over them to find out which one =
the mouse pointer is over,<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>convert that NSWindow back to an Emacs f=
rame, and set *fp to it before<br>
<div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displ=
ay:inline">=E2=80=8B=E2=80=8B</div>returning.<br></blockquote><div><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8BThe mouse wheel code manages to scroll the proper window that the =
mouse is over, even across overlapping frames where the window the mouse is=
 over is in a frame that is partially behind another frame.=C2=A0 And this =
happens without without any click events.=C2=A0 This could be utilized in t=
he click event code to get this right somehow.</div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gma=
il_default" style=3D"font-family:monospace,monospace">It looks like the EV_=
TRAILER macro call at the end of the nsterm.c mouseDown function (which is =
also called by mouseUp) sets the frame used for mouse button down, up and s=
croll wheel events from the variable emacsframe.=C2=A0 Somehow the value of=
 emacsframe must be set differently for mouse up events than it is for mous=
e wheel events since they end up with different frames for the same mouse p=
ositions.</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace">Bob</div><div class=3D"gmail_default" style=3D"font-family=
:monospace,monospace"><br></div></div></div></div>

--001a11404ff69685c0055aad840b--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 22:40:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 18:40:30 2017
Received: from localhost ([127.0.0.1]:46972 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzVra-00032b-EB
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 18:40:30 -0400
Received: from mail-wm0-f51.google.com ([74.125.82.51]:43947)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <athird@HIDDEN>) id 1dzVrX-00032M-Ue
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 18:40:28 -0400
Received: by mail-wm0-f51.google.com with SMTP id m72so12457033wmc.0
 for <28620 <at> debbugs.gnu.org>; Tue, 03 Oct 2017 15:40:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=googlemail.com; s=20161025;
 h=sender:date:from:to:cc:subject:message-id:references:mime-version
 :content-disposition:content-transfer-encoding:in-reply-to
 :user-agent; bh=zekWL6hXKyb4s51tVE22ZXVEpXfvCiT4EkQSDsnjD14=;
 b=vPivADS6BzGUCR6SAYi17ggUu6PY8yVuI0nemfaz27iWgByhahgR9Aee9ZIBkeM1by
 ed4IvvJkOyXGzwt+UfF02upHv0O6kgCoXsCMIflpOKBGqUORJtPY61J59sNO2XBuQUlJ
 M75FZXnlHotLnGCpsMOGEo8DVsk7MjHwMXBcfFDsTA5odGj1ShPFElqwzhGspbPmtzlg
 7a1I6X6hctEIF/lQdbTtHOJN1mpvKt0cBK7/OiETyYZl/UTo1WyBZwqlyzkS7DRRXfMt
 g7IcVv3Vh+cQIBPOvYYIY2oM5X2cBKlkZfMx5+RIP9CeyTBMHcNqj0WzV3tmGggxYNfT
 pL+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:date:from:to:cc:subject:message-id
 :references:mime-version:content-disposition
 :content-transfer-encoding:in-reply-to:user-agent;
 bh=zekWL6hXKyb4s51tVE22ZXVEpXfvCiT4EkQSDsnjD14=;
 b=Ohevb0rvJBgSXMzTW1gEr5u4cxhYMaQsynl7xzUJWoL3d8pjsiNuqerhq5qYpuJqRY
 ThOMlxgCBRDyR+ApyhjEmXUqF1O99sRs227L/TxTJ4NbmZmSxVcldzHafklIreILppcD
 QSh/EuraRUAVicFxK4rLFT6PQOzwNgQf3Xvm5w2/Ntv8wThdfwzpR2Fi9ddj9pXbP8Lz
 tvJcSYSHX3iHtcVby7Tkb5Vl45qQaVUw031WimFvDyOwRcgqq/Zbs25ohaanMAReA5Z8
 YnZ+J1ajyygDw7qy6brLQoznYL6leN5YMCZjduBtDOizZpotpnwYcvNwJIIz/1mPB50b
 oFPA==
X-Gm-Message-State: AMCzsaX3OjtR8FJlNCGqrX6qXvEiTprApEdCslemeYZv8g6CcrVi85HU
 zrmz2dUMkyndJEROpw/gBt4=
X-Google-Smtp-Source: AOwi7QDe79V3MKRnTOXttEnydExFZGI7PBWFIqhjii040S9xfssUcECAoJfYozW0h7IJ1ZYj8KrCNw==
X-Received: by 10.28.17.1 with SMTP id 1mr266952wmr.66.1507070420995;
 Tue, 03 Oct 2017 15:40:20 -0700 (PDT)
Received: from breton.holly.idiocy.org
 (ip6-2001-08b0-03f8-8129-ad89-e054-05c6-3eca.holly.idiocy.org.
 [2001:8b0:3f8:8129:ad89:e054:5c6:3eca])
 by smtp.gmail.com with ESMTPSA id 204sm15841692wml.10.2017.10.03.15.40.19
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Tue, 03 Oct 2017 15:40:19 -0700 (PDT)
Date: Tue, 3 Oct 2017 23:40:17 +0100
From: Alan Third <alan@HIDDEN>
To: rswgnu@HIDDEN
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag
 event records wrong release window
Message-ID: <20171003224017.GA51637@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN>
 <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
User-Agent: Mutt/1.9.0 (2017-09-02)
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.7 (/)

On Tue, Oct 03, 2017 at 02:21:43PM -0400, Robert Weiner wrote:
> This happens consistently in testing.  This must be a bug in mouse-position
> for macOS, right?  Why would (mouse-position) still report f1 when f2 is
> the selected frame?  Maybe this is why I am seeing the wrong frame on drag
> releases too.

As far as I can tell ns_mouse_position returns the frame stored in
dpyinfo->last_mouse_frame, which is set by EmacsView::mouseDown, however:

    If the user clicks a view that isn’t in the key window, by default
    the window is brought forward and made key, but the mouse event is
    not dispatched.

        https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html

My guess is that ns_mouse_position needs to get a list of NSWindows,
iterate over them to find out which one the mouse pointer is over,
convert that NSWindow back to an Emacs frame, and set *fp to it before
returning.

That way it should return the frame the mouse is over, rather than the
last one that received a click event.

I’m not sure what happens if the mouse isn’t over an emacs frame...
Does it just return *fp unchanged?
-- 
Alan Third




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 20:55:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 16:55:05 2017
Received: from localhost ([127.0.0.1]:46901 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzUDZ-0000M4-G3
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 16:55:05 -0400
Received: from eggs.gnu.org ([208.118.235.92]:40849)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzUDX-0000LX-W3
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 16:55:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzUDO-0004PX-2z
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 16:54:58 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41922)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzUDN-0004PM-VW
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 16:54:54 -0400
Received: from mail-qt0-f177.google.com ([209.85.216.177]:44062)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzUDN-0004ho-MB
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 16:54:53 -0400
Received: by mail-qt0-f177.google.com with SMTP id v28so6688957qtv.1
 for <28620 <at> debbugs.gnu.org>; Tue, 03 Oct 2017 13:54:53 -0700 (PDT)
X-Gm-Message-State: AMCzsaVScejS584oJjAeE7BwaqEO+0rSqMw5r/WCfMSt5bmyPpPsxs89
 cuX/DOgvRCxwXVvhzEdu6kuRr3qqzE4p1zjl9qk=
X-Google-Smtp-Source: AOwi7QCwyzryKrivLyEDoD6pUNsuM7oxsAzOg33YXhFtqv1JFf5MI/fvZCvxTPyeXfxEanQEekPPWf3qJaiXGbUZZ4E=
X-Received: by 10.200.57.29 with SMTP id s29mr26327388qtb.309.1507064093197;
 Tue, 03 Oct 2017 13:54:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 13:54:22 -0700 (PDT)
From: Robert Weiner <rsw@HIDDEN>
Date: Tue, 3 Oct 2017 16:54:22 -0400
X-Gmail-Original-Message-ID: <CA+OMD9i7AYoSMMbQzLUSwhghgg55UE-cMY47-uhQuaMTWa3hsw@HIDDEN>
Message-ID: <CA+OMD9i7AYoSMMbQzLUSwhghgg55UE-cMY47-uhQuaMTWa3hsw@HIDDEN>
Subject: (mouse-position_ wrong on macOS after mouse-1 click (Was: Interact
 directly on Emacs bug#28620: mouse drag event records wrong release window)
To: 28620 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="001a11418c4eedcb82055aaab375"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a11418c4eedcb82055aaab375
Content-Type: text/plain; charset="UTF-8"

Interestingly, mouse wheel scroll events work properly.  Such events always
include the window the mouse is over (when mouse-wheel-follow-mouse is t,
which it is by default).  They select this window and then scroll that
window, so I can move the mouse across frames and scroll arbitrary windows,
which suggests that drag events should operate similarly and include the
window of the drag release.

Now to find out how the position of the mouse is used differently in mouse
drags compared to mouse wheel events.

Bob

--001a11418c4eedcb82055aaab375
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">Interestingly, mouse wheel scroll events work properly.=C2=A0 =
Such events always include the window the mouse is over (when mouse-wheel-f=
ollow-mouse is t, which it is by default).=C2=A0 They select this window an=
d then scroll that window, so I can move the mouse across frames and scroll=
 arbitrary windows, which suggests that drag events should operate similarl=
y and include the window of the drag release.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:monospace,monospace">Now to find out how th=
e position of the mouse is used differently in mouse drags compared to mous=
e wheel events.</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace">Bob</div><div class=3D"gmail_default" style=3D"font-=
family:monospace,monospace"><br></div></div>

--001a11418c4eedcb82055aaab375--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:53:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 14:53:51 2017
Received: from localhost ([127.0.0.1]:46767 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzSKF-0005Vj-CW
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:53:51 -0400
Received: from eggs.gnu.org ([208.118.235.92]:41737)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzSKD-0005VU-MS
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:53:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzSK3-0004B0-3x
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:53:44 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,URIBL_BLOCKED autolearn=disabled
 version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39159)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzSK2-0004An-VY
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:53:39 -0400
Received: from mail-qk0-f171.google.com ([209.85.220.171]:47112)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzSK2-0003f0-Kg
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:53:38 -0400
Received: by mail-qk0-f171.google.com with SMTP id m189so5186644qke.4
 for <28620 <at> debbugs.gnu.org>; Tue, 03 Oct 2017 11:53:38 -0700 (PDT)
X-Gm-Message-State: AMCzsaVEfoy2Y13bLgCorbcuWgOK5FSnjiV9WzsrENp8JwTY4inbtS5I
 mpzu39rieQXjXBN7Z5tIe+z2JmfVrrGqtgSZO5w=
X-Google-Smtp-Source: AOwi7QDwO4JRhoPoYR4As6wyoGS3wVhHF2ZawS5EaHH5YbfdW1bzissySIBF+9cUYxDW28Mq05HAO3BmLsFWwulWs4s=
X-Received: by 10.55.12.130 with SMTP id 124mr3163946qkm.186.1507056817995;
 Tue, 03 Oct 2017 11:53:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 11:53:07 -0700 (PDT)
In-Reply-To: <83r2ukyswj.fsf@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 <83r2ukyswj.fsf@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Tue, 3 Oct 2017 14:53:07 -0400
X-Gmail-Original-Message-ID: <CA+OMD9jjGHtpm2j-sYQ_feqDJyWeGDOqWMJmnCwy=_ek4OYC6g@HIDDEN>
Message-ID: <CA+OMD9jjGHtpm2j-sYQ_feqDJyWeGDOqWMJmnCwy=_ek4OYC6g@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="001a114d6da04b0771055aa9026f"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a114d6da04b0771055aa9026f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 3, 2017 at 2:42 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Robert Weiner <rsw@HIDDEN>
> > Date: Tue, 3 Oct 2017 14:21:43 -0400
> > Cc: Eli Zaretskii <eliz@HIDDEN>
> >
> > I start with the mouse within a window of f1 and selected frame of f1;
> (mouse-position) also reports f1.
> >
> > I click mouse-1 in an Emacs window of f2 and leave it there.
> > (selected-frame) is now f2
> > macOS window manager highlights f2 as active window
> > (frame-focus) returns nil
> > (mouse-position) reports a frame of f1 <<< WRONG
>
> Sounds like something that's macOS specific.  At least on MS-Windows I
> cannot reproduce this: mouse-position returns the correct frame.
>

=E2=80=8BOk, that is good to know.  Is there a go to person for the Mac-spe=
cific
windowing code to check on this with?

Could someone check when running X with a click-for-focus window manager
setting and see what happens there?

Bob

--001a114d6da04b0771055aa9026f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Tue, Oct 3, 20=
17 at 2:42 PM, Eli Zaretskii </span><span dir=3D"ltr" style=3D"font-family:=
arial,sans-serif">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eli=
z@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote=
:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">&gt; From: Robert Weiner &lt;<a href=3D"mailto:=
rsw@HIDDEN">rsw@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 3 Oct 2017 14:21:43 -0400<br>
&gt; Cc: Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>=
&gt;<br>
<span class=3D"">&gt;<br>
&gt; I start with the mouse within a window of f1 and selected frame of f1;=
 (mouse-position) also reports f1.<br>
&gt;<br>
&gt; I click mouse-1 in an Emacs window of f2 and leave it there.<br>
&gt; (selected-frame) is now f2<br>
&gt; macOS window manager highlights f2 as active window<br>
&gt; (frame-focus) returns nil<br>
&gt; (mouse-position) reports a frame of f1 &lt;&lt;&lt; WRONG<br>
<br>
</span>Sounds like something that&#39;s macOS specific.=C2=A0 At least on M=
S-Windows I<br>
cannot reproduce this: mouse-position returns the correct frame.<br></block=
quote><div><br></div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace">=E2=80=8BOk, that is good to know.=C2=A0 Is there a go to =
person for the Mac-specific windowing code to check on this with?</div><div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">Co=
uld someone check when running X with a click-for-focus window manager sett=
ing and see what happens there?</div><div class=3D"gmail_default" style=3D"=
font-family:monospace,monospace"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace">Bob</div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace"><br></div></div><br></div></div=
>

--001a114d6da04b0771055aa9026f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:43:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 14:43:30 2017
Received: from localhost ([127.0.0.1]:46757 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzSAE-0005EH-Ds
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:43:30 -0400
Received: from eggs.gnu.org ([208.118.235.92]:38764)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1dzSAB-0005E3-Dy
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:43:29 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1dzSA1-0000l0-TY
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:43:22 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,
 URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39011)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1dzSA1-0000k7-Jv; Tue, 03 Oct 2017 14:43:17 -0400
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3134
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1dzS9z-00034N-UA; Tue, 03 Oct 2017 14:43:17 -0400
Date: Tue, 03 Oct 2017 21:42:53 +0300
Message-Id: <83r2ukyswj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: rswgnu@HIDDEN
In-reply-to: <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
 (message from Robert Weiner on Tue, 3 Oct 2017 14:21:43 -0400)
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
 <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 28620
Cc: 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Robert Weiner <rsw@HIDDEN>
> Date: Tue, 3 Oct 2017 14:21:43 -0400
> Cc: Eli Zaretskii <eliz@HIDDEN>
> 
> I start with the mouse within a window of f1 and selected frame of f1; (mouse-position) also reports f1.
> 
> I click mouse-1 in an Emacs window of f2 and leave it there.
> (selected-frame) is now f2
> macOS window manager highlights f2 as active window
> (frame-focus) returns nil
> (mouse-position) reports a frame of f1 <<< WRONG

Sounds like something that's macOS specific.  At least on MS-Windows I
cannot reproduce this: mouse-position returns the correct frame.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 3 Oct 2017 18:22:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 03 14:22:25 2017
Received: from localhost ([127.0.0.1]:46736 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dzRpp-0004ce-93
	for submit <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:22:25 -0400
Received: from eggs.gnu.org ([208.118.235.92]:56350)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dzRpn-0004cP-M2
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:22:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dzRpf-0007N7-7M
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:22:18 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38416)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dzRpf-0007Ms-45
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:22:15 -0400
Received: from mail-qt0-f178.google.com ([209.85.216.178]:52993)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dzRpe-00031w-SX
 for 28620 <at> debbugs.gnu.org; Tue, 03 Oct 2017 14:22:15 -0400
Received: by mail-qt0-f178.google.com with SMTP id o52so14641027qtc.9
 for <28620 <at> debbugs.gnu.org>; Tue, 03 Oct 2017 11:22:14 -0700 (PDT)
X-Gm-Message-State: AMCzsaWS7JcrTMwnQ/ps6rWVRkMu4vm/0hKpKHH6obwKHRjNlrLE3Iit
 713L/Z2N3cT8Muf7K/L4lMzI1XBHwoCyIF2Wsts=
X-Google-Smtp-Source: AOwi7QC2rhJqDo5vahh4K98cqVtZzNDTgFonrH1d90s7n5iIo/ND4xA12WOm/LrP3+XebtaPqP0kw38IsdYRLKwlZGo=
X-Received: by 10.200.54.3 with SMTP id m3mr842794qtb.197.1507054934286; Tue,
 03 Oct 2017 11:22:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Tue, 3 Oct 2017 11:21:43 -0700 (PDT)
In-Reply-To: <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@HIDDEN>
 <83wp4e3nvx.fsf@HIDDEN> <DCD76686-AED1-4D1B-BF28-CAA693633E07@HIDDEN>
 <8360bx340d.fsf@HIDDEN>
 <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@HIDDEN>
 <8360bw19es.fsf@HIDDEN>
 <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Tue, 3 Oct 2017 14:21:43 -0400
X-Gmail-Original-Message-ID: <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
Message-ID: <CA+OMD9gWapkR2f=K+cf9zRWwQjoQJ1B_=fxHSTVRH4bpPwgXuA@HIDDEN>
Subject: Re: Interact directly on Emacs bug#28620: mouse drag event records
 wrong release window
To: 28620 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="001a1137b05403ea3c055aa892a9"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a1137b05403ea3c055aa892a9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Using the latest Emacs26 built from master on MacOS Sierra using the macOS
window system, I see the following if I have two frames: f1 and f2.

I start with the mouse within a window of f1 and selected frame of f1;
(mouse-position) also reports f1.

I click mouse-1 in an Emacs window of f2 and leave it there.
  (selected-frame) is now f2
  macOS window manager highlights f2 as active window
  (frame-focus) returns nil
  (mouse-position) reports a frame of f1       <<< WRONG


I click mouse-1 again in the same Emacs window of f2.
  (selected-frame) is still f2
  macOS window manager highlights f2 as active window
  (frame-focus) returns nil
  (mouse-position) now reports a frame of f2

This happens consistently in testing.  This must be a bug in mouse-position
for macOS, right?  Why would (mouse-position) still report f1 when f2 is
the selected frame?  Maybe this is why I am seeing the wrong frame on drag
releases too.

If anyone else could confirm this and whether it happens on other window
systems that use a mouse click to select windows, that would be helpful.

Bob

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

--001a1137b05403ea3c055aa892a9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">Using the latest Emacs26 built from master on MacOS Sierra usi=
ng the macOS window system, I see the following if I have two frames: f1 an=
d f2.</div><div class=3D"gmail_default" style=3D"font-family:monospace,mono=
space"><br></div><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace">I start with the mouse within a window of f1 and selected fram=
e of f1; (mouse-position) also reports f1.</div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace">I click mouse-1 in an Ema=
cs window of f2 and leave it there.</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">=C2=A0 (selected-frame) is now f2</div=
><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=C2=
=A0 macOS window manager highlights f2 as active window</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace">=C2=A0 (frame-focu=
s) returns nil</div><div class=3D"gmail_default" style=3D"font-family:monos=
pace,monospace">=C2=A0 (mouse-position) reports a frame of f1=C2=A0 =C2=A0 =
=C2=A0 =C2=A0&lt;&lt;&lt; WRONG</div><div class=3D"gmail_default" style=3D"=
font-family:monospace,monospace"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace,monospace">I click mouse-1 again in the s=
ame Emacs window of f2.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:monospace,monospace">=C2=A0 (selected-frame) is still f2</div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace">=C2=A0 macOS =
window manager highlights f2 as active window</div><div class=3D"gmail_defa=
ult" style=3D"font-family:monospace,monospace">=C2=A0 (frame-focus) returns=
 nil</div><div class=3D"gmail_default" style=3D"font-family:monospace,monos=
pace">=C2=A0 (mouse-position) now reports a frame of f2</div><div class=3D"=
gmail_default" style=3D"font-family:monospace,monospace"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:monospace,monospace">This happens=
 consistently in testing.=C2=A0 This must be a bug in mouse-position for ma=
cOS, right?=C2=A0 Why would (mouse-position) still report f1 when f2 is the=
 selected frame?=C2=A0 Maybe this is why I am seeing the wrong frame on dra=
g releases too.</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:monospace,monospace">If anyone else could confirm this and whether it hap=
pens on other window systems that use a mouse click to select windows, that=
 would be helpful.</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:monospace,monospace">Bob</div><div class=3D"gmail_default" style=3D"fo=
nt-family:monospace,monospace"><br></div><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8B=
=E2=80=8B</div><div class=3D"gmail_default" style=3D"font-family:monospace,=
monospace">=E2=80=8B=E2=80=8B</div><br><div class=3D"gmail_quote"><br></div=
></div></div>

--001a1137b05403ea3c055aa892a9--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 30 Sep 2017 23:35:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 30 19:35:34 2017
Received: from localhost ([127.0.0.1]:41606 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dyRID-0006Ho-V9
	for submit <at> debbugs.gnu.org; Sat, 30 Sep 2017 19:35:34 -0400
Received: from eggs.gnu.org ([208.118.235.92]:39637)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dyRIC-0006HZ-6C
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 19:35:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dyRI4-00066A-AN
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 19:35:27 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54211)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dyRI4-00065P-7E
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 19:35:24 -0400
Received: from mail-qt0-f177.google.com ([209.85.216.177]:52782)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dyRI3-0002Fu-QR
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 19:35:24 -0400
Received: by mail-qt0-f177.google.com with SMTP id o52so3552935qtc.9
 for <28620 <at> debbugs.gnu.org>; Sat, 30 Sep 2017 16:35:23 -0700 (PDT)
X-Gm-Message-State: AMCzsaW/q+5Njd5haRqGkXVXeL0jWb4XzvXPde8DJ+/mRp+Cii+r+8G1
 qzg009wofd2PzC2ubXwuSX16USloBwrhvetSftI=
X-Google-Smtp-Source: AOwi7QB0qVQSMqWxzu9MxtVOE5obbSHHs6pWpsz4/X8CKYOizZuYGICtqrg7tU/nuIzaJ4qULLFas7z4SraEQMvm8s0=
X-Received: by 10.200.54.3 with SMTP id m3mr13206148qtb.197.1506814523252;
 Sat, 30 Sep 2017 16:35:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Sat, 30 Sep 2017 16:34:52 -0700 (PDT)
In-Reply-To: <CA+OMD9gVr1Gk_gtDoF-bnCfG=5c5h1NJVg4VXRN8v7RqokCB9g@HIDDEN>
References: <CA+OMD9ieLvVUCu6ubaHohNso+s9TGK+oJcnRVkdyZ4+2JtM41g@HIDDEN>
 <83k20h5m2x.fsf@HIDDEN>
 <CA+OMD9g+iCKCA1onkLCZ0nDpzDGMcciJXzOaddG5tBo0C2AfEw@HIDDEN>
 <59CF56AF.3090008@HIDDEN>
 <CA+OMD9jOZA6DNFqXyzsyc22dRzxdVeStZ9JdRBJ4cY6J9QWr9A@HIDDEN>
 <59CFD083.40407@HIDDEN>
 <CA+OMD9gVr1Gk_gtDoF-bnCfG=5c5h1NJVg4VXRN8v7RqokCB9g@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Sat, 30 Sep 2017 19:34:52 -0400
X-Gmail-Original-Message-ID: <CA+OMD9ig6cLHJXn+sZBxhNdQC+8afLNC0YptK47DiCtVSn5TUw@HIDDEN>
Message-ID: <CA+OMD9ig6cLHJXn+sZBxhNdQC+8afLNC0YptK47DiCtVSn5TUw@HIDDEN>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="001a1137b05466a8f7055a70982f"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.5 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

--001a1137b05466a8f7055a70982f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 30, 2017 at 5:56 PM, Robert Weiner <rsw@HIDDEN> wrote:

> In fact, the release event (drag event) contains the wrong
> frame (that of the depress rather than the release).
>

=E2=80=8BIn looking at how mouse-1 is able to select the proper window of a=
 mouse
click,
I found that the release binding of mouse-1 changes when a click is in a
frame
other than the selected one.  In that case, it shifts from mouse-set-point
to
handle-switch-frame which selects the new frame.  Is this shift due to the
transient-map
map setting in mouse-drag-track?

Eli, if you could point me to where the switch-frame event is generated
when the click
is in another frame, with that I might be able to produce a temporary fix
for this problem.

It would also help if in handle-switch-frame, the handle-focus-in hook
invocation occurred
after the call to do_switch_frame rather than before; then we could grab
the value of the
newly selected frame rather than the old one.

Bob


tBut I can't find anywhere in
the Emacs 25 code where mouse-1 is bound to handle-switch-frame.

Can you point me to where this is coded?  Is the keymap in use changing?
Is there any way to capture a switch-frame event and attach my own handler
to
it?  (I guess I could redefine the primitive handle-switch-fraem

--001a1137b05466a8f7055a70982f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Sat, Sep 30, 2=
017 at 5:56 PM, Robert Weiner </span><span dir=3D"ltr" style=3D"font-family=
:arial,sans-serif">&lt;<a href=3D"mailto:rsw@HIDDEN" target=3D"_blank">rsw=
@gnu.org</a>&gt;</span><span style=3D"font-family:arial,sans-serif"> wrote:=
</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><span><div style=3D"font-family=
:monospace,monospace">In fact, the release event (drag event) contains the =
wrong<br></div></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"=
><div style=3D"font-family:monospace,monospace">frame (that of the depress =
rather than the release).</div></div></div></div></blockquote><div><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=
=E2=80=8BIn looking at how mouse-1 is able to select the proper window of a=
 mouse click,</div><div class=3D"gmail_default" style=3D"font-family:monosp=
ace,monospace">I found that the release binding of mouse-1 changes when a c=
lick is in a frame</div><div class=3D"gmail_default" style=3D"font-family:m=
onospace,monospace">other than the selected one.=C2=A0 In that case, it shi=
fts from mouse-set-point to</div><div class=3D"gmail_default" style=3D"font=
-family:monospace,monospace">handle-switch-frame which selects the new fram=
e.=C2=A0 Is this shift due to the transient-map</div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace,monospace">map setting in mouse-drag-=
track?</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace"><br></div><div class=3D"gmail_default" style=3D"font-family:monospa=
ce,monospace">Eli, if you could point me to where the switch-frame event is=
 generated when the click</div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace">is in another frame, with that I might be able t=
o produce a temporary fix for this problem.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_=
default" style=3D"font-family:monospace,monospace">It would also help if in=
 handle-switch-frame, the handle-focus-in hook invocation occurred</div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace">after t=
he call to do_switch_frame rather than before; then we could grab the value=
 of the</div><div class=3D"gmail_default" style=3D"font-family:monospace,mo=
nospace">newly selected frame rather than the old one.</div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace">Bob</div><div=
 class=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:monospace,monospa=
ce">tBut I can&#39;t find anywhere in</div><div class=3D"gmail_default" sty=
le=3D"font-family:monospace,monospace">the Emacs 25 code where mouse-1 is b=
ound to handle-switch-frame.</div><div class=3D"gmail_default" style=3D"fon=
t-family:monospace,monospace"><br></div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">Can you point me to where this is code=
d?=C2=A0 Is the keymap in use changing?</div><div class=3D"gmail_default" s=
tyle=3D"font-family:monospace,monospace">Is there any way to capture a swit=
ch-frame event and attach my own handler to</div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace,monospace">it?=C2=A0 (I guess I could red=
efine the primitive handle-switch-fraem</div><div class=3D"gmail_default" s=
tyle=3D"font-family:monospace,monospace">=C2=A0</div></div></div></div>

--001a1137b05466a8f7055a70982f--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at 28620 <at> debbugs.gnu.org:


Received: (at 28620) by debbugs.gnu.org; 30 Sep 2017 21:57:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 30 17:57:30 2017
Received: from localhost ([127.0.0.1]:41549 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dyPlJ-0001b7-Ln
	for submit <at> debbugs.gnu.org; Sat, 30 Sep 2017 17:57:29 -0400
Received: from eggs.gnu.org ([208.118.235.92]:48178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dyPlH-0001as-HC
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 17:57:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dyPl9-0001jO-5s
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 17:57:22 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41070)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dyPl9-0001iy-14
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 17:57:19 -0400
Received: from mail-qt0-f176.google.com ([209.85.216.176]:50383)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dyPl8-0001UG-L5
 for 28620 <at> debbugs.gnu.org; Sat, 30 Sep 2017 17:57:18 -0400
Received: by mail-qt0-f176.google.com with SMTP id f15so3450242qtf.7
 for <28620 <at> debbugs.gnu.org>; Sat, 30 Sep 2017 14:57:18 -0700 (PDT)
X-Gm-Message-State: AMCzsaVkHyq6K6wkJHLjynTgyhwOGWKZSnsGnoXPiPO2MHe+RY1DBs/e
 G+ZIa0ccKe4FY0mFAXGOkOavfykjb4lbb7DH1iA=
X-Google-Smtp-Source: AOwi7QDjUnSXQV+VZY527/oCnNiYlxjyGtUrjzbhEeD+x7U+h/fqdsHAX0IOYeUoCJn7ozuc8z/RlLWSlbhqpZFsXv4=
X-Received: by 10.237.39.219 with SMTP id m27mr12532296qtg.34.1506808638051;
 Sat, 30 Sep 2017 14:57:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.34.225 with HTTP; Sat, 30 Sep 2017 14:56:47 -0700 (PDT)
In-Reply-To: <59CFD083.40407@HIDDEN>
References: <CA+OMD9ieLvVUCu6ubaHohNso+s9TGK+oJcnRVkdyZ4+2JtM41g@HIDDEN>
 <83k20h5m2x.fsf@HIDDEN>
 <CA+OMD9g+iCKCA1onkLCZ0nDpzDGMcciJXzOaddG5tBo0C2AfEw@HIDDEN>
 <59CF56AF.3090008@HIDDEN>
 <CA+OMD9jOZA6DNFqXyzsyc22dRzxdVeStZ9JdRBJ4cY6J9QWr9A@HIDDEN>
 <59CFD083.40407@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Sat, 30 Sep 2017 17:56:47 -0400
X-Gmail-Original-Message-ID: <CA+OMD9gVr1Gk_gtDoF-bnCfG=5c5h1NJVg4VXRN8v7RqokCB9g@HIDDEN>
Message-ID: <CA+OMD9gVr1Gk_gtDoF-bnCfG=5c5h1NJVg4VXRN8v7RqokCB9g@HIDDEN>
Subject: Re: bug#28621: Proposed patch for doc of posn-window and code of
 posn-set-point to handle frame arguments
To: martin rudalics <rudalics@HIDDEN>
Content-Type: multipart/alternative; boundary="f403045ee8569d99d7055a6f3978"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, 28620 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--f403045ee8569d99d7055a6f3978
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 30, 2017 at 1:12 PM, martin rudalics <rudalics@HIDDEN> wrote:

> > This speaks to my point in my most recent prior message, "If we just ha=
d
> a
> > way to get a window from a set of coordinates within a frame, then I
> think
> > this would help solve a lot of this."  If the event-end of Emacs mouse
> drag
> > events included a window, rather than a frame, when the endpoint of the
> > drag is at a position unique to a window (considering Z-frame order), I
> > think that would solve all these issues and simplify parts of the posn
> code.
>

=E2=80=8BThe issue, to recap, is that I can't find a function that
will report the window that a mouse release button event
occurs in if the depress and release are in different frames
(for Emacs 25).

In fact, the release event (drag event) contains the wrong
frame (that of the depress rather than the release).  The wrong
frame is also reported by mouse-position and mouse-pixel-position,
so window-at can't be used either.

The problem seems to be documented in the Emacs event design.
Frame selection events are deferred when they occur while a button
is depressed to prevent some kind of state inconsistency.  But as
a result, the drag release event records the wrong frame and there
is no way for the release binding to determine and record the right
one.


> Take the position of the event-end (if it's a frame) and translate it
> into absolute screen coordinates (the Elisp manual should give you
> enough clues to do that).  Or, try =E2=80=98mouse-absolute-pixel-position=
=E2=80=99 - it
> should give you the screen position of the mouse at that time so you can
> ignore the event completely.
>
> Then walk all your windows and compare that position with whatever
> =E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window.  I=
f you have two
> or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare t=
he result
> against those windows' frames.  No hands, IMHO.


=E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that works w=
ith
older versions.=E2=80=8B

Bob

--f403045ee8569d99d7055a6f3978
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e,monospace"><span style=3D"font-family:arial,sans-serif">On Sat, Sep 30, 2=
017 at 1:12 PM, martin rudalics </span><span dir=3D"ltr" style=3D"font-fami=
ly:arial,sans-serif">&lt;<a href=3D"mailto:rudalics@HIDDEN" target=3D"_blan=
k">rudalics@HIDDEN</a>&gt;</span><span style=3D"font-family:arial,sans-seri=
f"> wrote:</span><br></div><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><span class=3D"">&gt; This speaks to m=
y point in my most recent prior message, &quot;If we just had a<br>
&gt; way to get a window from a set of coordinates within a frame, then I t=
hink<br>
&gt; this would help solve a lot of this.&quot;=C2=A0 If the event-end of E=
macs mouse drag<br>
&gt; events included a window, rather than a frame, when the endpoint of th=
e<br>
&gt; drag is at a position unique to a window (considering Z-frame order), =
I<br>
&gt; think that would solve all these issues and simplify parts of the posn=
 code.<br></span></blockquote><div><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:monospace,monospace">=E2=80=8BThe issue, to recap, is t=
hat I can&#39;t find a function that</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace,monospace">will report the window that a mouse r=
elease button event</div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace">occurs in if the depress and release are in different =
frames</div><div class=3D"gmail_default" style=3D"font-family:monospace,mon=
ospace">(for Emacs 25).</div><div class=3D"gmail_default" style=3D"font-fam=
ily:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:monospace,monospace">In fact, the release event (drag event) cont=
ains the wrong</div><div class=3D"gmail_default" style=3D"font-family:monos=
pace,monospace">frame (that of the depress rather than the release).=C2=A0 =
The wrong=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:mono=
space,monospace">frame is also reported by mouse-position and mouse-pixel-p=
osition,</div><div class=3D"gmail_default" style=3D"font-family:monospace,m=
onospace">so window-at can&#39;t be used either.</div><div class=3D"gmail_d=
efault" style=3D"font-family:monospace,monospace"><br></div><div class=3D"g=
mail_default" style=3D"font-family:monospace,monospace">The problem seems t=
o be documented in the Emacs event design.</div><div class=3D"gmail_default=
" style=3D"font-family:monospace,monospace">Frame selection events are defe=
rred when they occur while a button</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace">is depressed to prevent some kind of s=
tate inconsistency.=C2=A0 But as</div><div class=3D"gmail_default" style=3D=
"font-family:monospace,monospace">a result, the drag release event records =
the wrong frame and there</div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace">is no way for the release binding to determine a=
nd record the right</div><div class=3D"gmail_default" style=3D"font-family:=
monospace,monospace">one.</div><div class=3D"gmail_default" style=3D"font-f=
amily:monospace,monospace"><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D""><br></span>
Take the position of the event-end (if it&#39;s a frame) and translate it<b=
r>
into absolute screen coordinates (the Elisp manual should give you<br>
enough clues to do that).=C2=A0 Or, try =E2=80=98mouse-absolute-pixel-posit=
ion<wbr>=E2=80=99 - it<br>
should give you the screen position of the mouse at that time so you can<br=
>
ignore the event completely.<br>
<br>
Then walk all your windows and compare that position with whatever<br>
=E2=80=98window-absolute-pixel-edges=E2=80=99 returns for that window.=C2=
=A0 If you have two<br>
or more positives, run =E2=80=98frame-list-z-order=E2=80=99 and compare the=
 result<br>
against those windows&#39; frames.=C2=A0 No hands, IMHO.</blockquote><div><=
br></div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp=
ace">=E2=80=8Bframe-list-z-order is Emacs 26 only; I need something that wo=
rks with older versions.=E2=80=8B</div><div class=3D"gmail_default" style=
=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_default"=
 style=3D"font-family:monospace,monospace">Bob</div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace,monospace"><br></div></div><br></div><=
/div>

--f403045ee8569d99d7055a6f3978--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 27 Sep 2017 15:44:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 27 11:44:53 2017
Received: from localhost ([127.0.0.1]:35172 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1dxEW4-0001Eo-RW
	for submit <at> debbugs.gnu.org; Wed, 27 Sep 2017 11:44:53 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49983)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1dxEW3-0001EQ-7V
 for submit <at> debbugs.gnu.org; Wed, 27 Sep 2017 11:44:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dxEVw-0007GL-5G
 for submit <at> debbugs.gnu.org; Wed, 27 Sep 2017 11:44:46 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,HTML_MESSAGE,
 RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:51377)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <rsw@HIDDEN>) id 1dxEVw-0007Fx-0c
 for submit <at> debbugs.gnu.org; Wed, 27 Sep 2017 11:44:44 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40953)
 by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dxEVt-0001Az-Lc
 for bug-gnu-emacs@HIDDEN; Wed, 27 Sep 2017 11:44:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1dxEVq-00077b-8O
 for bug-gnu-emacs@HIDDEN; Wed, 27 Sep 2017 11:44:41 -0400
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54722)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1dxEVq-00077P-3U
 for bug-gnu-emacs@HIDDEN; Wed, 27 Sep 2017 11:44:38 -0400
Received: from mail-qk0-f177.google.com ([209.85.220.177]:48562)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1dxEVp-0004OQ-Qg
 for bug-gnu-emacs@HIDDEN; Wed, 27 Sep 2017 11:44:37 -0400
Received: by mail-qk0-f177.google.com with SMTP id a128so13718886qkc.5
 for <bug-gnu-emacs@HIDDEN>; Wed, 27 Sep 2017 08:44:37 -0700 (PDT)
X-Gm-Message-State: AHPjjUjrCFLRQBBpujFdJRHn1zRWB/I/rznRKm3joFyLI4Do3HoZHJJl
 YCKcLCDvUUY5QdWDEGE8fz5lSpcQIAGMqjkX1yQ=
X-Google-Smtp-Source: AOwi7QA1zoLoYdmlHExYutYIz3hj5XgGCe8h/qCzynYxo7zTYdJ0ZO9vT2dMU/tTBsa1SuVHffNHm0VeULQWpZg8cO4=
X-Received: by 10.55.19.228 with SMTP id 97mr1816371qkt.271.1506527077064;
 Wed, 27 Sep 2017 08:44:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.28.3 with HTTP; Wed, 27 Sep 2017 08:44:06 -0700 (PDT)
From: Robert Weiner <rsw@HIDDEN>
Date: Wed, 27 Sep 2017 11:44:06 -0400
X-Gmail-Original-Message-ID: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
Message-ID: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
Subject: Mouse drag event records wrong window for release when crossing frames
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary="001a113fe9f045e485055a2dab4b"
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://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: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: rswgnu@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.5 (----)

--001a113fe9f045e485055a2dab4b
Content-Type: text/plain; charset="UTF-8"

With Emacs 25.3 under MacOS 10.12, a drag with mouse-1 depressed from
the text area of frame F1 to the text area of frame F2 improperly
generates a drag event whose (posn-window (event-end <event>)) shows
F1 rather than F2.

Note that for a drag between frames, posn-window should return a frame
(according to the Elisp manual but not its own doc string).  The bug is
that the event itself records the wrong frame (the depress frame rather
than the release frame).

I have confirmed this with Emacs 25.2 under Windows 7 as well.

Bob


In GNU Emacs 25.3.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version
10.9.5 (Build 13F1911))
 of 2017-09-12 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  recentf-mode: t
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  desktop-save-mode: t
  winner-mode: t
  which-key-mode: t
  show-paren-mode: t
  which-function-mode: t
  persistent-scratch-autosave-mode: t
  paredit-everywhere-mode: t
  dynamic-completion-mode: t
  global-edit-server-edit-mode: t
  delete-selection-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  auto-compile-mode: t
  outline-minor-mode: t
  minibuffer-depth-indicate-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Features:
(shadow mail-extr emacsbug tabify man magit-utils crm pulse glasses
cus-start cus-load mule-diag ispell filecache two-column iso-transl
debug recentf tree-widget helm-x-files helm-for-files helm-bookmark
helm-adaptive helm-info bookmark helm-external helm-net helm-files
image-dired ffap helm-tags helm-locate tramp tramp-compat tramp-loaddefs
trampver eieio-opt speedbar sb-image ezimage dframe helm-buffers
helm-grep helm-regexp helm-utils helm-help helm-types thai-util
thai-word misearch multi-isearch pcmpl-unix pcmpl-gnu shell dired-aux
grep hywconfig network-stream nsm starttls web-beautify org-element
org-rmail org-mhe org-irc org-info org-gnus org-docview org-bibtex
bibtex org-bbdb org-w3m doc-view arc-mode archive-mode eww mm-url gnus
gnus-ems nnheader wid-edit url-queue shr dom texinfo make-mode
skewer-html markdown-mode color sh-script smie executable rst conf-mode
tern-auto-complete tern jsdock helm-dash cursor-sensor image-mode
flycheck rx flymake jedi auto-complete popup jedi-core
python-environment epc ctable concurrent deferred pydock pydoc goto-addr
autorevert filenotify vc-git diff-mode .emacs desktop frameset
window-jump winner which-key supercite regi sort skewer-setup
skewer-mode cache-table js2-mode js cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs simple-httpd pp
json map python-mode compile thingatpt aggressive-indent paren
which-func imenu persistent-scratch js-lookup paredit-everywhere
paredit-menu paredit par-align rep-region id-edit wrect rect id-linecol
bw-tags apropos file-hdr lib site-key site-func id-keys id-vers
chrome-macos emmet-mode dired-x completion ido server edit-server delsel
jka-compr auto-compile packed dash hmouse-tag etags xref project
rsw-helm helm-easymenu helm edmacro kmacro helm-source eieio-compat
helm-multi-match helm-lib wdired async hyperbole hinit hibtypes
hib-doc-id hsys-www klink subr-x hib-kbd hib-social hib-debbugs
debbugs-gnu debbugs soap-client url-http tls gnutls url-auth url-gw
warnings rng-xsd rng-dt rng-util xsd-regexp hsys-org org org-macro
org-footnote org-pcomplete pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp
org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs find-func hactypes comint ansi-color hui-mini hui hui-mouse
hui-window hargs hui-menu hyrolo-menu hyrolo google-contacts xml
url-cache url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf mailcap url-util url-parse auth-source cl-seq
eieio url-vars google-oauth hmail hui-jmenu noutline outline easy-mmode
hmouse-key hmouse-sh hmouse-drv hypb locate hsettings hui-em-but hbut
hact hpath hhist hbdata htz cal-julian cal-menu calendar cal-loaddefs
hbmap hmoccur derived browse-url hui-select web-mode disp-table
sgml-mode hvar set hversion hload-path package-x mail-hist sendmail ring
message dired format-spec rfc822 mml mml-sec password-cache epg
gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-utils
gmm-utils mailheader rsw-evernote epic htmlize cl add-log
exec-path-from-shell finder-inf eieio-core cl-macs kotl-loaddefs
pydoc-info advice info-look info package epg-config seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv mb-depth edebug easymenu
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 1208296 206512)
 (symbols 48 87755 1)
 (miscs 40 9963 6750)
 (strings 32 234897 19520)
 (string-bytes 1 7230712)
 (vectors 16 99432)
 (vector-slots 8 2323157 242912)
 (floats 8 1648 1850)
 (intervals 56 53652 6347)
 (buffers 976 433))

--001a113fe9f045e485055a2dab4b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default"><div class=3D"gmail_default">=
<span style=3D"font-family:monospace,monospace">With Emacs 25.3 under MacOS=
 10.12, a drag with mouse-1 depressed from</span><br></div><div class=3D"gm=
ail_default"><font face=3D"monospace, monospace">the text area of frame F1 =
to the text area of frame F2 improperly</font></div><div class=3D"gmail_def=
ault"><font face=3D"monospace, monospace">generates=C2=A0</font><span style=
=3D"font-family:monospace,monospace">a drag event whose (posn-window (event=
-end &lt;event&gt;)) shows</span></div><div class=3D"gmail_default"><span s=
tyle=3D"font-family:monospace,monospace">F1 rather than F2.</span></div><di=
v class=3D"gmail_default"><font face=3D"monospace, monospace"><br></font></=
div><div class=3D"gmail_default"><font face=3D"monospace, monospace">Note t=
hat for a drag between frames, posn-window should return a frame</font></di=
v><div class=3D"gmail_default"><font face=3D"monospace, monospace">(accordi=
ng to the Elisp manual but not its own doc string).=C2=A0 The bug is</font>=
</div><div class=3D"gmail_default"><font face=3D"monospace, monospace">that=
 the event itself records the wrong frame (the depress frame rather</font><=
/div><div class=3D"gmail_default"><font face=3D"monospace, monospace">than =
the release frame).</font></div><div class=3D"gmail_default"><font face=3D"=
monospace, monospace"><br></font></div><div class=3D"gmail_default"><font f=
ace=3D"monospace, monospace">I have confirmed this with Emacs 25.2 under Wi=
ndows 7 as well.</font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace"><br></font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">Bob</font></div><div class=3D"gmail_default"><fon=
t face=3D"monospace, monospace"><br></font></div><div class=3D"gmail_defaul=
t"><font face=3D"monospace, monospace"><br></font></div><div class=3D"gmail=
_default"><font face=3D"monospace, monospace">In GNU Emacs 25.3.1 (x86_64-a=
pple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))</font>=
</div><div class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=
=A0of 2017-09-12 built on builder10-9.local</font></div><div class=3D"gmail=
_default"><font face=3D"monospace, monospace">Windowing system distributor =
&#39;Apple&#39;, version 10.3.1504</font></div><div class=3D"gmail_default"=
><font face=3D"monospace, monospace">Configured using:</font></div><div cla=
ss=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0&#39;configu=
re --with-ns &#39;--enable-locallisppath=3D/Library/Application</font></div=
><div class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0Sup=
port/Emacs/${version}/site-lisp:/Library/Application</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0Support/Emacs/=
site-lisp&#39; --with-modules&#39;</font></div><div class=3D"gmail_default"=
><font face=3D"monospace, monospace"><br></font></div><div class=3D"gmail_d=
efault"><font face=3D"monospace, monospace">Configured features:</font></di=
v><div class=3D"gmail_default"><font face=3D"monospace, monospace">NOTIFY A=
CL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES</font></div><div clas=
s=3D"gmail_default"><font face=3D"monospace, monospace"><br></font></div><d=
iv class=3D"gmail_default"><font face=3D"monospace, monospace">Important se=
ttings:</font></div><div class=3D"gmail_default"><font face=3D"monospace, m=
onospace">=C2=A0 value of $LANG: en_US.UTF-8</font></div><div class=3D"gmai=
l_default"><font face=3D"monospace, monospace">=C2=A0 locale-coding-system:=
 utf-8-unix</font></div><div class=3D"gmail_default"><font face=3D"monospac=
e, monospace"><br></font></div><div class=3D"gmail_default"><font face=3D"m=
onospace, monospace">Major mode: Emacs-Lisp</font></div><div class=3D"gmail=
_default"><font face=3D"monospace, monospace"><br></font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">Minor modes in effec=
t:</font></div><div class=3D"gmail_default"><font face=3D"monospace, monosp=
ace">=C2=A0 recentf-mode: t</font></div><div class=3D"gmail_default"><font =
face=3D"monospace, monospace">=C2=A0 shell-dirtrack-mode: t</font></div><di=
v class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 diff-a=
uto-refine-mode: t</font></div><div class=3D"gmail_default"><font face=3D"m=
onospace, monospace">=C2=A0 desktop-save-mode: t</font></div><div class=3D"=
gmail_default"><font face=3D"monospace, monospace">=C2=A0 winner-mode: t</f=
ont></div><div class=3D"gmail_default"><font face=3D"monospace, monospace">=
=C2=A0 which-key-mode: t</font></div><div class=3D"gmail_default"><font fac=
e=3D"monospace, monospace">=C2=A0 show-paren-mode: t</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 which-functio=
n-mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace,=
 monospace">=C2=A0 persistent-scratch-autosave-mode: t</font></div><div cla=
ss=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 paredit-eve=
rywhere-mode: t</font></div><div class=3D"gmail_default"><font face=3D"mono=
space, monospace">=C2=A0 dynamic-completion-mode: t</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 global-edit-s=
erver-edit-mode: t</font></div><div class=3D"gmail_default"><font face=3D"m=
onospace, monospace">=C2=A0 delete-selection-mode: t</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 auto-compile-=
on-load-mode: t</font></div><div class=3D"gmail_default"><font face=3D"mono=
space, monospace">=C2=A0 auto-compile-on-save-mode: t</font></div><div clas=
s=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 auto-compile=
-mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace, =
monospace">=C2=A0 outline-minor-mode: t</font></div><div class=3D"gmail_def=
ault"><font face=3D"monospace, monospace">=C2=A0 minibuffer-depth-indicate-=
mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace, m=
onospace">=C2=A0 tooltip-mode: t</font></div><div class=3D"gmail_default"><=
font face=3D"monospace, monospace">=C2=A0 global-eldoc-mode: t</font></div>=
<div class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 eld=
oc-mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace=
, monospace">=C2=A0 electric-indent-mode: t</font></div><div class=3D"gmail=
_default"><font face=3D"monospace, monospace">=C2=A0 mouse-wheel-mode: t</f=
ont></div><div class=3D"gmail_default"><font face=3D"monospace, monospace">=
=C2=A0 menu-bar-mode: t</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">=C2=A0 file-name-shadow-mode: t</font></div><div =
class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 global-f=
ont-lock-mode: t</font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">=C2=A0 font-lock-mode: t</font></div><div class=3D"gmail=
_default"><font face=3D"monospace, monospace">=C2=A0 blink-cursor-mode: t</=
font></div><div class=3D"gmail_default"><font face=3D"monospace, monospace"=
>=C2=A0 auto-composition-mode: t</font></div><div class=3D"gmail_default"><=
font face=3D"monospace, monospace">=C2=A0 auto-encryption-mode: t</font></d=
iv><div class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 =
auto-compression-mode: t</font></div><div class=3D"gmail_default"><font fac=
e=3D"monospace, monospace">=C2=A0 column-number-mode: t</font></div><div cl=
ass=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 line-numbe=
r-mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace,=
 monospace">=C2=A0 auto-fill-function: do-auto-fill</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0 transient-mar=
k-mode: t</font></div><div class=3D"gmail_default"><font face=3D"monospace,=
 monospace"><br></font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">Features:</font></div><div class=3D"gmail_default"><font=
 face=3D"monospace, monospace">(shadow mail-extr emacsbug tabify man magit-=
utils crm pulse glasses</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">cus-start cus-load mule-diag ispell filecache two=
-column iso-transl</font></div><div class=3D"gmail_default"><font face=3D"m=
onospace, monospace">debug recentf tree-widget helm-x-files helm-for-files =
helm-bookmark</font></div><div class=3D"gmail_default"><font face=3D"monosp=
ace, monospace">helm-adaptive helm-info bookmark helm-external helm-net hel=
m-files</font></div><div class=3D"gmail_default"><font face=3D"monospace, m=
onospace">image-dired ffap helm-tags helm-locate tramp tramp-compat tramp-l=
oaddefs</font></div><div class=3D"gmail_default"><font face=3D"monospace, m=
onospace">trampver eieio-opt speedbar sb-image ezimage dframe helm-buffers<=
/font></div><div class=3D"gmail_default"><font face=3D"monospace, monospace=
">helm-grep helm-regexp helm-utils helm-help helm-types thai-util</font></d=
iv><div class=3D"gmail_default"><font face=3D"monospace, monospace">thai-wo=
rd misearch multi-isearch pcmpl-unix pcmpl-gnu shell dired-aux</font></div>=
<div class=3D"gmail_default"><font face=3D"monospace, monospace">grep hywco=
nfig network-stream nsm starttls web-beautify org-element</font></div><div =
class=3D"gmail_default"><font face=3D"monospace, monospace">org-rmail org-m=
he org-irc org-info org-gnus org-docview org-bibtex</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">bibtex org-bbdb org-=
w3m doc-view arc-mode archive-mode eww mm-url gnus</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">gnus-ems nnheader wi=
d-edit url-queue shr dom texinfo make-mode</font></div><div class=3D"gmail_=
default"><font face=3D"monospace, monospace">skewer-html markdown-mode colo=
r sh-script smie executable rst conf-mode</font></div><div class=3D"gmail_d=
efault"><font face=3D"monospace, monospace">tern-auto-complete tern jsdock =
helm-dash cursor-sensor image-mode</font></div><div class=3D"gmail_default"=
><font face=3D"monospace, monospace">flycheck rx flymake jedi auto-complete=
 popup jedi-core</font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">python-environment epc ctable concurrent deferred pydock=
 pydoc goto-addr</font></div><div class=3D"gmail_default"><font face=3D"mon=
ospace, monospace">autorevert filenotify vc-git diff-mode .emacs desktop fr=
ameset</font></div><div class=3D"gmail_default"><font face=3D"monospace, mo=
nospace">window-jump winner which-key supercite regi sort skewer-setup</fon=
t></div><div class=3D"gmail_default"><font face=3D"monospace, monospace">sk=
ewer-mode cache-table js2-mode js cc-mode cc-fonts cc-guess cc-menus</font>=
</div><div class=3D"gmail_default"><font face=3D"monospace, monospace">cc-c=
mds cc-styles cc-align cc-engine cc-vars cc-defs simple-httpd pp</font></di=
v><div class=3D"gmail_default"><font face=3D"monospace, monospace">json map=
 python-mode compile thingatpt aggressive-indent paren</font></div><div cla=
ss=3D"gmail_default"><font face=3D"monospace, monospace">which-func imenu p=
ersistent-scratch js-lookup paredit-everywhere</font></div><div class=3D"gm=
ail_default"><font face=3D"monospace, monospace">paredit-menu paredit par-a=
lign rep-region id-edit wrect rect id-linecol</font></div><div class=3D"gma=
il_default"><font face=3D"monospace, monospace">bw-tags apropos file-hdr li=
b site-key site-func id-keys id-vers</font></div><div class=3D"gmail_defaul=
t"><font face=3D"monospace, monospace">chrome-macos emmet-mode dired-x comp=
letion ido server edit-server delsel</font></div><div class=3D"gmail_defaul=
t"><font face=3D"monospace, monospace">jka-compr auto-compile packed dash h=
mouse-tag etags xref project</font></div><div class=3D"gmail_default"><font=
 face=3D"monospace, monospace">rsw-helm helm-easymenu helm edmacro kmacro h=
elm-source eieio-compat</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">helm-multi-match helm-lib wdired async hyperbole =
hinit hibtypes</font></div><div class=3D"gmail_default"><font face=3D"monos=
pace, monospace">hib-doc-id hsys-www klink subr-x hib-kbd hib-social hib-de=
bbugs</font></div><div class=3D"gmail_default"><font face=3D"monospace, mon=
ospace">debbugs-gnu debbugs soap-client url-http tls gnutls url-auth url-gw=
</font></div><div class=3D"gmail_default"><font face=3D"monospace, monospac=
e">warnings rng-xsd rng-dt rng-util xsd-regexp hsys-org org org-macro</font=
></div><div class=3D"gmail_default"><font face=3D"monospace, monospace">org=
-footnote org-pcomplete pcomplete org-list org-faces org-entities</font></d=
iv><div class=3D"gmail_default"><font face=3D"monospace, monospace">org-ver=
sion ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp</font></div><=
div class=3D"gmail_default"><font face=3D"monospace, monospace">org-src ob-=
keys ob-comint ob-core ob-eval org-compat org-macs</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">org-loaddefs find-fu=
nc hactypes comint ansi-color hui-mini hui hui-mouse</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">hui-window hargs hui=
-menu hyrolo-menu hyrolo google-contacts xml</font></div><div class=3D"gmai=
l_default"><font face=3D"monospace, monospace">url-cache url url-proxy url-=
privacy url-expand url-methods url-history</font></div><div class=3D"gmail_=
default"><font face=3D"monospace, monospace">url-cookie url-domsuf mailcap =
url-util url-parse auth-source cl-seq</font></div><div class=3D"gmail_defau=
lt"><font face=3D"monospace, monospace">eieio url-vars google-oauth hmail h=
ui-jmenu noutline outline easy-mmode</font></div><div class=3D"gmail_defaul=
t"><font face=3D"monospace, monospace">hmouse-key hmouse-sh hmouse-drv hypb=
 locate hsettings hui-em-but hbut</font></div><div class=3D"gmail_default">=
<font face=3D"monospace, monospace">hact hpath hhist hbdata htz cal-julian =
cal-menu calendar cal-loaddefs</font></div><div class=3D"gmail_default"><fo=
nt face=3D"monospace, monospace">hbmap hmoccur derived browse-url hui-selec=
t web-mode disp-table</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">sgml-mode hvar set hversion hload-path package-x =
mail-hist sendmail ring</font></div><div class=3D"gmail_default"><font face=
=3D"monospace, monospace">message dired format-spec rfc822 mml mml-sec pass=
word-cache epg</font></div><div class=3D"gmail_default"><font face=3D"monos=
pace, monospace">gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231=
 rfc2047</font></div><div class=3D"gmail_default"><font face=3D"monospace, =
monospace">rfc2045 ietf-drums mm-util help-fns mail-prsvr mailabbrev mail-u=
tils</font></div><div class=3D"gmail_default"><font face=3D"monospace, mono=
space">gmm-utils mailheader rsw-evernote epic htmlize cl add-log</font></di=
v><div class=3D"gmail_default"><font face=3D"monospace, monospace">exec-pat=
h-from-shell finder-inf eieio-core cl-macs kotl-loaddefs</font></div><div c=
lass=3D"gmail_default"><font face=3D"monospace, monospace">pydoc-info advic=
e info-look info package epg-config seq byte-opt gv</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">bytecomp byte-compil=
e cl-extra help-mode cconv mb-depth edebug easymenu</font></div><div class=
=3D"gmail_default"><font face=3D"monospace, monospace">cl-loaddefs pcase cl=
-lib time-date mule-util tooltip eldoc electric</font></div><div class=3D"g=
mail_default"><font face=3D"monospace, monospace">uniquify ediff-hook vc-ho=
oks lisp-float-type mwheel ns-win ucs-normalize</font></div><div class=3D"g=
mail_default"><font face=3D"monospace, monospace">term/common-win tool-bar =
dnd fontset image regexp-opt fringe</font></div><div class=3D"gmail_default=
"><font face=3D"monospace, monospace">tabulated-list newcomment elisp-mode =
lisp-mode prog-mode register page</font></div><div class=3D"gmail_default">=
<font face=3D"monospace, monospace">menu-bar rfn-eshadow timer select scrol=
l-bar mouse jit-lock font-lock</font></div><div class=3D"gmail_default"><fo=
nt face=3D"monospace, monospace">syntax facemenu font-core frame cl-generic=
 cham georgian utf-8-lang</font></div><div class=3D"gmail_default"><font fa=
ce=3D"monospace, monospace">misc-lang vietnamese tibetan thai tai-viet lao =
korean japanese eucjp-ms</font></div><div class=3D"gmail_default"><font fac=
e=3D"monospace, monospace">cp51932 hebrew greek romanian slovak czech europ=
ean ethiopic indian</font></div><div class=3D"gmail_default"><font face=3D"=
monospace, monospace">cyrillic chinese charscript case-table epa-hook jka-c=
mpr-hook help</font></div><div class=3D"gmail_default"><font face=3D"monosp=
ace, monospace">simple abbrev minibuffer cl-preloaded nadvice loaddefs butt=
on faces</font></div><div class=3D"gmail_default"><font face=3D"monospace, =
monospace">cus-face macroexp files text-properties overlay sha1 md5 base64 =
format</font></div><div class=3D"gmail_default"><font face=3D"monospace, mo=
nospace">env code-pages mule custom widget hashtable-print-readable backquo=
te</font></div><div class=3D"gmail_default"><font face=3D"monospace, monosp=
ace">kqueue cocoa ns multi-tty make-network-process emacs)</font></div><div=
 class=3D"gmail_default"><font face=3D"monospace, monospace"><br></font></d=
iv><div class=3D"gmail_default"><font face=3D"monospace, monospace">Memory =
information:</font></div><div class=3D"gmail_default"><font face=3D"monospa=
ce, monospace">((conses 16 1208296 206512)</font></div><div class=3D"gmail_=
default"><font face=3D"monospace, monospace">=C2=A0(symbols 48 87755 1)</fo=
nt></div><div class=3D"gmail_default"><font face=3D"monospace, monospace">=
=C2=A0(miscs 40 9963 6750)</font></div><div class=3D"gmail_default"><font f=
ace=3D"monospace, monospace">=C2=A0(strings 32 234897 19520)</font></div><d=
iv class=3D"gmail_default"><font face=3D"monospace, monospace">=C2=A0(strin=
g-bytes 1 7230712)</font></div><div class=3D"gmail_default"><font face=3D"m=
onospace, monospace">=C2=A0(vectors 16 99432)</font></div><div class=3D"gma=
il_default"><font face=3D"monospace, monospace">=C2=A0(vector-slots 8 23231=
57 242912)</font></div><div class=3D"gmail_default"><font face=3D"monospace=
, monospace">=C2=A0(floats 8 1648 1850)</font></div><div class=3D"gmail_def=
ault"><font face=3D"monospace, monospace">=C2=A0(intervals 56 53652 6347)</=
font></div><div class=3D"gmail_default"><font face=3D"monospace, monospace"=
>=C2=A0(buffers 976 433))</font></div><div style=3D"font-family:monospace,m=
onospace"><br></div></div></div>

--001a113fe9f045e485055a2dab4b--




Acknowledgement sent to rswgnu@HIDDEN:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#28620; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Thu, 19 Oct 2017 18:45:01 UTC

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