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; 4 Aug 2019 07:59:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Aug 04 03:59:56 2019
Received: from localhost ([127.0.0.1]:60381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1huBQp-0002nI-PV
	for submit <at> debbugs.gnu.org; Sun, 04 Aug 2019 03:59:56 -0400
Received: from mout.gmx.net ([212.227.15.19]:60287)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>)
 id 1huBQo-0002n3-Ku; Sun, 04 Aug 2019 03:59:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1564905582;
 bh=vYXTYKyJxRFKYE7/aX1T8klEoyC0Td3DamqRdd+3aQg=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=IUiX1/ysmkplUp8DGNdj5vkhh15c2yqTlxpszILYRTetT/EHZ2/AXX3cSYLRPt+Kt
 DnYdYCjgJ6Jgdv+iq2Tc78HXlzDJqUljkFuDmWnBLaf2B+5gt36v6dOGp9do8nhrZG
 TGFP3DJN7ByZDt9SVwpkytHrw7+xKurnK7u9ooa8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.101] ([213.142.96.135]) by mail.gmx.com (mrgmx004
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MRTRH-1hgDRw3f3F-00NQ5X; Sun, 04
 Aug 2019 09:59:41 +0200
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
To: Eli Zaretskii <eliz@HIDDEN>
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> <8336irn617.fsf@HIDDEN>
 <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN> <83ftmiebja.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <87b36360-28b3-0b00-a8ee-6e09b750d4a7@HIDDEN>
Date: Sun, 4 Aug 2019 09:59:40 +0200
MIME-Version: 1.0
In-Reply-To: <83ftmiebja.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:LqvrVnRT2xdq0NVOs0gTG6AIYLHLC7jZHm7f+nZuhNuXO5rU91X
 +3Y2drcE5mHZzybamhFag2GdMI9dOTWMcKl3XOa59TlJ8IbbfGbHSNz7fwdKPQB5fxE4cJ0
 AP4U5GQFRuiGA5ELMJ+OQBeBzkxKdH419HNAmN8q7I3ZRdMrUE/Xf8iiJuM0esEoFn1KfVb
 iY+G2dbjnTm6XaLAlAi8w==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:cCkZBelkWQY=:USq/zVcHU9BbPVilM2C9kR
 DNQvjvoaOL7cTFyuHU6pGPhpu14xpqw7bccfR0pkVi8PIHw2gd45MuFebw/yX81CEjj1E6PII
 3jE6fSmYijoOnAnB2w1BM6ar5nuYeXn2QTi+LmCViZZoE0MZ4W8mP5/GH8sPiuONVg/969Phk
 NMlJ9rMmNqXqQXWXI4NNuXNHresAxwpOqMtZ4rMFcFEMkmen99TtxUr+VqsxSjksKkBS9tdsP
 wk3snRskx78MOFMGOFVeogTfok0iIKrSYRR14sy0qDjQJuMKqfS0DEbbkKIZFuMYgFGkpd+4a
 rSC57mPIJRmquG3ICy5amkbhfMfJ+Y52AzpGAXtmX3sroG7m90enLY7gpoW5AFoLlUkzjLTiE
 F55VFPCOozlNAcqy9ouDFXKEMk+Fwq2hvQh6oFHf0Q/RYBlebBeUE00ebX9aSSJ39/P+1YC+/
 Cry1Nkf6MuP9aqgxHuBELjo0miJL7D2iSnnUkE90O1H1Y1VgaruZeYa+wVRMsOaUmBqBtjgmG
 rE1vSCCYIdRvxpAcJUmoPVymcjhBpU1sVm6SdOeSvTyBN+m9RnxUDx+4oKzU7bzr13ZBT0Klx
 3/+7IXNqJcChtZF7CjbILt33f5FuTcDrbdXLTbJZAphiiu3h5L7B0HPmSwtEu77bByrq5rOQN
 o6WF9BUMMXN/EucM3qrA4F2G80cPbB9Rmcpe0cQSt1v44fE5mEb1Xd7bv/Vrk6LKAvsC+SV1n
 FAOxpzD4dVqS9z61vs/PIk3A5dTNrp+1sV53ceSBapoZDaEw+W1t57uGUKoI4VsJ2HKVzflvI
 lJHcN5zeT4LZW2i/We9AmzrzJJI5Eq2dYHtzo1uw7Fsc+aK8c78drUpN2VxpY2v3tdAL1nJMN
 svPI0L9Aqdag6UiyBZSdRz3k9Q7LdPk3R4N7zB8agiaz28FR9O80IRakhSuu5Imo0Tc9D8bec
 KrlsHAry24K7x/kLaMk0UkfgDzjncl4amwX4jdGy7t0VD6WNLhybU9FJh6db7wI3nNzQBRh6c
 xDGkPFEgIe9gh3yzFaGADjXXMdLPR9KaWyxBtg4YUNZp/NkVThMu5RYp3XxEnETHUt/e7wZb2
 fE9VxH25EzWvzemHnT4E6017iJtrtB6TAQZdxBmhciTJDklJs1C0oHRJ76qUWhYWPeJ3zfHdw
 qUaB4=
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 28620
Cc: rswgnu@HIDDEN, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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: -1.0 (-)

 > I think you should push this to master, and we will have enough time
 > before the release to see if there are any problems with it.

Done.  Let's see what it breaks.

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; 3 Aug 2019 11:25:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Aug 03 07:25:43 2019
Received: from localhost ([127.0.0.1]:58367 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1htsAQ-0005JB-Ne
	for submit <at> debbugs.gnu.org; Sat, 03 Aug 2019 07:25:42 -0400
Received: from eggs.gnu.org ([209.51.188.92]:33607)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>)
 id 1htsAM-0005Ir-BD; Sat, 03 Aug 2019 07:25:39 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:55746)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1htsAG-0002Rv-O0; Sat, 03 Aug 2019 07:25:32 -0400
Received: from [176.228.60.248] (port=4927 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 1htsA5-0008Ip-AZ; Sat, 03 Aug 2019 07:25:23 -0400
Date: Sat, 03 Aug 2019 14:25:13 +0300
Message-Id: <83ftmiebja.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
In-reply-to: <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN> (message from
 martin rudalics on Sun, 28 Jul 2019 09:34:00 +0200)
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> <8336irn617.fsf@HIDDEN>
 <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 28620
Cc: rswgnu@HIDDEN, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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.3 (---)

> Cc: rswgnu@HIDDEN, 28620 <at> debbugs.gnu.org, 36269 <at> debbugs.gnu.org,
>  scotto@HIDDEN
> From: martin rudalics <rudalics@HIDDEN>
> Date: Sun, 28 Jul 2019 09:34:00 +0200
> 
>  > There's too much of whitespace changes in the rest of the patch,
>  > making it very hard to review.  Can you show the patch without
>  > whitespace differences?
> 
> I attach a patch which re-adds some extraneous braces to w32term.c.

Thanks, that helped a lot.

> Also, I do not intend to push the changes until someone tells me that
> they work.  I neither use the mouse to drop nor mouse avoidance mode
> and so have never given it any serious testing.

I think you should push this to master, and we will have enough time
before the release to see if there are any problems with it.

Thanks.




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 Jul 2019 07:00:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 30 03:00:40 2019
Received: from localhost ([127.0.0.1]:49446 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hsM7k-0002ji-2U
	for submit <at> debbugs.gnu.org; Tue, 30 Jul 2019 03:00:40 -0400
Received: from mout.gmx.net ([212.227.17.21]:47533)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>)
 id 1hsM7h-0002jP-QV; Tue, 30 Jul 2019 03:00:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1564470020;
 bh=Eb5wp0EbQ4iUlojnNnPDvNSot32KWfUdWBdxHsH1hYs=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=ZccuSIHumQJipxDNXT7kuka4uGIcLHvAK1x/ORCS2DtQ5QIySaBI+gBLJI2FdGVU1
 chjqRdg/Y05NYNpo3r2Jq4eJJyanLiDbJYMbaXCMt7xOZZtLda4B8iJGe7Fef+5NJw
 MENhG7gDt1WVT+fXzIUvfmMZLN2Qqtqw0/sHiRwM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.101] ([212.95.5.43]) by mail.gmx.com (mrgmx102
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MLR30-1hrnt81Cio-000bXt; Tue, 30
 Jul 2019 09:00:20 +0200
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
To: Robert Weiner <rswgnu@HIDDEN>
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> <8336irn617.fsf@HIDDEN>
 <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN>
 <B8523E3F-B1E7-4F0B-A9B9-4C2F05B92DA3@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <b38a68bd-e1d1-3ef3-ec07-a0b84348e11d@HIDDEN>
Date: Tue, 30 Jul 2019 09:00:17 +0200
MIME-Version: 1.0
In-Reply-To: <B8523E3F-B1E7-4F0B-A9B9-4C2F05B92DA3@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:d0NocdFEFtBH0mSzrAaL8ICzGVrrxbeF1OGxibM+mtWpLKJWNE7
 ru+5ksuB7xvT1mpNM1eAv9lBf/7lfY/Wo6JeVDc35wc9X8C26Gbpo66QQ2jTyyE2U7aNotA
 StpShhc4l50geZYbgvqlh90X0AVqsqKgvbk3OJz+IZwStajUf2EgxhprQGambnWCU1YLjHe
 wCjh++xIWV+Sc/zMA8z6g==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:YnTTqSITiHI=:skBP7HHxtcKNxbL/0Jbvtc
 DRFHJUcGvuzs/UznjM2mvWJMJ9wJswxWtD8IAOkO1ofZfeD2j2HkwNlIRr6izSP7ML68SIlxl
 gTLlQNtUh4fpwP9ju6H1qyhJJCAAd8vOWg1q8tjDG9LkQwApOLFVSLk9BW1jcBnLAC5nCFvKP
 0FnUHoJE6thq/Y+IrOpDe6q57Dxnw3ng8ACUFbFmWXJiJbckDgKpMKi946C+nhYXftShqV1cc
 yLq8VJUjSMLGzx1m75CVVCSa4MOpuE59PNH0KGZ8u3nYhRL+qWA5EXqc37N4za11yFWDEoVpb
 E9je7R22uFVRUB8n77TM+p5IIme3T9Y6lgGm/4Wl+8UN78LN4cqwOEOaRYH1kmzhbwG3Lt6Zc
 04XGOeyP7pFCaqy2HYmRpFYplKztH9fFV/pYdUvXOrtJbyusOAebeL6mkahoHdF5nMf7yHp/2
 FeiRFRhuJMQpnUUHuuy0Ukye87XJt/58xUXTvmOtK4Mvu41wX6aajsqTQ4su87vUVSf6SbtB6
 Br41u0unBZbQ1UkvOgBrrivfH0OGAoF4KD/p49xgUGGYlS5wamTZTa3OCU8aVbFxOzfDFTFnO
 dixvB3WxY+QSQ7PC0kC8mmcHPO+oU06kRUH8/SOkTkNqMGO1i/DTfnesGLQFqfm5+8pI1OlzM
 t6J6iswTAL8lN8JFg6pvO5GpU0UkuZFdAQnu761GzfeeNVR8Nr4tameRyafphs+bFfrbwIS9n
 bpRCrDftmJUVvPiDfVwuDgvFmEj9gCDE+o1A7AL/aUJrwfAtfdqN51LnBY+iK+qvesE30VmLM
 L9zD1lguBK/exz6se4NJ/cfQcLgJKgWc648twzGs3QY9pIMvnqE9w/78tan/evJjFPzJFb3n+
 JELi2jvUE1ErHYXOEIpqVVNFk9peA1zvIW9hFR7ZP5ROBw4lgCipS90hoffRyER9kmBPmZTFm
 UdGeSp9GhLI0FeXrKackKB63QBu/0OfyWFTmNGbCRbLB+Fq4JQapNhKYaXZDQ+3kW/I4orXbf
 T16keQPJiPYmNjVdSK0Vqp09xJ5wS847XNgYP/Vb4yLAiLSKQ/LrFFA0hHDhgv9wixtkqZMIz
 4O1SPnBNxn9pkDWNolwRmbly7zLtuw3plWx
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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: -1.7 (-)

 > I don=E2=80=99t have much time these days but will try to test it next=

 > weekend.  I use do use MacOS sometimes, so I can test there.

Your original report just turned two years old so there really is
no hurry ...

Thanks in advance, 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; 29 Jul 2019 23:21:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 29 19:21:43 2019
Received: from localhost ([127.0.0.1]:49314 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hsExa-0005e1-Qm
	for submit <at> debbugs.gnu.org; Mon, 29 Jul 2019 19:21:43 -0400
Received: from mail-qk1-f196.google.com ([209.85.222.196]:40351)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rswgnu@HIDDEN>)
 id 1hsExY-0005dc-D9; Mon, 29 Jul 2019 19:21:40 -0400
Received: by mail-qk1-f196.google.com with SMTP id s145so45277487qke.7;
 Mon, 29 Jul 2019 16:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=4I3Q2rBgwYziIOJtm0w7S8M4qOJadrtwHWKtDHPSao4=;
 b=oYloeKHcE+NiOCcrXsO6TDxaFcBza/RCpuO2Bk09Y0oBXDan6CbmbRbPCLtSZdfOK+
 w4b+9FM0ZYyUHFVBUigINoPsbLLUJfHJQIp5OpDxyIIAIBoCsxazgiclwqwNo6Zstydv
 RBROYOwY+9yAiIXtr6NA7rpC5zkj5lxXinj/dQt/p3KodTDpzakzYVj+vZHC6MfhEKgT
 OVDIoow8oUUlAcWIBk2YcstM1a17Q6qDyCkmYiAjOoxFH7CkbAyrvRBJIn/egWN6FGfp
 IQJ6o1ECWWC5vSJyxjvl8sFYKg/dwzOAqqUggzGmp/pK4AX/leGSED1CcM8ZWJvNqIYz
 Iz6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=4I3Q2rBgwYziIOJtm0w7S8M4qOJadrtwHWKtDHPSao4=;
 b=DqzvtxVcpmpBiDnfG7nifRfRTmeqqv34T+Mm5vrMyeS0LloGzMGrZR/R+GDdTIyTsg
 s/Pt760+TpU/Iww1199Uda/o70gvB+v4giUooLiXecS3+kObF/Y52Z1TG7LmWYFt+d+p
 OaEh+rIUz6W/YPMtRAkjnudRGDT385DDjtQV7ujgroBDPOv2SLDgrukgpHulGiUmUqh4
 BQutM0mirDIC0KZdTDBZ29fnUQXBNZ6cV2gTIln1PRTzQ5Fc2/3ACAVBnJ6ppC2eaqnk
 cY0scW4w9wNFe2Um2ea5UsPIWzjPnbxHGnQTS6py0Xp2XJyTCw5ScZI/vycVPlI6kCqS
 744w==
X-Gm-Message-State: APjAAAXVe401IxKuVz0kvh5Dc/C1AmoYMbqACuzQ3BjAPOgpaUaKxN8P
 Al6NlLkhJ0c92hsLZRUJeu4=
X-Google-Smtp-Source: APXvYqx+wyHfNUSUnPPa0XsMC2fgC+Tyf21Y45/YdUFzqqFllmgL/n5JPctNXlZCM2Y7qM0tWnKERA==
X-Received: by 2002:a05:620a:14ba:: with SMTP id
 x26mr74071910qkj.328.1564442494787; 
 Mon, 29 Jul 2019 16:21:34 -0700 (PDT)
Received: from ?IPv6:2600:1000:b107:7b33:109d:7796:455e:2146?
 ([2600:1000:b107:7b33:109d:7796:455e:2146])
 by smtp.gmail.com with ESMTPSA id i62sm28410981qke.52.2019.07.29.16.21.33
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 29 Jul 2019 16:21:34 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
From: Robert Weiner <rswgnu@HIDDEN>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN>
Date: Mon, 29 Jul 2019 19:21:28 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8523E3F-B1E7-4F0B-A9B9-4C2F05B92DA3@HIDDEN>
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> <8336irn617.fsf@HIDDEN>
 <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 28620
Cc: Eli Zaretskii <eliz@HIDDEN>, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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: -1.0 (-)

Martin:

I just want to say that this is an exciting fix and thank you for working on=
 it.  I don=E2=80=99t have much time these days but will try to test it next=
 weekend.  I use do use MacOS sometimes, so I can test there.

-- Bob

> On Jul 28, 2019, at 3:34 AM, martin rudalics <rudalics@HIDDEN> wrote:
>=20
> > Thanks, a few minor comments below.
>=20
> Thanks for the comments.  I hopefully applied all changes you
> proposed.
>=20
> Please keep in mind that I wrote the code almost two years ago and
> then forgot about it.  It's only in the context of Bug#36269 that I
> resurrected it - with all its inadequacies.
>=20
> >> @@ -3995,7 +3992,7 @@ kbd_buffer_get_event (KBOARD **kbp,
> >>         }
> >>       }
> >>     /* Try generating a mouse motion event.  */
> >> -  else if (!NILP (do_mouse_tracking) && some_mouse_moved ())
> >> +  else if (some_mouse_moved ())
> >
> > Can't we have mouse motion events outside track-mouse?
>=20
> Not to my knowledge.  In either case, I wouldn't want to change
> anything in this regard here.
>=20
> > There's too much of whitespace changes in the rest of the patch,
> > making it very hard to review.  Can you show the patch without
> > whitespace differences?
>=20
> I attach a patch which re-adds some extraneous braces to w32term.c.
> If you want me to restore more of the old code, please tell me.
>=20
> Also, I do not intend to push the changes until someone tells me that
> they work.  I neither use the mouse to drop nor mouse avoidance mode
> and so have never given it any serious testing.
>=20
> Thanks, martin
> <track-mouse-with-braces.diff>




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; 28 Jul 2019 07:34:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 28 03:34:23 2019
Received: from localhost ([127.0.0.1]:45688 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hrdhD-0007yF-RB
	for submit <at> debbugs.gnu.org; Sun, 28 Jul 2019 03:34:23 -0400
Received: from mout.gmx.net ([212.227.17.21]:55533)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>)
 id 1hrdhA-0007xi-QH; Sun, 28 Jul 2019 03:34:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1564299245;
 bh=33GO84EghBonLdfZxG6rC2j7MbWIEw3TvEAOl+tNY/c=;
 h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To;
 b=N85pRnxGKikDk8y+ynEO5AQYt0u9UiZ3nW4Bi9fNXNzor0MK4+0RtN/i4V1YhFhVT
 yRpaNqKzVbQjfwals3IH/hVIu+nYjEv+jWjnxzJ+vTa5t8kdZyG41dOWP9maDjwqSx
 QuMqaNFKrFvetf6ibJSn/VPjMDWaHoIgGseB6nIU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.101] ([212.95.5.130]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M7b2T-1hjfTV2vPx-0080lq; Sun, 28
 Jul 2019 09:34:04 +0200
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
To: Eli Zaretskii <eliz@HIDDEN>
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> <8336irn617.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <42eec0a5-2c91-aaab-a536-08f3157ca864@HIDDEN>
Date: Sun, 28 Jul 2019 09:34:00 +0200
MIME-Version: 1.0
In-Reply-To: <8336irn617.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------39FE6C27FE5DB683E2477899"
Content-Language: de-DE
X-Provags-ID: V03:K1:axf9ntRsxgdms2q9H/gzMm7wG6d99TPEPlR9aa+kh9IlhC7ImJ1
 sXAwOUHhRXUq+Mxjd94/dGE5JxaBy1hsiDPs8aaRhT60HCuVMzrIeQa5bIEc313tzudbF4C
 JBqjz848GEirkPqUtDxhFNAO+DE64fvR3gLWS0Oz287wDsMQUYGFh88gGc/U0H44h/Vq05Q
 9XsuLYCZ2GrgNgV6S6CYg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:ckY1jz07PjY=:mPbH/r8hy4guNPNsyfHQO7
 Xng1bjyxFojDCYwD2KUS726beOdhBH/SYjzN0NFcViePO8ogBl4D4ThvTwK0TFrhMTCOrnmqm
 DO68U9phgjnE6cvGiNakKB0qgWi2nrqOR25ug+HwaroaPXcwxN0hjYfI0MP/ya5oElsUOue5e
 HmzYhwbf3J8Uc2lZ7IFoAnvWUOFylhv4XffcsFd3Wbn4Td9yDBw+PnRW+tq+YOOmyv5fMx+eA
 hJkr98hik7hqvoqjNcRVdLjj2aU3nHDLjeQrbpYz4ePVQ7CODaLv9PxuS/R1TKM2eD2Yipgoy
 H62qogyahiwJ51IjbQrDpy1koosJUn1BWecZ6Xzf0iiAXw2i5oaa4LUtIzKT4W0Lzk2KVHeDQ
 z0IK3xaglW5XLcnZfqURKrMZT3F7OnnOt6rWMAGsS7nMwFiJqEDU7hDc4CxWq1e7R9+Oipv8K
 3UMCRjnPOChhhDN3cY4Bkd53e04FqvshG7SPPegVoJ6/AX85Mc4Lxjw+ls92kCfeL93PkFjsB
 axRIfqo28D2WgGGG8dqzewo1qa6qQLcVEvCgH2lcC0sDqtpcCvxhBPte3XB4qoX4pY7GArWXC
 6DafcWhWcYfoKI2oJyBgCrD290e0YflCXtkf0LcaUUFwtaSn5I9UTlriIH/PCw0UW7z9T9aa/
 +4m8vpxCjbA/2QMawCtrJnMu+I911H/3jWbekB4S3W4tz1ui5p5/856lqDykQnvTGYDbw8HPY
 wOAXXuXyL9sgDzjlOI+0Soa/a9oTqXyWGN97XtJ3+3Se0Bk/jpNaL6aa468hfiTsuS9Nro1wh
 fnutAaxYWoiiQL3Y9PYp9MZGhTcSI/c81ml7HybZrHN0NrDM6Ynw9JSF/njcGCkKmaLBAugvt
 D2T+IP81Q9NVwMHR+9hj0LIRtWK7VWS0kw4/rWe3q8dyLkTCWzBxhyaqjXTlcRUuQTQjxYfzP
 LbuG0w0Ood47Qxg54VEzQe8Fx+Ez4tUJj7cr/B+4/MebJ13hLc2SnedEQitmETdXNt0VOyu1e
 AdlEcsTGWeYDusPj7UFNP1wfO38UIDAAzb7gAY048ZKcPNKigLWt4kY/LFtw4/XWkoDaZqZMS
 hZNk90Es8NoxeU=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 28620
Cc: rswgnu@HIDDEN, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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: -1.7 (-)

This is a multi-part message in MIME format.
--------------39FE6C27FE5DB683E2477899
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

 > Thanks, a few minor comments below.

Thanks for the comments.  I hopefully applied all changes you
proposed.

Please keep in mind that I wrote the code almost two years ago and
then forgot about it.  It's only in the context of Bug#36269 that I
resurrected it - with all its inadequacies.

 >> @@ -3995,7 +3992,7 @@ kbd_buffer_get_event (KBOARD **kbp,
 >>         }
 >>       }
 >>     /* Try generating a mouse motion event.  */
 >> -  else if (!NILP (do_mouse_tracking) && some_mouse_moved ())
 >> +  else if (some_mouse_moved ())
 >
 > Can't we have mouse motion events outside track-mouse?

Not to my knowledge.  In either case, I wouldn't want to change
anything in this regard here.

 > There's too much of whitespace changes in the rest of the patch,
 > making it very hard to review.  Can you show the patch without
 > whitespace differences?

I attach a patch which re-adds some extraneous braces to w32term.c.
If you want me to restore more of the old code, please tell me.

Also, I do not intend to push the changes until someone tells me that
they work.  I neither use the mouse to drop nor mouse avoidance mode
and so have never given it any serious testing.

Thanks, martin

--------------39FE6C27FE5DB683E2477899
Content-Type: text/plain; charset=UTF-8;
 name="track-mouse-with-braces.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="track-mouse-with-braces.diff"

ZGlmZiAtLWdpdCBhL2xpc3AvYXZvaWQuZWwgYi9saXNwL2F2b2lkLmVsCmluZGV4IDdkNjlm
YTJhMjQuLjQzZTUwNjJiNzYgMTAwNjQ0Ci0tLSBhL2xpc3AvYXZvaWQuZWwKKysrIGIvbGlz
cC9hdm9pZC5lbApAQCAtMzI3LDYgKzMyNyw5IEBAIG1vdXNlLWF2b2lkYW5jZS1pZ25vcmUt
cAogICAgICAgICBleGVjdXRpbmcta2JkLW1hY3JvCSAgICAgICA7IGRvbid0IGNoZWNrIGlu
c2lkZSBtYWNybwogCShudWxsIChjYWRyIG1wKSkJICAgICAgIDsgZG9uJ3QgbW92ZSB1bmxl
c3MgaW4gYW4gRW1hY3MgZnJhbWUKIAkobm90IChlcSAoY2FyIG1wKSAoc2VsZWN0ZWQtZnJh
bWUpKSkKKyAgICAgICAgOzsgRG9uJ3QgaW50ZXJmZXJlIHdpdGggb25nb2luZyBgbW91c2Ut
ZHJhZy1hbmQtZHJvcC1yZWdpb24nCisgICAgICAgIDs7IChCdWcjMzYyNjkpLgorICAgICAg
ICAoZXEgdHJhY2stbW91c2UgJ2Ryb3BwaW5nKQogCTs7IERvbid0IGRvIGFueXRoaW5nIGlm
IGxhc3QgZXZlbnQgd2FzIGEgbW91c2UgZXZlbnQuCiAJOzsgRklYTUU6IHRoaXMgY29kZSBm
YWlscyBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgbW91c2Ugd2FzIG1vdmVkCiAJOzsgc2luY2Ug
dGhlIGxhc3Qga2V5LXByZXNzIGJ1dCB3aXRob3V0IGdlbmVyYXRpbmcgYW55IGV2ZW50Lgpk
aWZmIC0tZ2l0IGEvbGlzcC9tb3VzZS5lbCBiL2xpc3AvbW91c2UuZWwKaW5kZXggNGE1MzJh
MTVlNS4uZTk0N2UxNmQ0NyAxMDA2NDQKLS0tIGEvbGlzcC9tb3VzZS5lbAorKysgYi9saXNw
L21vdXNlLmVsCkBAIC0xMjk2LDcgKzEyOTYsNyBAQCBtb3VzZS1kcmFnLXRyYWNrCiAgICAg
IHQgKGxhbWJkYSAoKQogICAgICAgICAgKHNldHEgdHJhY2stbW91c2Ugb2xkLXRyYWNrLW1v
dXNlKQogICAgICAgICAgKHNldHEgYXV0by1oc2Nyb2xsLW1vZGUgYXV0by1oc2Nyb2xsLW1v
ZGUtc2F2ZWQpCi0gICAgICAgICAgKGRlYWN0aXZhdGUtbWFyaykKKyAgICAgICAgIChkZWFj
dGl2YXRlLW1hcmspCiAgICAgICAgICAocG9wLW1hcmspKSkpKQogCiAoZGVmdW4gbW91c2Ut
LWRyYWctc2V0LW1hcmstYW5kLXBvaW50IChzdGFydCBjbGljayBjbGljay1jb3VudCkKQEAg
LTI0NjcsMTIgKzI0NjcsMTMgQEAgbW91c2UtZHJhZy1hbmQtZHJvcC1yZWdpb24KIAogICAg
IChpZ25vcmUtZXJyb3JzCiAgICAgICAodHJhY2stbW91c2UKKyAgICAgICAgKHNldHEgdHJh
Y2stbW91c2UgJ2Ryb3BwaW5nKQogICAgICAgICA7OyBXaGVuIGV2ZW50IHdhcyAiY2xpY2si
IGluc3RlYWQgb2YgImRyYWciLCBza2lwIGxvb3AuCiAgICAgICAgICh3aGlsZSAocHJvZ24K
ICAgICAgICAgICAgICAgICAgKHNldHEgZXZlbnQgKHJlYWQta2V5KSkgICAgICA7IHJlYWQt
ZXZlbnQgb3IgcmVhZC1rZXkKICAgICAgICAgICAgICAgICAgKG9yIChtb3VzZS1tb3ZlbWVu
dC1wIGV2ZW50KQogICAgICAgICAgICAgICAgICAgICAgOzsgSGFuZGxlIGBtb3VzZS1hdXRv
c2VsZWN0LXdpbmRvdycuCi0gICAgICAgICAgICAgICAgICAgICAoZXEgKGNhci1zYWZlIGV2
ZW50KSAnc2VsZWN0LXdpbmRvdykpKQorICAgICAgICAgICAgICAgICAgICAgKG1lbXEgKGNh
ciBldmVudCkgJyhzZWxlY3Qtd2luZG93IHN3aXRjaC1mcmFtZSkpKSkKICAgICAgICAgICA7
OyBPYnRhaW4gdGhlIGRyYWdnZWQgdGV4dCBpbiByZWdpb24uICBXaGVuIHRoZSBsb29wIHdh
cwogICAgICAgICAgIDs7IHNraXBwZWQsIHZhbHVlLXNlbGVjdGlvbiByZW1haW5zIG5pbC4K
ICAgICAgICAgICAodW5sZXNzIHZhbHVlLXNlbGVjdGlvbgpkaWZmIC0tZ2l0IGEvc3JjL2Rp
c3BuZXcuYyBiL3NyYy9kaXNwbmV3LmMKaW5kZXggMDEzMWI2Mzc2Ny4uNzk5ZWYyYmVhZSAx
MDA2NDQKLS0tIGEvc3JjL2Rpc3BuZXcuYworKysgYi9zcmMvZGlzcG5ldy5jCkBAIC0zNDAy
LDkgKzM0MDIsOSBAQCB1cGRhdGVfd2luZG93IChzdHJ1Y3Qgd2luZG93ICp3LCBib29sIGZv
cmNlX3ApCiAgIGlmICghZm9yY2VfcCkKICAgICBkZXRlY3RfaW5wdXRfcGVuZGluZ19pZ25v
cmVfc3F1ZWV6YWJsZXMgKCk7CiAKLSAgLyogSWYgZm9yY2VkIHRvIGNvbXBsZXRlIHRoZSB1
cGRhdGUsIG9yIGlmIG5vIGlucHV0IGlzIHBlbmRpbmcsIGRvCi0gICAgIHRoZSB1cGRhdGUu
ICAqLwotICBpZiAoZm9yY2VfcCB8fCAhaW5wdXRfcGVuZGluZyB8fCAhTklMUCAoZG9fbW91
c2VfdHJhY2tpbmcpKQorICAvKiBJZiBmb3JjZWQgdG8gY29tcGxldGUgdGhlIHVwZGF0ZSwg
bm8gaW5wdXQgaXMgcGVuZGluZywgb3Igd2UgYXJlCisgICAgIHRyYWNraW5nIHRoZSBtb3Vz
ZSwgZG8gdGhlIHVwZGF0ZS4gICovCisgIGlmIChmb3JjZV9wIHx8ICFpbnB1dF9wZW5kaW5n
IHx8ICFOSUxQICh0cmFja19tb3VzZSkpCiAgICAgewogICAgICAgc3RydWN0IGdseXBoX3Jv
dyAqcm93LCAqZW5kOwogICAgICAgc3RydWN0IGdseXBoX3JvdyAqbW9kZV9saW5lX3JvdzsK
ZGlmZiAtLWdpdCBhL3NyYy9rZXlib2FyZC5jIGIvc3JjL2tleWJvYXJkLmMKaW5kZXggYjg2
YWQwMzg1MS4uNzY1YjZlODVjMSAxMDA2NDQKLS0tIGEvc3JjL2tleWJvYXJkLmMKKysrIGIv
c3JjL2tleWJvYXJkLmMKQEAgLTExNTksMTQgKzExNTksMTQgQEAgREVGVU4gKCJhYm9ydC1y
ZWN1cnNpdmUtZWRpdCIsIEZhYm9ydF9yZWN1cnNpdmVfZWRpdCwgU2Fib3J0X3JlY3Vyc2l2
ZV9lZGl0LCAwLAogICB1c2VyX2Vycm9yICgiTm8gcmVjdXJzaXZlIGVkaXQgaXMgaW4gcHJv
Z3Jlc3MiKTsKIH0KIAwKLS8qIFJlc3RvcmUgbW91c2UgdHJhY2tpbmcgZW5hYmxlbWVudC4g
IFNlZSBGdHJhY2tfbW91c2UgZm9yIHRoZSBvbmx5IHVzZQotICAgb2YgdGhpcyBmdW5jdGlv
bi4gICovCisvKiBSZXN0b3JlIG1vdXNlIHRyYWNraW5nIGVuYWJsZW1lbnQuICBTZWUgRmlu
dGVybmFsX3RyYWNrX21vdXNlIGZvcgorICAgdGhlIG9ubHkgdXNlIG9mIHRoaXMgZnVuY3Rp
b24uICAqLwogCiBzdGF0aWMgdm9pZAotdHJhY2tpbmdfb2ZmIChMaXNwX09iamVjdCBvbGRf
dmFsdWUpCit0cmFja2luZ19vZmYgKExpc3BfT2JqZWN0IG9sZF90cmFja19tb3VzZSkKIHsK
LSAgZG9fbW91c2VfdHJhY2tpbmcgPSBvbGRfdmFsdWU7Ci0gIGlmIChOSUxQIChvbGRfdmFs
dWUpKQorICB0cmFja19tb3VzZSA9IG9sZF90cmFja19tb3VzZTsKKyAgaWYgKE5JTFAgKG9s
ZF90cmFja19tb3VzZSkpCiAgICAgewogICAgICAgLyogUmVkaXNwbGF5IG1heSBoYXZlIGJl
ZW4gcHJlZW1wdGVkIGJlY2F1c2UgdGhlcmUgd2FzIGlucHV0CiAJIGF2YWlsYWJsZSwgYW5k
IGl0IGFzc3VtZXMgaXQgd2lsbCBiZSBjYWxsZWQgYWdhaW4gYWZ0ZXIgdGhlCkBAIC0xMTgx
LDI0ICsxMTgxLDI0IEBAIHRyYWNraW5nX29mZiAoTGlzcF9PYmplY3Qgb2xkX3ZhbHVlKQog
ICAgIH0KIH0KIAotREVGVU4gKCJpbnRlcm5hbC0tdHJhY2stbW91c2UiLCBGdHJhY2tfbW91
c2UsIFN0cmFja19tb3VzZSwgMSwgMSwgMCwKK0RFRlVOICgiaW50ZXJuYWwtLXRyYWNrLW1v
dXNlIiwgRmludGVybmFsX3RyYWNrX21vdXNlLCBTaW50ZXJuYWxfdHJhY2tfbW91c2UsCisg
ICAgICAgMSwgMSwgMCwKICAgICAgICBkb2M6IC8qIENhbGwgQk9EWUZVTiB3aXRoIG1vdXNl
IG1vdmVtZW50IGV2ZW50cyBlbmFibGVkLiAgKi8pCiAgIChMaXNwX09iamVjdCBib2R5ZnVu
KQogewogICBwdHJkaWZmX3QgY291bnQgPSBTUEVDUERMX0lOREVYICgpOwogICBMaXNwX09i
amVjdCB2YWw7CiAKLSAgcmVjb3JkX3Vud2luZF9wcm90ZWN0ICh0cmFja2luZ19vZmYsIGRv
X21vdXNlX3RyYWNraW5nKTsKKyAgcmVjb3JkX3Vud2luZF9wcm90ZWN0ICh0cmFja2luZ19v
ZmYsIHRyYWNrX21vdXNlKTsKIAotICBkb19tb3VzZV90cmFja2luZyA9IFF0OworICB0cmFj
a19tb3VzZSA9IFF0OwogCiAgIHZhbCA9IGNhbGwwIChib2R5ZnVuKTsKICAgcmV0dXJuIHVu
YmluZF90byAoY291bnQsIHZhbCk7CiB9CiAKLS8qIElmIG1vdXNlIGhhcyBtb3ZlZCBvbiBz
b21lIGZyYW1lLCByZXR1cm4gb25lIG9mIHRob3NlIGZyYW1lcy4KLQotICAgUmV0dXJuIDAg
b3RoZXJ3aXNlLgorLyogSWYgbW91c2UgaGFzIG1vdmVkIG9uIHNvbWUgZnJhbWUgYW5kIHdl
IGFyZSB0cmFja2luZyB0aGUgbW91c2UsCisgICByZXR1cm4gb25lIG9mIHRob3NlIGZyYW1l
cy4gIFJldHVybiBOVUxMIG90aGVyd2lzZS4KIAogICAgSWYgaWdub3JlX21vdXNlX2RyYWdf
cCBpcyBub24temVybywgaWdub3JlIChpbXBsaWNpdCkgbW91c2UgbW92ZW1lbnQKICAgIGFm
dGVyIHJlc2l6aW5nIHRoZSB0b29sLWJhciB3aW5kb3cuICAqLwpAQCAtMTIxMCwxMSArMTIx
MCw4IEBAIHNvbWVfbW91c2VfbW92ZWQgKHZvaWQpCiB7CiAgIExpc3BfT2JqZWN0IHRhaWws
IGZyYW1lOwogCi0gIGlmIChpZ25vcmVfbW91c2VfZHJhZ19wKQotICAgIHsKLSAgICAgIC8q
IGlnbm9yZV9tb3VzZV9kcmFnX3AgPSBmYWxzZTsgKi8KLSAgICAgIHJldHVybiAwOwotICAg
IH0KKyAgaWYgKE5JTFAgKHRyYWNrX21vdXNlKSB8fCBpZ25vcmVfbW91c2VfZHJhZ19wKQor
ICAgIHJldHVybiBOVUxMOwogCiAgIEZPUl9FQUNIX0ZSQU1FICh0YWlsLCBmcmFtZSkKICAg
ICB7CkBAIC0xMjIyLDcgKzEyMTksNyBAQCBzb21lX21vdXNlX21vdmVkICh2b2lkKQogCXJl
dHVybiBYRlJBTUUgKGZyYW1lKTsKICAgICB9CiAKLSAgcmV0dXJuIDA7CisgIHJldHVybiBO
VUxMOwogfQogCiAMCkBAIC0yMDcxLDcgKzIwNjgsOCBAQCBzaG93X2hlbHBfZWNobyAoTGlz
cF9PYmplY3QgaGVscCwgTGlzcF9PYmplY3Qgd2luZG93LCBMaXNwX09iamVjdCBvYmplY3Qs
CiAJIFRoaXMgY2F1c2VzIHRyb3VibGUgaWYgd2UgYXJlIHRyeWluZyB0byByZWFkIGEgbW91
c2UgbW90aW9uCiAJIGV2ZW50IChpLmUuLCBpZiB3ZSBhcmUgaW5zaWRlIGEgYHRyYWNrLW1v
dXNlJyBmb3JtKSwgc28gd2UKIAkgcmVzdG9yZSB0aGUgbW91c2VfbW92ZWQgZmxhZy4gICov
Ci0gICAgICBzdHJ1Y3QgZnJhbWUgKmYgPSBOSUxQIChkb19tb3VzZV90cmFja2luZykgPyBO
VUxMIDogc29tZV9tb3VzZV9tb3ZlZCAoKTsKKyAgICAgIHN0cnVjdCBmcmFtZSAqZiA9IHNv
bWVfbW91c2VfbW92ZWQgKCk7CisKICAgICAgIGhlbHAgPSBjYWxsMSAoUW1vdXNlX2ZpeHVw
X2hlbHBfbWVzc2FnZSwgaGVscCk7CiAgICAgICBpZiAoZikKIAlmLT5tb3VzZV9tb3ZlZCA9
IHRydWU7CkBAIC0zNDAzLDggKzM0MDEsNyBAQCByZWFkYWJsZV9ldmVudHMgKGludCBmbGFn
cykKIAlyZXR1cm4gMTsKICAgICB9CiAKLSAgaWYgKCEoZmxhZ3MgJiBSRUFEQUJMRV9FVkVO
VFNfSUdOT1JFX1NRVUVFWkFCTEVTKQotICAgICAgJiYgIU5JTFAgKGRvX21vdXNlX3RyYWNr
aW5nKSAmJiBzb21lX21vdXNlX21vdmVkICgpKQorICBpZiAoIShmbGFncyAmIFJFQURBQkxF
X0VWRU5UU19JR05PUkVfU1FVRUVaQUJMRVMpICYmIHNvbWVfbW91c2VfbW92ZWQgKCkpCiAg
ICAgcmV0dXJuIDE7CiAgIGlmIChzaW5nbGVfa2JvYXJkKQogICAgIHsKQEAgLTM3ODYsNyAr
Mzc4Myw3IEBAIGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKiprYnAsCiAKICAgICAg
IGlmIChrYmRfZmV0Y2hfcHRyICE9IGtiZF9zdG9yZV9wdHIpCiAJYnJlYWs7Ci0gICAgICBp
ZiAoIU5JTFAgKGRvX21vdXNlX3RyYWNraW5nKSAmJiBzb21lX21vdXNlX21vdmVkICgpKQor
ICAgICAgaWYgKHNvbWVfbW91c2VfbW92ZWQgKCkpCiAJYnJlYWs7CiAKICAgICAgIC8qIElm
IHRoZSBxdWl0IGZsYWcgaXMgc2V0LCB0aGVuIHJlYWRfY2hhciB3aWxsIHJldHVybgpAQCAt
MzgwMiw3ICszNzk5LDcgQEAga2JkX2J1ZmZlcl9nZXRfZXZlbnQgKEtCT0FSRCAqKmticCwK
ICNlbmRpZgogICAgICAgaWYgKGtiZF9mZXRjaF9wdHIgIT0ga2JkX3N0b3JlX3B0cikKIAli
cmVhazsKLSAgICAgIGlmICghTklMUCAoZG9fbW91c2VfdHJhY2tpbmcpICYmIHNvbWVfbW91
c2VfbW92ZWQgKCkpCisgICAgICBpZiAoc29tZV9tb3VzZV9tb3ZlZCAoKSkKIAlicmVhazsK
ICAgICAgIGlmIChlbmRfdGltZSkKIAl7CkBAIC0zOTQxLDggKzM5MzgsOSBAQCBrYmRfYnVm
ZmVyX2dldF9ldmVudCAoS0JPQVJEICoqa2JwLAogICAgICAgICBicmVhazsKICAgICAgIGRl
ZmF1bHQ6CiAJewotCSAgLyogSWYgdGhpcyBldmVudCBpcyBvbiBhIGRpZmZlcmVudCBmcmFt
ZSwgcmV0dXJuIGEgc3dpdGNoLWZyYW1lIHRoaXMKLQkgICAgIHRpbWUsIGFuZCBsZWF2ZSB0
aGUgZXZlbnQgaW4gdGhlIHF1ZXVlIGZvciBuZXh0IHRpbWUuICAqLworCSAgLyogSWYgdGhp
cyBldmVudCBpcyBvbiBhIGRpZmZlcmVudCBmcmFtZSwgcmV0dXJuIGEKKwkgICAgIHN3aXRj
aC1mcmFtZSB0aGlzIHRpbWUsIGFuZCBsZWF2ZSB0aGUgZXZlbnQgaW4gdGhlIHF1ZXVlCisJ
ICAgICBmb3IgbmV4dCB0aW1lLiAgKi8KIAkgIExpc3BfT2JqZWN0IGZyYW1lOwogCSAgTGlz
cF9PYmplY3QgZm9jdXM7CiAKQEAgLTM5NTYsMTQgKzM5NTQsMTMgQEAga2JkX2J1ZmZlcl9n
ZXRfZXZlbnQgKEtCT0FSRCAqKmticCwKIAkgIGlmICghIE5JTFAgKGZvY3VzKSkKIAkgICAg
ZnJhbWUgPSBmb2N1czsKIAotCSAgaWYgKCEgRVEgKGZyYW1lLCBpbnRlcm5hbF9sYXN0X2V2
ZW50X2ZyYW1lKQorCSAgaWYgKCFFUSAoZnJhbWUsIGludGVybmFsX2xhc3RfZXZlbnRfZnJh
bWUpCiAJICAgICAgJiYgIUVRIChmcmFtZSwgc2VsZWN0ZWRfZnJhbWUpKQogCSAgICBvYmog
PSBtYWtlX2xpc3B5X3N3aXRjaF9mcmFtZSAoZnJhbWUpOwogCSAgaW50ZXJuYWxfbGFzdF9l
dmVudF9mcmFtZSA9IGZyYW1lOwogCiAJICAvKiBJZiB3ZSBkaWRuJ3QgZGVjaWRlIHRvIG1h
a2UgYSBzd2l0Y2gtZnJhbWUgZXZlbnQsIGdvIGFoZWFkCiAJICAgICBhbmQgYnVpbGQgYSBy
ZWFsIGV2ZW50IGZyb20gdGhlIHF1ZXVlIGVudHJ5LiAgKi8KLQogCSAgaWYgKE5JTFAgKG9i
aikpCiAJICAgIHsKIAkgICAgICBvYmogPSBtYWtlX2xpc3B5X2V2ZW50ICgmZXZlbnQtPmll
KTsKQEAgLTM5OTUsNyArMzk5Miw3IEBAIGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQg
KiprYnAsCiAgICAgICB9CiAgICAgfQogICAvKiBUcnkgZ2VuZXJhdGluZyBhIG1vdXNlIG1v
dGlvbiBldmVudC4gICovCi0gIGVsc2UgaWYgKCFOSUxQIChkb19tb3VzZV90cmFja2luZykg
JiYgc29tZV9tb3VzZV9tb3ZlZCAoKSkKKyAgZWxzZSBpZiAoc29tZV9tb3VzZV9tb3ZlZCAo
KSkKICAgICB7CiAgICAgICBzdHJ1Y3QgZnJhbWUgKmYgPSBzb21lX21vdXNlX21vdmVkICgp
OwogICAgICAgTGlzcF9PYmplY3QgYmFyX3dpbmRvdzsKQEAgLTQwMjcsNyArNDAyNCw3IEBA
IGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKiprYnAsCiAJICBpZiAoTklMUCAoZnJh
bWUpKQogCSAgICBYU0VURlJBTUUgKGZyYW1lLCBmKTsKIAotCSAgaWYgKCEgRVEgKGZyYW1l
LCBpbnRlcm5hbF9sYXN0X2V2ZW50X2ZyYW1lKQorCSAgaWYgKCFFUSAoZnJhbWUsIGludGVy
bmFsX2xhc3RfZXZlbnRfZnJhbWUpCiAJICAgICAgJiYgIUVRIChmcmFtZSwgc2VsZWN0ZWRf
ZnJhbWUpKQogCSAgICBvYmogPSBtYWtlX2xpc3B5X3N3aXRjaF9mcmFtZSAoZnJhbWUpOwog
CSAgaW50ZXJuYWxfbGFzdF9ldmVudF9mcmFtZSA9IGZyYW1lOwpAQCAtMTA5MzUsNyArMTA5
MzIsNyBAQCBpbml0X2tleWJvYXJkICh2b2lkKQogICByZWNlbnRfa2V5c19pbmRleCA9IDA7
CiAgIGtiZF9mZXRjaF9wdHIgPSBrYmRfYnVmZmVyOwogICBrYmRfc3RvcmVfcHRyID0ga2Jk
X2J1ZmZlcjsKLSAgZG9fbW91c2VfdHJhY2tpbmcgPSBRbmlsOworICB0cmFja19tb3VzZSA9
IFFuaWw7CiAgIGlucHV0X3BlbmRpbmcgPSBmYWxzZTsKICAgaW50ZXJydXB0X2lucHV0X2Js
b2NrZWQgPSAwOwogICBwZW5kaW5nX3NpZ25hbHMgPSBmYWxzZTsKQEAgLTExMjk3LDcgKzEx
Mjk0LDcgQEAgc3ltc19vZl9rZXlib2FyZCAodm9pZCkKICAgZGVmc3ViciAoJlNyZWFkX2tl
eV9zZXF1ZW5jZSk7CiAgIGRlZnN1YnIgKCZTcmVhZF9rZXlfc2VxdWVuY2VfdmVjdG9yKTsK
ICAgZGVmc3ViciAoJlNyZWN1cnNpdmVfZWRpdCk7Ci0gIGRlZnN1YnIgKCZTdHJhY2tfbW91
c2UpOworICBkZWZzdWJyICgmU2ludGVybmFsX3RyYWNrX21vdXNlKTsKICAgZGVmc3ViciAo
JlNpbnB1dF9wZW5kaW5nX3ApOwogICBkZWZzdWJyICgmU3JlY2VudF9rZXlzKTsKICAgZGVm
c3ViciAoJlN0aGlzX2NvbW1hbmRfa2V5cyk7CkBAIC0xMTY0Miw4ICsxMTYzOSwxNSBAQCBh
bmQgdGhlIG1pbm9yIG1vZGUgbWFwcyByZWdhcmRsZXNzIG9mIGBvdmVycmlkaW5nLWxvY2Fs
LW1hcCcuICAqLyk7CiAJICAgICAgIGRvYzogLyogS2V5bWFwIGRlZmluaW5nIGJpbmRpbmdz
IGZvciBzcGVjaWFsIGV2ZW50cyB0byBleGVjdXRlIGF0IGxvdyBsZXZlbC4gICovKTsKICAg
VnNwZWNpYWxfZXZlbnRfbWFwID0gbGlzdDEgKFFrZXltYXApOwogCi0gIERFRlZBUl9MSVNQ
ICgidHJhY2stbW91c2UiLCBkb19tb3VzZV90cmFja2luZywKLQkgICAgICAgZG9jOiAvKiBO
b24tbmlsIG1lYW5zIGdlbmVyYXRlIG1vdGlvbiBldmVudHMgZm9yIG1vdXNlIG1vdGlvbi4g
ICovKTsKKyAgREVGVkFSX0xJU1AgKCJ0cmFjay1tb3VzZSIsIHRyYWNrX21vdXNlLAorCSAg
ICAgICBkb2M6IC8qIE5vbi1uaWwgbWVhbnMgZ2VuZXJhdGUgbW90aW9uIGV2ZW50cyBmb3Ig
bW91c2UgbW90aW9uLgorVGhlIHNwZWNpYWwgdmFsdWVzIGBkcmFnZ2luZycgYW5kIGBkcm9w
cGluZycgYXNzZXJ0IHRoYXQgdGhlIG1vdXNlCitjdXJzb3IgcmV0YWlucyBpdHMgYXBwZWFy
YW5jZSBkdXJpbmcgbW91c2UgbW90aW9uLiAgQW55IG5vbi1uaWwgdmFsdWUKK2J1dCBgZHJv
cHBpbmcnIGFzc2VydHMgdGhhdCBtb3Rpb24gZXZlbnRzIGFsd2F5cyByZWxhdGUgdG8gdGhl
IGZyYW1lCit3aGVyZSB0aGUgdGhlIG1vdXNlIG1vdmVtZW50IHN0YXJ0ZWQuICBUaGUgdmFs
dWUgYGRyb3BwaW5nJyBhc3NlcnRzCit0aGF0IG1vdGlvbiBldmVudHMgcmVsYXRlIHRvIHRo
ZSBmcmFtZSB3aGVyZSB0aGUgbW91c2UgY3Vyc29yIGlzIHNlZW4KK3doZW4gZ2VuZXJhdGlu
ZyB0aGUgZXZlbnQuICBJZiB0aGVyZSdzIG5vIHN1Y2ggZnJhbWUsIHN1Y2ggbW90aW9uCitl
dmVudHMgcmVsYXRlIHRvIHRoZSBmcmFtZSB3aGVyZSB0aGUgbW91c2UgbW92ZW1lbnQgc3Rh
cnRlZC4gICovKTsKIAogICBERUZWQVJfS0JPQVJEICgic3lzdGVtLWtleS1hbGlzdCIsIFZz
eXN0ZW1fa2V5X2FsaXN0LAogCQkgZG9jOiAvKiBBbGlzdCBvZiBzeXN0ZW0tc3BlY2lmaWMg
WCB3aW5kb3dzIGtleSBzeW1ib2xzLgpkaWZmIC0tZ2l0IGEvc3JjL25zdGVybS5tIGIvc3Jj
L25zdGVybS5tCmluZGV4IDAyMzMxODI2ZDkuLmZiMmU1NTkyOWUgMTAwNjQ0Ci0tLSBhL3Ny
Yy9uc3Rlcm0ubQorKysgYi9zcmMvbnN0ZXJtLm0KQEAgLTI0ODAsNyArMjQ4MCwxMSBAQCBz
byBzb21lIGtleSBwcmVzc2VzIChUQUIpIGFyZSBzd2FsbG93ZWQgYnkgdGhlIHN5c3RlbS4g
ICovCiAgICAgICBYRlJBTUUgKGZyYW1lKS0+bW91c2VfbW92ZWQgPSAwOwogCiAgIGRweWlu
Zm8tPmxhc3RfbW91c2Vfc2Nyb2xsX2JhciA9IG5pbDsKKyAgZiA9IGRweWluZm8tPm5zX2Zv
Y3VzX2ZyYW1lID8gZHB5aW5mby0+bnNfZm9jdXNfZnJhbWUgOiBTRUxFQ1RFRF9GUkFNRSAo
KTsKICAgaWYgKGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWUKKyAgICAgIC8qIFdoaWxlIGRy
b3BwaW5nLCB1c2UgdGhlIGxhc3QgbW91c2UgZnJhbWUgb25seSBpZiB0aGVyZSBpcyBubwor
CSBjdXJyZW50bHkgZm9jdXNlZCBmcmFtZS4gICovCisgICAgICAmJiAoIUVRICh0cmFja19t
b3VzZSwgUWRyb3BwaW5nKSB8fCAhZikKICAgICAgICYmIEZSQU1FX0xJVkVfUCAoZHB5aW5m
by0+bGFzdF9tb3VzZV9mcmFtZSkpCiAgICAgZiA9IGRweWluZm8tPmxhc3RfbW91c2VfZnJh
bWU7CiAgIGVsc2UKZGlmZiAtLWdpdCBhL3NyYy90ZXJtLmMgYi9zcmMvdGVybS5jCmluZGV4
IGIwNThkOGJkYWQuLmE4OGQ0N2Y5MjMgMTAwNjQ0Ci0tLSBhL3NyYy90ZXJtLmMKKysrIGIv
c3JjL3Rlcm0uYwpAQCAtMzAzMywxOCArMzAzMywxOCBAQCByZWFkX21lbnVfaW5wdXQgKHN0
cnVjdCBmcmFtZSAqc2YsIGludCAqeCwgaW50ICp5LCBpbnQgbWluX3ksIGludCBtYXhfeSwK
ICAgICAgIGJvb2wgdXNhYmxlX2lucHV0ID0gMTsKICAgICAgIG1pX3Jlc3VsdCBzdCA9IE1J
X0NPTlRJTlVFOwogICAgICAgc3RydWN0IHR0eV9kaXNwbGF5X2luZm8gKnR0eSA9IEZSQU1F
X1RUWSAoc2YpOwotICAgICAgTGlzcF9PYmplY3Qgc2F2ZWRfbW91c2VfdHJhY2tpbmcgPSBk
b19tb3VzZV90cmFja2luZzsKKyAgICAgIExpc3BfT2JqZWN0IG9sZF90cmFja19tb3VzZSA9
IHRyYWNrX21vdXNlOwogCiAgICAgICAvKiBTaWduYWwgdGhlIGtleWJvYXJkIHJlYWRpbmcg
cm91dGluZXMgd2UgYXJlIGRpc3BsYXlpbmcgYSBtZW51CiAJIG9uIHRoaXMgdGVybWluYWwu
ICAqLwogICAgICAgdHR5LT5zaG93aW5nX21lbnUgPSAxOwogICAgICAgLyogV2Ugd2FudCBt
b3VzZSBtb3ZlbWVudHMgYmUgcmVwb3J0ZWQgYnkgcmVhZF9tZW51X2NvbW1hbmQuICAqLwot
ICAgICAgZG9fbW91c2VfdHJhY2tpbmcgPSBRdDsKKyAgICAgIHRyYWNrX21vdXNlID0gUXQ7
CiAgICAgICBkbyB7CiAJY21kID0gcmVhZF9tZW51X2NvbW1hbmQgKCk7CiAgICAgICB9IHdo
aWxlIChOSUxQIChjbWQpKTsKICAgICAgIHR0eS0+c2hvd2luZ19tZW51ID0gMDsKLSAgICAg
IGRvX21vdXNlX3RyYWNraW5nID0gc2F2ZWRfbW91c2VfdHJhY2tpbmc7CisgICAgICB0cmFj
a19tb3VzZSA9IG9sZF90cmFja19tb3VzZTsKIAogICAgICAgaWYgKEVRIChjbWQsIFF0KSB8
fCBFUSAoY21kLCBRdHR5X21lbnVfZXhpdCkKIAkgIC8qIElmIHNvbWUgaW5wdXQgc3dpdGNo
ZWQgZnJhbWVzIHVuZGVyIG91ciBmZWV0LCBleGl0IHRoZQpkaWZmIC0tZ2l0IGEvc3JjL3cz
MmZucy5jIGIvc3JjL3czMmZucy5jCmluZGV4IGFjZDljODA1MjguLmEyYTg4YjI1ODggMTAw
NjQ0Ci0tLSBhL3NyYy93MzJmbnMuYworKysgYi9zcmMvdzMyZm5zLmMKQEAgLTQ1ODYsNyAr
NDU4Niw4IEBAIHczMl93bmRfcHJvYyAoSFdORCBod25kLCBVSU5UIG1zZywgV1BBUkFNIHdQ
YXJhbSwgTFBBUkFNIGxQYXJhbSkKIAlpZiAoYnV0dG9uX3N0YXRlICYgdGhpcykKIAkgIHJl
dHVybiAwOwogCi0JaWYgKGJ1dHRvbl9zdGF0ZSA9PSAwKQorCS8qIERvbid0IGNhcHR1cmUg
bW91c2Ugd2hlbiBkcm9wcGluZy4gICovCisJaWYgKGJ1dHRvbl9zdGF0ZSA9PSAwICYmICFF
USAodHJhY2tfbW91c2UsIFFkcm9wcGluZykpCiAJICBTZXRDYXB0dXJlIChod25kKTsKIAog
CWJ1dHRvbl9zdGF0ZSB8PSB0aGlzOwpAQCAtNDcwNyw4ICs0NzA4LDExIEBAIHczMl93bmRf
cHJvYyAoSFdORCBod25kLCBVSU5UIG1zZywgV1BBUkFNIHdQYXJhbSwgTFBBUkFNIGxQYXJh
bSkKIAogCWlmIChwYXJzZV9idXR0b24gKG1zZywgSElXT1JEICh3UGFyYW0pLCAmYnV0dG9u
LCAmdXApKQogCSAgewotCSAgICBpZiAodXApIFJlbGVhc2VDYXB0dXJlICgpOwotCSAgICBl
bHNlIFNldENhcHR1cmUgKGh3bmQpOworCSAgICBpZiAodXApCisJICAgICAgUmVsZWFzZUNh
cHR1cmUgKCk7CisJICAgIC8qIERvbid0IGNhcHR1cmUgbW91c2Ugd2hlbiBkcm9wcGluZy4g
ICovCisJICAgIGVsc2UgaWYgKCFFUSAodHJhY2tfbW91c2UsIFFkcm9wcGluZykpCisJICAg
ICAgU2V0Q2FwdHVyZSAoaHduZCk7CiAJICAgIGJ1dHRvbiA9IChidXR0b24gPT0gMCkgPyBM
TU9VU0UgOgogCSAgICAgICgoYnV0dG9uID09IDEpID8gTU1PVVNFICA6IFJNT1VTRSk7CiAJ
ICAgIGlmICh1cCkKQEAgLTUzNTEsOCArNTM1NSw5IEBAIHczMl93bmRfcHJvYyAoSFdORCBo
d25kLCBVSU5UIG1zZywgV1BBUkFNIHdQYXJhbSwgTFBBUkFNIGxQYXJhbSkKIAllbHNlIGlm
IChidXR0b25fc3RhdGUgJiBSTU9VU0UpCiAJICBmbGFncyB8PSBUUE1fUklHSFRCVVRUT047
CiAKLQkvKiBSZW1lbWJlciB3ZSBkaWQgYSBTZXRDYXB0dXJlIG9uIHRoZSBpbml0aWFsIG1v
dXNlIGRvd24gZXZlbnQsCi0JICAgc28gZm9yIHNhZmV0eSwgd2UgbWFrZSBzdXJlIHRoZSBj
YXB0dXJlIGlzIGNhbmNlbGVkIG5vdy4gICovCisJLyogV2UgbWF5IGhhdmUgZG9uZSBhIFNl
dENhcHR1cmUgb24gdGhlIGluaXRpYWwgbW91c2UgZG93bgorCSAgIGV2ZW50LCBzbyBmb3Ig
c2FmZXR5LCBtYWtlIHN1cmUgdGhlIGNhcHR1cmUgaXMgY2FuY2VsZWQKKwkgICBub3cuICAq
LwogCVJlbGVhc2VDYXB0dXJlICgpOwogCWJ1dHRvbl9zdGF0ZSA9IDA7CiAKZGlmZiAtLWdp
dCBhL3NyYy93MzJ0ZXJtLmMgYi9zcmMvdzMydGVybS5jCmluZGV4IGM2ZTE3NWU3ZTUuLjAw
NThiOThlZDQgMTAwNjQ0Ci0tLSBhL3NyYy93MzJ0ZXJtLmMKKysrIGIvc3JjL3czMnRlcm0u
YwpAQCAtMzUyNSwxMSArMzUyNSwxMyBAQCB3MzJfbW91c2VfcG9zaXRpb24gKHN0cnVjdCBm
cmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09iamVjdCAqYmFyX3dpbmRvdywKIAogICAg
ICAgLyogTm93IHdlIGhhdmUgYSBwb3NpdGlvbiBvbiB0aGUgcm9vdDsgZmluZCB0aGUgaW5u
ZXJtb3N0IHdpbmRvdwogCSBjb250YWluaW5nIHRoZSBwb2ludGVyLiAgKi8KKwogICAgICAg
ewotCS8qIElmIG1vdXNlIHdhcyBncmFiYmVkIG9uIGEgZnJhbWUsIGdpdmUgY29vcmRzIGZv
ciB0aGF0Ci0JICAgZnJhbWUgZXZlbiBpZiB0aGUgbW91c2UgaXMgbm93IG91dHNpZGUgaXQu
ICBPdGhlcndpc2UKLQkgICBjaGVjayBmb3Igd2luZG93IHVuZGVyIG1vdXNlIG9uIG9uZSBv
ZiBvdXIgZnJhbWVzLiAgKi8KLQlpZiAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pKQor
CS8qIElmIG1vdXNlIHdhcyBncmFiYmVkIG9uIGEgZnJhbWUgYW5kIHdlIGFyZSBub3QgZHJv
cHBpbmcsCisJICAgZ2l2ZSBjb29yZHMgZm9yIHRoYXQgZnJhbWUgZXZlbiBpZiB0aGUgbW91
c2UgaXMgbm93IG91dHNpZGUKKwkgICBpdC4gIE90aGVyd2lzZSBjaGVjayBmb3Igd2luZG93
IHVuZGVyIG1vdXNlIG9uIG9uZSBvZiBvdXIKKwkgICBmcmFtZXMuICAqLworCWlmIChndWlf
bW91c2VfZ3JhYmJlZCAoZHB5aW5mbykgJiYgIUVRICh0cmFja19tb3VzZSwgUWRyb3BwaW5n
KSkKIAkgIGYxID0gZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZTsKIAllbHNlCiAJICB7CkBA
IC0zNTU1LDE3ICszNTU3LDIzIEBAIHczMl9tb3VzZV9wb3NpdGlvbiAoc3RydWN0IGZyYW1l
ICoqZnAsIGludCBpbnNpc3QsIExpc3BfT2JqZWN0ICpiYXJfd2luZG93LAogCSAgICAgIH0K
IAkgIH0KIAorCWlmICghZjEgfHwgRlJBTUVfVE9PTFRJUF9QIChmMSkpCisJICAvKiBEb24n
dCB1c2UgYSB0b29sdGlwIGZyYW1lLiAgKi8KKwkgIGYxID0gKChFUSAodHJhY2tfbW91c2Us
IFFkcm9wcGluZykgJiYgZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pKQorCQk/IGRweWlu
Zm8tPmxhc3RfbW91c2VfZnJhbWUKKwkJOiBOVUxMKTsKKwogCS8qIElmIG5vdCwgaXMgaXQg
b25lIG9mIG91ciBzY3JvbGwgYmFycz8gICovCi0JaWYgKCEgZjEpCisJaWYgKCFmMSkKIAkg
IHsKIAkgICAgc3RydWN0IHNjcm9sbF9iYXIgKmJhcgotICAgICAgICAgICAgICA9IHczMl93
aW5kb3dfdG9fc2Nyb2xsX2JhciAoV2luZG93RnJvbVBvaW50IChwdCksIDIpOworCSAgICAg
ID0gdzMyX3dpbmRvd190b19zY3JvbGxfYmFyIChXaW5kb3dGcm9tUG9pbnQgKHB0KSwgMik7
CiAKIAkgICAgaWYgKGJhcikKIAkgICAgICBmMSA9IFhGUkFNRSAoV0lORE9XX0ZSQU1FIChY
V0lORE9XIChiYXItPndpbmRvdykpKTsKIAkgIH0KIAotCWlmIChmMSA9PSAwICYmIGluc2lz
dCA+IDApCisJaWYgKCFmMSAmJiBpbnNpc3QgPiAwKQogCSAgZjEgPSBTRUxFQ1RFRF9GUkFN
RSAoKTsKIAogCWlmIChmMSkKQEAgLTQ2NjcsNiArNDY3NSwzNyBAQCBzdGF0aWMgc2hvcnQg
dGVtcF9idWZmZXJbMTAwXTsKIC8qIFRlbXBvcmFyaWx5IHN0b3JlIGxlYWQgYnl0ZSBvZiBE
QkNTIGlucHV0IHNlcXVlbmNlcy4gICovCiBzdGF0aWMgY2hhciBkYmNzX2xlYWQgPSAwOwog
CisvKioKKyAgbW91c2Vfb3Jfd2Rlc2NfZnJhbWU6IFdoZW4gbm90IGRyb3BwaW5nIGFuZCB0
aGUgbW91c2Ugd2FzIGdyYWJiZWQKKyAgZm9yIERQWUlORk8sIHJldHVybiB0aGUgZnJhbWUg
d2hlcmUgdGhlIG1vdXNlIHdhcyBzZWVuIGxhc3QuICBJZgorICB0aGVyZSdzIG5vIHN1Y2gg
ZnJhbWUsIHJldHVybiB0aGUgZnJhbWUgYWNjb3JkaW5nIHRvIFdERVNDLiAgV2hlbgorICBk
cm9wcGluZywgcmV0dXJuIHRoZSBmcmFtZSBhY2NvcmRpbmcgdG8gV0RFU0MuICBJZiB0aGVy
ZSdzIG5vIHN1Y2gKKyAgZnJhbWUgYW5kIHRoZSBtb3VzZSB3YXMgZ3JhYmJlZCBmb3IgRFBZ
SU5GTywgcmV0dXJuIHRoZSBmcmFtZSB3aGVyZQorICB0aGUgbW91c2Ugd2FzIHNlZW4gbGFz
dC4gIEluIGVpdGhlciBjYXNlLCBuZXZlciByZXR1cm4gYSB0b29sdGlwCisgIGZyYW1lLiAg
Ki8KK3N0YXRpYyBzdHJ1Y3QgZnJhbWUgKgorbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKHN0cnVj
dCB3MzJfZGlzcGxheV9pbmZvICpkcHlpbmZvLCBIV05EIHdkZXNjKQoreworICBzdHJ1Y3Qg
ZnJhbWUgKmxtX2YgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pCisJCQk/IGRweWlu
Zm8tPmxhc3RfbW91c2VfZnJhbWUKKwkJCTogTlVMTCk7CisKKyAgaWYgKGxtX2YgJiYgIUVR
ICh0cmFja19tb3VzZSwgUWRyb3BwaW5nKSkKKyAgICByZXR1cm4gbG1fZjsKKyAgZWxzZQor
ICAgIHsKKyAgICAgIHN0cnVjdCBmcmFtZSAqd19mID0gdzMyX3dpbmRvd190b19mcmFtZSAo
ZHB5aW5mbywgd2Rlc2MpOworCisgICAgICAvKiBEbyBub3QgcmV0dXJuIGEgdG9vbHRpcCBm
cmFtZS4gICovCisgICAgICBpZiAoIXdfZiB8fCBGUkFNRV9UT09MVElQX1AgKHdfZikpCisJ
cmV0dXJuIEVRICh0cmFja19tb3VzZSwgUWRyb3BwaW5nKSA/IGxtX2YgOiBOVUxMOworICAg
ICAgZWxzZQorCS8qIFdoZW4gZHJvcHBpbmcgaXQgd291bGQgYmUgcHJvYmFibHkgbmljZSB0
byByYWlzZSB3X2YKKwkgICBoZXJlLiAgKi8KKwlyZXR1cm4gd19mOworICAgIH0KK30KKwog
LyogUmVhZCBldmVudHMgY29taW5nIGZyb20gdGhlIFczMiBzaGVsbC4KICAgIFRoaXMgcm91
dGluZSBpcyBjYWxsZWQgYnkgdGhlIFNJR0lPIGhhbmRsZXIuCiAgICBXZSByZXR1cm4gYXMg
c29vbiBhcyB0aGVyZSBhcmUgbm8gbW9yZSBldmVudHMgdG8gYmUgcmVhZC4KQEAgLTQ5NDAs
MTUgKzQ5NzksMTMgQEAgdzMyX3JlYWRfc29ja2V0IChzdHJ1Y3QgdGVybWluYWwgKnRlcm1p
bmFsLAogICAgICAgICAgIHByZXZpb3VzX2hlbHBfZWNob19zdHJpbmcgPSBoZWxwX2VjaG9f
c3RyaW5nOwogCSAgaGVscF9lY2hvX3N0cmluZyA9IFFuaWw7CiAKLQkgIGYgPSAoZ3VpX21v
dXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZQotCSAg
ICAgICA6IHczMl93aW5kb3dfdG9fZnJhbWUgKGRweWluZm8sIG1zZy5tc2cuaHduZCkpOwot
CiAJICBpZiAoaGxpbmZvLT5tb3VzZV9mYWNlX2hpZGRlbikKIAkgICAgewogCSAgICAgIGhs
aW5mby0+bW91c2VfZmFjZV9oaWRkZW4gPSBmYWxzZTsKIAkgICAgICBjbGVhcl9tb3VzZV9m
YWNlIChobGluZm8pOwogCSAgICB9CiAKKwkgIGYgPSBtb3VzZV9vcl93ZGVzY19mcmFtZSAo
ZHB5aW5mbywgbXNnLm1zZy5od25kKTsKIAkgIGlmIChmKQogCSAgICB7CiAJICAgICAgLyog
TWF5YmUgZ2VuZXJhdGUgU0VMRUNUX1dJTkRPV19FVkVOVHMgZm9yCkBAIC01MDIwLDkgKzUw
NTcsNyBAQCB3MzJfcmVhZF9zb2NrZXQgKHN0cnVjdCB0ZXJtaW5hbCAqdGVybWluYWwsCiAJ
ICAgIGludCBidXR0b24gPSAwOwogCSAgICBpbnQgdXAgPSAwOwogCi0JICAgIGYgPSAoZ3Vp
X21vdXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZQot
CQkgOiB3MzJfd2luZG93X3RvX2ZyYW1lIChkcHlpbmZvLCBtc2cubXNnLmh3bmQpKTsKLQor
CSAgICBmID0gbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKGRweWluZm8sIG1zZy5tc2cuaHduZCk7
CiAJICAgIGlmIChmKQogCSAgICAgIHsKICAgICAgICAgICAgICAgICB3MzJfY29uc3RydWN0
X21vdXNlX2NsaWNrICgmaW5ldiwgJm1zZywgZik7CkBAIC01MDgxLDkgKzUxMTYsNyBAQCB3
MzJfcmVhZF9zb2NrZXQgKHN0cnVjdCB0ZXJtaW5hbCAqdGVybWluYWwsCiAJY2FzZSBXTV9N
T1VTRVdIRUVMOgogICAgICAgICBjYXNlIFdNX01PVVNFSFdIRUVMOgogCSAgewotCSAgICBm
ID0gKGd1aV9tb3VzZV9ncmFiYmVkIChkcHlpbmZvKSA/IGRweWluZm8tPmxhc3RfbW91c2Vf
ZnJhbWUKLQkJIDogdzMyX3dpbmRvd190b19mcmFtZSAoZHB5aW5mbywgbXNnLm1zZy5od25k
KSk7Ci0KKwkgICAgZiA9IG1vdXNlX29yX3dkZXNjX2ZyYW1lIChkcHlpbmZvLCBtc2cubXNn
Lmh3bmQpOwogCSAgICBpZiAoZikKIAkgICAgICB7CiAJCWlmICghZHB5aW5mby0+dzMyX2Zv
Y3VzX2ZyYW1lCkBAIC01NDM5LDYgKzU0NzIsNyBAQCB3MzJfcmVhZF9zb2NrZXQgKHN0cnVj
dCB0ZXJtaW5hbCAqdGVybWluYWwsCiAJICAgICAgaWYgKGFueV9oZWxwX2V2ZW50X3ApCiAJ
CWRvX2hlbHAgPSAtMTsKIAkgICAgfQorCiAJICBicmVhazsKIAogCWNhc2UgV01fU0VURk9D
VVM6CmRpZmYgLS1naXQgYS9zcmMveGRpc3AuYyBiL3NyYy94ZGlzcC5jCmluZGV4IDFiYjVm
NWUwZjIuLjczMzhkMmI3ZDQgMTAwNjQ0Ci0tLSBhL3NyYy94ZGlzcC5jCisrKyBiL3NyYy94
ZGlzcC5jCkBAIC0xNzI4OSw3ICsxNzI4OSw3IEBAIHJlZGlzcGxheV93aW5kb3cgKExpc3Bf
T2JqZWN0IHdpbmRvdywgYm9vbCBqdXN0X3RoaXNfb25lX3ApCiAJIHRoZSBtb3VzZSwgcmVz
dWx0aW5nIGluIGFuIHVud2FudGVkIG1vdXNlLW1vdmVtZW50IHJhdGhlcgogCSB0aGFuIGEg
c2ltcGxlIG1vdXNlLWNsaWNrLiAgKi8KICAgICAgIGlmICghdy0+c3RhcnRfYXRfbGluZV9i
ZWcKLQkgICYmIE5JTFAgKGRvX21vdXNlX3RyYWNraW5nKQorCSAgJiYgTklMUCAodHJhY2tf
bW91c2UpCiAgICAgICAJICAmJiBDSEFSUE9TIChzdGFydHApID4gQkVHVgogCSAgJiYgQ0hB
UlBPUyAoc3RhcnRwKSA+IEJFRyArIGJlZ191bmNoYW5nZWQKIAkgICYmIENIQVJQT1MgKHN0
YXJ0cCkgPD0gWiAtIGVuZF91bmNoYW5nZWQKQEAgLTMwMjc5LDcgKzMwMjc5LDcgQEAgc2hv
d19tb3VzZV9mYWNlIChNb3VzZV9ITEluZm8gKmhsaW5mbywgZW51bSBkcmF3X2dseXBoc19m
YWNlIGRyYXcpCiAKICNpZmRlZiBIQVZFX1dJTkRPV19TWVNURU0KICAgLyogQ2hhbmdlIHRo
ZSBtb3VzZSBjdXJzb3IuICAqLwotICBpZiAoRlJBTUVfV0lORE9XX1AgKGYpICYmIE5JTFAg
KGRvX21vdXNlX3RyYWNraW5nKSkKKyAgaWYgKEZSQU1FX1dJTkRPV19QIChmKSAmJiBOSUxQ
ICh0cmFja19tb3VzZSkpCiAgICAgewogI2lmbmRlZiBIQVZFX0VYVF9UT09MX0JBUgogICAg
ICAgaWYgKGRyYXcgPT0gRFJBV19OT1JNQUxfVEVYVApAQCAtMzEyMjYsNyArMzEyMjYsNyBA
QCBkZWZpbmVfZnJhbWVfY3Vyc29yMSAoc3RydWN0IGZyYW1lICpmLCBFbWFjc19DdXJzb3Ig
Y3Vyc29yLCBMaXNwX09iamVjdCBwb2ludGVyKQogICAgIHJldHVybjsKIAogICAvKiBEbyBu
b3QgY2hhbmdlIGN1cnNvciBzaGFwZSB3aGlsZSBkcmFnZ2luZyBtb3VzZS4gICovCi0gIGlm
IChFUSAoZG9fbW91c2VfdHJhY2tpbmcsIFFkcmFnZ2luZykpCisgIGlmIChFUSAodHJhY2tf
bW91c2UsIFFkcmFnZ2luZykgfHwgRVEgKHRyYWNrX21vdXNlLCBRZHJvcHBpbmcpKQogICAg
IHJldHVybjsKIAogICBpZiAoIU5JTFAgKHBvaW50ZXIpKQpAQCAtMzI5NTYsNiArMzI5NTYs
NyBAQCBiZSBsZXQtYm91bmQgYXJvdW5kIGNvZGUgdGhhdCBuZWVkcyB0byBkaXNhYmxlIG1l
c3NhZ2VzIHRlbXBvcmFyaWx5LiAqLyk7CiAgIC8qIGFsc28gUXRleHQgKi8KIAogICBERUZT
WU0gKFFkcmFnZ2luZywgImRyYWdnaW5nIik7CisgIERFRlNZTSAoUWRyb3BwaW5nLCAiZHJv
cHBpbmciKTsKIAogICBERUZTWU0gKFFpbmhpYml0X2ZyZWVfcmVhbGl6ZWRfZmFjZXMsICJp
bmhpYml0LWZyZWUtcmVhbGl6ZWQtZmFjZXMiKTsKIApkaWZmIC0tZ2l0IGEvc3JjL3h0ZXJt
LmMgYi9zcmMveHRlcm0uYwppbmRleCBjOTZhYTc0YTdhLi45N2QxNGY3ZDQ1IDEwMDY0NAot
LS0gYS9zcmMveHRlcm0uYworKysgYi9zcmMveHRlcm0uYwpAQCAtNTE2NywyMCArNTE2Nywx
NSBAQCBYVG1vdXNlX3Bvc2l0aW9uIChzdHJ1Y3QgZnJhbWUgKipmcCwgaW50IGluc2lzdCwg
TGlzcF9PYmplY3QgKmJhcl93aW5kb3csCiAgICAgICAvKiBGaWd1cmUgb3V0IHdoaWNoIHJv
b3Qgd2luZG93IHdlJ3JlIG9uLiAgKi8KICAgICAgIFhRdWVyeVBvaW50ZXIgKEZSQU1FX1hf
RElTUExBWSAoKmZwKSwKIAkJICAgICBEZWZhdWx0Um9vdFdpbmRvdyAoRlJBTUVfWF9ESVNQ
TEFZICgqZnApKSwKLQogCQkgICAgIC8qIFRoZSByb290IHdpbmRvdyB3aGljaCBjb250YWlu
cyB0aGUgcG9pbnRlci4gICovCiAJCSAgICAgJnJvb3QsCi0KIAkJICAgICAvKiBUcmFzaCB3
aGljaCB3ZSBjYW4ndCB0cnVzdCBpZiB0aGUgcG9pbnRlciBpcyBvbgogCQkJYSBkaWZmZXJl
bnQgc2NyZWVuLiAgKi8KIAkJICAgICAmZHVtbXlfd2luZG93LAotCiAJCSAgICAgLyogVGhl
IHBvc2l0aW9uIG9uIHRoYXQgcm9vdCB3aW5kb3cuICAqLwogCQkgICAgICZyb290X3gsICZy
b290X3ksCi0KIAkJICAgICAvKiBNb3JlIHRyYXNoIHdlIGNhbid0IHRydXN0LiAgKi8KIAkJ
ICAgICAmZHVtbXksICZkdW1teSwKLQogCQkgICAgIC8qIE1vZGlmaWVyIGtleXMgYW5kIHBv
aW50ZXIgYnV0dG9ucywgYWJvdXQgd2hpY2gKIAkJCXdlIGRvbid0IGNhcmUuICAqLwogCQkg
ICAgICh1bnNpZ25lZCBpbnQgKikgJmR1bW15KTsKQEAgLTUyMDMsMjEgKzUxOTgsMTcgQEAg
WFRtb3VzZV9wb3NpdGlvbiAoc3RydWN0IGZyYW1lICoqZnAsIGludCBpbnNpc3QsIExpc3Bf
T2JqZWN0ICpiYXJfd2luZG93LAogCiAJeF9jYXRjaF9lcnJvcnMgKEZSQU1FX1hfRElTUExB
WSAoKmZwKSk7CiAKLQlpZiAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pKQorCWlmIChn
dWlfbW91c2VfZ3JhYmJlZCAoZHB5aW5mbykgJiYgIUVRICh0cmFja19tb3VzZSwgUWRyb3Bw
aW5nKSkKIAkgIHsKIAkgICAgLyogSWYgbW91c2Ugd2FzIGdyYWJiZWQgb24gYSBmcmFtZSwg
Z2l2ZSBjb29yZHMgZm9yIHRoYXQgZnJhbWUKIAkgICAgICAgZXZlbiBpZiB0aGUgbW91c2Ug
aXMgbm93IG91dHNpZGUgaXQuICAqLwogCSAgICBYVHJhbnNsYXRlQ29vcmRpbmF0ZXMgKEZS
QU1FX1hfRElTUExBWSAoKmZwKSwKLQogCQkJCSAgIC8qIEZyb20td2luZG93LiAgKi8KIAkJ
CQkgICByb290LAotCiAJCQkJICAgLyogVG8td2luZG93LiAgKi8KIAkJCQkgICBGUkFNRV9Y
X1dJTkRPVyAoZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZSksCi0KIAkJCQkgICAvKiBGcm9t
LXBvc2l0aW9uLCB0by1wb3NpdGlvbi4gICovCiAJCQkJICAgcm9vdF94LCByb290X3ksICZ3
aW5feCwgJndpbl95LAotCiAJCQkJICAgLyogQ2hpbGQgb2Ygd2luLiAgKi8KIAkJCQkgICAm
Y2hpbGQpOwogCSAgICBmMSA9IGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWU7CkBAIC01MjI3
LDE2ICs1MjE4LDEyIEBAIFhUbW91c2VfcG9zaXRpb24gKHN0cnVjdCBmcmFtZSAqKmZwLCBp
bnQgaW5zaXN0LCBMaXNwX09iamVjdCAqYmFyX3dpbmRvdywKIAkgICAgd2hpbGUgKHRydWUp
CiAJICAgICAgewogCQlYVHJhbnNsYXRlQ29vcmRpbmF0ZXMgKEZSQU1FX1hfRElTUExBWSAo
KmZwKSwKLQogCQkJCSAgICAgICAvKiBGcm9tLXdpbmRvdywgdG8td2luZG93LiAgKi8KIAkJ
CQkgICAgICAgcm9vdCwgd2luLAotCiAJCQkJICAgICAgIC8qIEZyb20tcG9zaXRpb24sIHRv
LXBvc2l0aW9uLiAgKi8KIAkJCQkgICAgICAgcm9vdF94LCByb290X3ksICZ3aW5feCwgJndp
bl95LAotCiAJCQkJICAgICAgIC8qIENoaWxkIG9mIHdpbi4gICovCiAJCQkJICAgICAgICZj
aGlsZCk7Ci0KIAkJaWYgKGNoaWxkID09IE5vbmUgfHwgY2hpbGQgPT0gd2luKQogCQkgIHsK
ICNpZmRlZiBVU0VfR1RLCkBAIC01Mjk5LDEzICs1Mjg2LDM1IEBAIFhUbW91c2VfcG9zaXRp
b24gKHN0cnVjdCBmcmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09iamVjdCAqYmFyX3dp
bmRvdywKICNlbmRpZiAvKiBVU0VfWF9UT09MS0lUICovCiAJICB9CiAKKwlpZiAoKCFmMSB8
fCBGUkFNRV9UT09MVElQX1AgKGYxKSkKKwkgICAgJiYgRVEgKHRyYWNrX21vdXNlLCBRZHJv
cHBpbmcpCisJICAgICYmIGd1aV9tb3VzZV9ncmFiYmVkIChkcHlpbmZvKSkKKwkgIHsKKwkg
ICAgLyogV2hlbiBkcm9wcGluZyB0aGVuIGlmIHdlIGRpZG4ndCBnZXQgYSBmcmFtZSBvciBv
bmx5IGEKKwkgICAgICAgdG9vbHRpcCBmcmFtZSBhbmQgdGhlIG1vdXNlIHdhcyBncmFiYmVk
IG9uIGEgZnJhbWUsCisJICAgICAgIGdpdmUgY29vcmRzIGZvciB0aGF0IGZyYW1lIGV2ZW4g
aWYgdGhlIG1vdXNlIGlzIG5vdworCSAgICAgICBvdXRzaWRlIGl0LiAgKi8KKwkgICAgWFRy
YW5zbGF0ZUNvb3JkaW5hdGVzIChGUkFNRV9YX0RJU1BMQVkgKCpmcCksCisJCQkJICAgLyog
RnJvbS13aW5kb3cuICAqLworCQkJCSAgIHJvb3QsCisJCQkJICAgLyogVG8td2luZG93LiAg
Ki8KKwkJCQkgICBGUkFNRV9YX1dJTkRPVyAoZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZSks
CisJCQkJICAgLyogRnJvbS1wb3NpdGlvbiwgdG8tcG9zaXRpb24uICAqLworCQkJCSAgIHJv
b3RfeCwgcm9vdF95LCAmd2luX3gsICZ3aW5feSwKKwkJCQkgICAvKiBDaGlsZCBvZiB3aW4u
ICAqLworCQkJCSAgICZjaGlsZCk7CisJICAgIGYxID0gZHB5aW5mby0+bGFzdF9tb3VzZV9m
cmFtZTsKKwkgIH0KKwllbHNlIGlmIChmMSAmJiBGUkFNRV9UT09MVElQX1AgKGYxKSkKKwkg
IGYxID0gTlVMTDsKKwogCWlmICh4X2hhZF9lcnJvcnNfcCAoRlJBTUVfWF9ESVNQTEFZICgq
ZnApKSkKLQkgIGYxID0gMDsKKwkgIGYxID0gTlVMTDsKIAogCXhfdW5jYXRjaF9lcnJvcnNf
YWZ0ZXJfY2hlY2sgKCk7CiAKIAkvKiBJZiBub3QsIGlzIGl0IG9uZSBvZiBvdXIgc2Nyb2xs
IGJhcnM/ICAqLwotCWlmICghIGYxKQorCWlmICghZjEpCiAJICB7CiAJICAgIHN0cnVjdCBz
Y3JvbGxfYmFyICpiYXI7CiAKQEAgLTUzMTksNyArNTMyOCw3IEBAIFhUbW91c2VfcG9zaXRp
b24gKHN0cnVjdCBmcmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09iamVjdCAqYmFyX3dp
bmRvdywKIAkgICAgICB9CiAJICB9CiAKLQlpZiAoZjEgPT0gMCAmJiBpbnNpc3QgPiAwKQor
CWlmICghZjEgJiYgaW5zaXN0ID4gMCkKIAkgIGYxID0gU0VMRUNURURfRlJBTUUgKCk7CiAK
IAlpZiAoZjEpCkBAIC03Nzg4LDYgKzc3OTcsMzcgQEAgZmx1c2hfZGlydHlfYmFja19idWZm
ZXJzICh2b2lkKQogICB1bmJsb2NrX2lucHV0ICgpOwogfQogCisvKioKKyAgbW91c2Vfb3Jf
d2Rlc2NfZnJhbWU6IFdoZW4gbm90IGRyb3BwaW5nIGFuZCB0aGUgbW91c2Ugd2FzIGdyYWJi
ZWQKKyAgZm9yIERQWUlORk8sIHJldHVybiB0aGUgZnJhbWUgd2hlcmUgdGhlIG1vdXNlIHdh
cyBzZWVuIGxhc3QuICBJZgorICB0aGVyZSdzIG5vIHN1Y2ggZnJhbWUsIHJldHVybiB0aGUg
ZnJhbWUgYWNjb3JkaW5nIHRvIFdERVNDLiAgV2hlbgorICBkcm9wcGluZywgcmV0dXJuIHRo
ZSBmcmFtZSBhY2NvcmRpbmcgdG8gV0RFU0MuICBJZiB0aGVyZSdzIG5vIHN1Y2gKKyAgZnJh
bWUgYW5kIHRoZSBtb3VzZSB3YXMgZ3JhYmJlZCBmb3IgRFBZSU5GTywgcmV0dXJuIHRoZSBm
cmFtZSB3aGVyZQorICB0aGUgbW91c2Ugd2FzIHNlZW4gbGFzdC4gIEluIGVpdGhlciBjYXNl
LCBuZXZlciByZXR1cm4gYSB0b29sdGlwCisgIGZyYW1lLiAgKi8KK3N0YXRpYyBzdHJ1Y3Qg
ZnJhbWUgKgorbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKHN0cnVjdCB4X2Rpc3BsYXlfaW5mbyAq
ZHB5aW5mbywgaW50IHdkZXNjKQoreworICBzdHJ1Y3QgZnJhbWUgKmxtX2YgPSAoZ3VpX21v
dXNlX2dyYWJiZWQgKGRweWluZm8pCisJCQk/IGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWUK
KwkJCTogTlVMTCk7CisKKyAgaWYgKGxtX2YgJiYgIUVRICh0cmFja19tb3VzZSwgUWRyb3Bw
aW5nKSkKKyAgICByZXR1cm4gbG1fZjsKKyAgZWxzZQorICAgIHsKKyAgICAgIHN0cnVjdCBm
cmFtZSAqd19mID0geF93aW5kb3dfdG9fZnJhbWUgKGRweWluZm8sIHdkZXNjKTsKKworICAg
ICAgLyogRG8gbm90IHJldHVybiBhIHRvb2x0aXAgZnJhbWUuICAqLworICAgICAgaWYgKCF3
X2YgfHwgRlJBTUVfVE9PTFRJUF9QICh3X2YpKQorCXJldHVybiBFUSAodHJhY2tfbW91c2Us
IFFkcm9wcGluZykgPyBsbV9mIDogTlVMTDsKKyAgICAgIGVsc2UKKwkvKiBXaGVuIGRyb3Bw
aW5nIGl0IHdvdWxkIGJlIHByb2JhYmx5IG5pY2UgdG8gcmFpc2Ugd19mCisJICAgaGVyZS4g
ICovCisJcmV0dXJuIHdfZjsKKyAgICB9Cit9CisKIC8qIEhhbmRsZXMgdGhlIFhFdmVudCBF
VkVOVCBvbiBkaXNwbGF5IERQWUlORk8uCiAKICAgICpGSU5JU0ggaXMgWF9FVkVOVF9HT1RP
X09VVCBpZiBjYWxsZXIgc2hvdWxkIHN0b3AgcmVhZGluZyBldmVudHMuCkBAIC04NzIwLDE1
ICs4NzYwLDE0IEBAIGhhbmRsZV9vbmVfeGV2ZW50IChzdHJ1Y3QgeF9kaXNwbGF5X2luZm8g
KmRweWluZm8sCiAgICAgICAgIHByZXZpb3VzX2hlbHBfZWNob19zdHJpbmcgPSBoZWxwX2Vj
aG9fc3RyaW5nOwogICAgICAgICBoZWxwX2VjaG9fc3RyaW5nID0gUW5pbDsKIAotCWYgPSAo
Z3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFt
ZQotCSAgICAgOiB4X3dpbmRvd190b19mcmFtZSAoZHB5aW5mbywgZXZlbnQtPnhtb3Rpb24u
d2luZG93KSk7Ci0KLSAgICAgICAgaWYgKGhsaW5mby0+bW91c2VfZmFjZV9oaWRkZW4pCisJ
aWYgKGhsaW5mby0+bW91c2VfZmFjZV9oaWRkZW4pCiAgICAgICAgICAgewogICAgICAgICAg
ICAgaGxpbmZvLT5tb3VzZV9mYWNlX2hpZGRlbiA9IGZhbHNlOwogICAgICAgICAgICAgY2xl
YXJfbW91c2VfZmFjZSAoaGxpbmZvKTsKICAgICAgICAgICB9CiAKKwlmID0gbW91c2Vfb3Jf
d2Rlc2NfZnJhbWUgKGRweWluZm8sIGV2ZW50LT54bW90aW9uLndpbmRvdyk7CisKICNpZmRl
ZiBVU0VfR1RLCiAgICAgICAgIGlmIChmICYmIHhnX2V2ZW50X2lzX2Zvcl9zY3JvbGxiYXIg
KGYsIGV2ZW50KSkKICAgICAgICAgICBmID0gMDsKQEAgLTg5NzAsMzMgKzkwMDksMjcgQEAg
aGFuZGxlX29uZV94ZXZlbnQgKHN0cnVjdCB4X2Rpc3BsYXlfaW5mbyAqZHB5aW5mbywKIAlk
cHlpbmZvLT5sYXN0X21vdXNlX2dseXBoX2ZyYW1lID0gTlVMTDsKIAl4X2Rpc3BsYXlfc2V0
X2xhc3RfdXNlcl90aW1lIChkcHlpbmZvLCBldmVudC0+eGJ1dHRvbi50aW1lKTsKIAotCWlm
IChndWlfbW91c2VfZ3JhYmJlZCAoZHB5aW5mbykpCi0JICBmID0gZHB5aW5mby0+bGFzdF9t
b3VzZV9mcmFtZTsKLQllbHNlCisJZiA9IG1vdXNlX29yX3dkZXNjX2ZyYW1lIChkcHlpbmZv
LCBldmVudC0+eG1vdGlvbi53aW5kb3cpOworCWlmIChmICYmIGV2ZW50LT54YnV0dG9uLnR5
cGUgPT0gQnV0dG9uUHJlc3MKKwkgICAgJiYgIXBvcHVwX2FjdGl2YXRlZCAoKQorCSAgICAm
JiAheF93aW5kb3dfdG9fc2Nyb2xsX2JhciAoZXZlbnQtPnhidXR0b24uZGlzcGxheSwKKwkJ
CQkJZXZlbnQtPnhidXR0b24ud2luZG93LCAyKQorCSAgICAmJiAhRlJBTUVfTk9fQUNDRVBU
X0ZPQ1VTIChmKSkKIAkgIHsKLQkgICAgZiA9IHhfd2luZG93X3RvX2ZyYW1lIChkcHlpbmZv
LCBldmVudC0+eGJ1dHRvbi53aW5kb3cpOworCSAgICAvKiBXaGVuIGNsaWNraW5nIGludG8g
YSBjaGlsZCBmcmFtZSBvciB3aGVuIGNsaWNraW5nCisJICAgICAgIGludG8gYSBwYXJlbnQg
ZnJhbWUgd2l0aCB0aGUgY2hpbGQgZnJhbWUgc2VsZWN0ZWQgYW5kCisJICAgICAgIGBuby1h
Y2NlcHQtZm9jdXMnIGlzIG5vdCBzZXQsIHNlbGVjdCB0aGUgY2xpY2tlZAorCSAgICAgICBm
cmFtZS4gICovCisJICAgIHN0cnVjdCBmcmFtZSAqaGYgPSBkcHlpbmZvLT5oaWdobGlnaHRf
ZnJhbWU7CiAKLQkgICAgaWYgKGYgJiYgZXZlbnQtPnhidXR0b24udHlwZSA9PSBCdXR0b25Q
cmVzcwotCQkmJiAhcG9wdXBfYWN0aXZhdGVkICgpCi0JCSYmICF4X3dpbmRvd190b19zY3Jv
bGxfYmFyIChldmVudC0+eGJ1dHRvbi5kaXNwbGF5LAotCQkJCQkgICAgZXZlbnQtPnhidXR0
b24ud2luZG93LCAyKQotCQkmJiAhRlJBTUVfTk9fQUNDRVBUX0ZPQ1VTIChmKSkKKwkgICAg
aWYgKEZSQU1FX1BBUkVOVF9GUkFNRSAoZikgfHwgKGhmICYmIGZyYW1lX2FuY2VzdG9yX3Ag
KGYsIGhmKSkpCiAJICAgICAgewotCQkvKiBXaGVuIGNsaWNraW5nIGludG8gYSBjaGlsZCBm
cmFtZSBvciB3aGVuIGNsaWNraW5nCi0JCSAgIGludG8gYSBwYXJlbnQgZnJhbWUgd2l0aCB0
aGUgY2hpbGQgZnJhbWUgc2VsZWN0ZWQgYW5kCi0JCSAgIGBuby1hY2NlcHQtZm9jdXMnIGlz
IG5vdCBzZXQsIHNlbGVjdCB0aGUgY2xpY2tlZAotCQkgICBmcmFtZS4gICovCi0JCXN0cnVj
dCBmcmFtZSAqaGYgPSBkcHlpbmZvLT5oaWdobGlnaHRfZnJhbWU7Ci0KLQkJaWYgKEZSQU1F
X1BBUkVOVF9GUkFNRSAoZikgfHwgKGhmICYmIGZyYW1lX2FuY2VzdG9yX3AgKGYsIGhmKSkp
Ci0JCSAgewotCQkgICAgYmxvY2tfaW5wdXQgKCk7Ci0JCSAgICBYU2V0SW5wdXRGb2N1cyAo
RlJBTUVfWF9ESVNQTEFZIChmKSwgRlJBTUVfT1VURVJfV0lORE9XIChmKSwKLQkJCQkgICAg
UmV2ZXJ0VG9QYXJlbnQsIEN1cnJlbnRUaW1lKTsKLQkJICAgIGlmIChGUkFNRV9QQVJFTlRf
RlJBTUUgKGYpKQotCQkgICAgICBYUmFpc2VXaW5kb3cgKEZSQU1FX1hfRElTUExBWSAoZiks
IEZSQU1FX09VVEVSX1dJTkRPVyAoZikpOwotCQkgICAgdW5ibG9ja19pbnB1dCAoKTsKLQkJ
ICB9CisJCWJsb2NrX2lucHV0ICgpOworCQlYU2V0SW5wdXRGb2N1cyAoRlJBTUVfWF9ESVNQ
TEFZIChmKSwgRlJBTUVfT1VURVJfV0lORE9XIChmKSwKKwkJCQlSZXZlcnRUb1BhcmVudCwg
Q3VycmVudFRpbWUpOworCQlpZiAoRlJBTUVfUEFSRU5UX0ZSQU1FIChmKSkKKwkJICBYUmFp
c2VXaW5kb3cgKEZSQU1FX1hfRElTUExBWSAoZiksIEZSQU1FX09VVEVSX1dJTkRPVyAoZikp
OworCQl1bmJsb2NrX2lucHV0ICgpOwogCSAgICAgIH0KIAkgIH0KIAoK
--------------39FE6C27FE5DB683E2477899--




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; 27 Jul 2019 10:09:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 27 06:09:08 2019
Received: from localhost ([127.0.0.1]:43610 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hrJdU-0005hG-BW
	for submit <at> debbugs.gnu.org; Sat, 27 Jul 2019 06:09:08 -0400
Received: from eggs.gnu.org ([209.51.188.92]:34409)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>)
 id 1hrJdS-0005gc-2d; Sat, 27 Jul 2019 06:09:06 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:38263)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1hrJdM-0005l3-JF; Sat, 27 Jul 2019 06:09:00 -0400
Received: from [176.228.60.248] (port=3704 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 1hrJdM-0006wS-2a; Sat, 27 Jul 2019 06:09:00 -0400
Date: Sat, 27 Jul 2019 13:08:52 +0300
Message-Id: <8336irn617.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
In-reply-to: <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN> (message from
 martin rudalics on Sat, 27 Jul 2019 11:26:47 +0200)
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
 <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 28620
Cc: rswgnu@HIDDEN, scotto@HIDDEN, 28620 <at> debbugs.gnu.org,
 36269 <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.3 (---)

> From: martin rudalics <rudalics@HIDDEN>
> Date: Sat, 27 Jul 2019 11:26:47 +0200
> 
> I tried to address this problem in the attached patch.  Tested with
> GTK, Lucid, Motif and Windows builds.  Since my GNUstep Emacs is
> currently broken, somebody please verify that it does something
> reasonable (if anything at all) on MacOS.  Otherwise, I'd need help
> from people working there.
> 
> The patch should also fix the mouse drag and drop region vs. mouse
> avoidance mode problem.  Please someone verify that it does TRT now.

Thanks, a few minor comments below.

> +  /* If forced to complete the update, no input is pending or we are
> +     tracking the mouse do the update.  */

Commas missing here.  Should be

  /* If forced to complete the update, no input is pending, or we are
     tracking the mouse, do the update.  */


> -	  /* If this event is on a different frame, return a switch-frame this
> -	     time, and leave the event in the queue for next time.  */
> +	  /* If this event is on a different frame, return a
> +	     switch-frame this time and leave the event in the queue

A comma missing before "and".

> @@ -3995,7 +3992,7 @@ kbd_buffer_get_event (KBOARD **kbp,
>        }
>      }
>    /* Try generating a mouse motion event.  */
> -  else if (!NILP (do_mouse_tracking) && some_mouse_moved ())
> +  else if (some_mouse_moved ())

Can't we have mouse motion events outside track-mouse?

> +  DEFVAR_LISP ("track-mouse", track_mouse,
> +	       doc: /* Non-nil means generate motion events for mouse motion.
> +The sepecial values 'dragging' and 'dropping' assert that the moue
       ^^^^^^^^                                                  ^^^^
Typos.

Also, the quoting in doc strings should be `like this'.

> +      /* While dropping use the last mouse frame only if there is no
> +	 currently focused frame.  */

A comma missing before "use".

There's too much of whitespace changes in the rest of the patch,
making it very hard to review.  Can you show the patch without
whitespace differences?

Thanks.




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; 27 Jul 2019 09:27:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 27 05:27:04 2019
Received: from localhost ([127.0.0.1]:43589 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1hrIyl-0004ji-3s
	for submit <at> debbugs.gnu.org; Sat, 27 Jul 2019 05:27:04 -0400
Received: from mout.gmx.net ([212.227.17.20]:47249)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>)
 id 1hrIyh-0004j7-4e; Sat, 27 Jul 2019 05:27:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
 s=badeba3b8450; t=1564219611;
 bh=sQf0ztfyf8qHKc9gAce+WS7gI2pibKHV2EY02miFOeI=;
 h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To;
 b=N3dbwGu4oZDI+wyp9hRD8knlF2GznQ7Xn2rPiSY6cMYuIfT3xucUtsUL+SA2J3+HX
 ndev5M+1yFpulPyvp2slaVDLrzcc+Hj1VlWiJHyHkbgnvXoEBHGofR1d/76WRl8+Vw
 0wVyPboPTPbsHNeV4rILPqRQxQXBnTsTo++4dbco=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.101] ([213.162.80.250]) by mail.gmx.com (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MIx3C-1i7Jei2nVK-00KTOC; Sat, 27
 Jul 2019 11:26:50 +0200
Subject: Re: bug#28620: Mouse drag event records wrong window for release when
 crossing frames
To: rswgnu@HIDDEN, 28620 <at> debbugs.gnu.org, 36269 <at> debbugs.gnu.org,
 Scott Otterson <scotto@HIDDEN>
References: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
Message-ID: <5881afff-b233-2a01-34c3-0d7c4225875b@HIDDEN>
Date: Sat, 27 Jul 2019 11:26:47 +0200
MIME-Version: 1.0
In-Reply-To: <CA+OMD9ii+yax4Pb+UvJpF-Rj=AkxV0qDbY=ZoMarP0B6qBC42g@HIDDEN>
Content-Type: multipart/mixed; boundary="------------B7922B75546CE207C9316044"
Content-Language: de-DE
X-Provags-ID: V03:K1:ELKHQ1oVUydZPakr5y0wWKe29HXHmtSfkhZdV+h/zK5qbTOQP/y
 03SPW62Urb7fsIiBseyMZmOM5ji6tdZFoQpd4SIFoWyEcSyKQk2detW+s8PA3Ipzg4r3NNP
 cQGHm4EOdwligMv9y+arrpYSMkowphrFQBMi1eosEFbe/LJ91IMIGSQs1mWU78TF/9a9UIR
 XVwTotG6XmfZowNe4yq+w==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:vMzbYUH+jkI=:6DWA5ydhYSHmg2Ojv1sDu0
 wk1EtI91gC73E4pkwpXIQfjMk7b5mvQBv66AQ/d21kOyYiKJZQ15LUsHRdQcvV1o36RMAN48y
 yPmgMmMe1A/PJ/P0eWgZwzQG2NYBNBby9nAISW4DEj8GBlV0eLKSeeEkbG2yTtBbR1FYvzsf+
 1K3cOQATpwCtfuQz1V94qi/0WMg5+zsON4dMk5s9qfuzwQVyN0uG7YuNIlh2FrkOjjKljaz7I
 PEpJ683vdTEWndA2evFpo4EZAcv5PaSfULxt+tU8UMBnbSByVfVdKXeNsYEyosqzgbdSUwvgI
 Eolt9TF5Kg9jJ21OvUK8hMyJOMSd7sjyJAR0ZvfF8TT1nKLbLAzX04qX62ospp+Or1kamEW8x
 QDh+t4ShrmGiB7yuR9iMFtA/mMKcGojxqNrxeXnQIGVw9sx+9l6kPZbo2j+/zAzX6ef7ipz7b
 npWFYAToJDM52O+yAh91jxsGDcrvffO5RoVuPN5JBzfcbb1UxX5x3G0rdh9RV0CzRkEigB1fV
 i3OQRaMaSiT5D1gUdAO/hBWbS/1fB3R0TDUE3+cQIpxRK1cUP2bquQw1Bvn3PtPSBxYh0n6tz
 6NYCtY1uOqU1UuSCv/LpysFi2HXJ2mvVoY7bjJjLvORDbftGKn3T+/RVU2KhWOvBqRVwg87eb
 LLlQti48gCveD53/kp6y9Yp5e2mDXE0tj26N/EPbjXS+iN1e+F0/FlcmM/FgPj74ac0fiOtgG
 qIg13hjxFmrhqI7qks+mJvQLUfBy43WFw5uyDfyTiJMhHUYOfTCZxVVfwgPiiVnIJqtzelAOO
 Qk/AQz9kKgEb9LjRZS0qE6WIMp60bMEa4T42n2s3pI3x7b/6wucf7cp21ZhGgifNTE+NRxUNW
 aDTenxIdAL7vznJI0y/uBr0QX01CvonLKKf2zXeV1puAjwAf73hTj/CAoco973I8MvYpQDOc3
 h3+jYRe5Ly+dntF/oB8dgnDGWW7DAti0DWc0n+2owvCV3HgIN98zY3O8Aw2FLCufoMgTrDBCk
 c/3wwHZpgl2dLpJCrZ2ujUA4Iu3c5km6ItQeoEhnnyqynNCF5wr3fENcvMFkAfgtR9Yz7YBrh
 DtVgtkg1qKU6oY=
X-Spam-Score: 2.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:  > 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 <eve [...] 
 Content analysis details:   (2.9 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [213.162.80.250 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.17.20 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
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: 1.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:  > 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 <eve [...] 
 
 Content analysis details:   (1.9 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [213.162.80.250 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.17.20 listed in list.dnswl.org]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

This is a multi-part message in MIME format.
--------------B7922B75546CE207C9316044
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

 > 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 tried to address this problem in the attached patch.  Tested with
GTK, Lucid, Motif and Windows builds.  Since my GNUstep Emacs is
currently broken, somebody please verify that it does something
reasonable (if anything at all) on MacOS.  Otherwise, I'd need help
from people working there.

The patch should also fix the mouse drag and drop region vs. mouse
avoidance mode problem.  Please someone verify that it does TRT now.

TIA, martin

--------------B7922B75546CE207C9316044
Content-Type: text/plain; charset=UTF-8;
 name="track-mouse.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="track-mouse.diff"

ZGlmZiAtLWdpdCBhL2xpc3AvYXZvaWQuZWwgYi9saXNwL2F2b2lkLmVsCmluZGV4IDdkNjlm
YTJhMjQuLjQzZTUwNjJiNzYgMTAwNjQ0Ci0tLSBhL2xpc3AvYXZvaWQuZWwKKysrIGIvbGlz
cC9hdm9pZC5lbApAQCAtMzI3LDYgKzMyNyw5IEBAIG1vdXNlLWF2b2lkYW5jZS1pZ25vcmUt
cAogICAgICAgICBleGVjdXRpbmcta2JkLW1hY3JvCSAgICAgICA7IGRvbid0IGNoZWNrIGlu
c2lkZSBtYWNybwogCShudWxsIChjYWRyIG1wKSkJICAgICAgIDsgZG9uJ3QgbW92ZSB1bmxl
c3MgaW4gYW4gRW1hY3MgZnJhbWUKIAkobm90IChlcSAoY2FyIG1wKSAoc2VsZWN0ZWQtZnJh
bWUpKSkKKyAgICAgICAgOzsgRG9uJ3QgaW50ZXJmZXJlIHdpdGggb25nb2luZyBgbW91c2Ut
ZHJhZy1hbmQtZHJvcC1yZWdpb24nCisgICAgICAgIDs7IChCdWcjMzYyNjkpLgorICAgICAg
ICAoZXEgdHJhY2stbW91c2UgJ2Ryb3BwaW5nKQogCTs7IERvbid0IGRvIGFueXRoaW5nIGlm
IGxhc3QgZXZlbnQgd2FzIGEgbW91c2UgZXZlbnQuCiAJOzsgRklYTUU6IHRoaXMgY29kZSBm
YWlscyBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgbW91c2Ugd2FzIG1vdmVkCiAJOzsgc2luY2Ug
dGhlIGxhc3Qga2V5LXByZXNzIGJ1dCB3aXRob3V0IGdlbmVyYXRpbmcgYW55IGV2ZW50Lgpk
aWZmIC0tZ2l0IGEvbGlzcC9tb3VzZS5lbCBiL2xpc3AvbW91c2UuZWwKaW5kZXggNGE1MzJh
MTVlNS4uZTk0N2UxNmQ0NyAxMDA2NDQKLS0tIGEvbGlzcC9tb3VzZS5lbAorKysgYi9saXNw
L21vdXNlLmVsCkBAIC0xMjk2LDcgKzEyOTYsNyBAQCBtb3VzZS1kcmFnLXRyYWNrCiAgICAg
IHQgKGxhbWJkYSAoKQogICAgICAgICAgKHNldHEgdHJhY2stbW91c2Ugb2xkLXRyYWNrLW1v
dXNlKQogICAgICAgICAgKHNldHEgYXV0by1oc2Nyb2xsLW1vZGUgYXV0by1oc2Nyb2xsLW1v
ZGUtc2F2ZWQpCi0gICAgICAgICAgKGRlYWN0aXZhdGUtbWFyaykKKyAgICAgICAgIChkZWFj
dGl2YXRlLW1hcmspCiAgICAgICAgICAocG9wLW1hcmspKSkpKQogCiAoZGVmdW4gbW91c2Ut
LWRyYWctc2V0LW1hcmstYW5kLXBvaW50IChzdGFydCBjbGljayBjbGljay1jb3VudCkKQEAg
LTI0NjcsMTIgKzI0NjcsMTMgQEAgbW91c2UtZHJhZy1hbmQtZHJvcC1yZWdpb24KIAogICAg
IChpZ25vcmUtZXJyb3JzCiAgICAgICAodHJhY2stbW91c2UKKyAgICAgICAgKHNldHEgdHJh
Y2stbW91c2UgJ2Ryb3BwaW5nKQogICAgICAgICA7OyBXaGVuIGV2ZW50IHdhcyAiY2xpY2si
IGluc3RlYWQgb2YgImRyYWciLCBza2lwIGxvb3AuCiAgICAgICAgICh3aGlsZSAocHJvZ24K
ICAgICAgICAgICAgICAgICAgKHNldHEgZXZlbnQgKHJlYWQta2V5KSkgICAgICA7IHJlYWQt
ZXZlbnQgb3IgcmVhZC1rZXkKICAgICAgICAgICAgICAgICAgKG9yIChtb3VzZS1tb3ZlbWVu
dC1wIGV2ZW50KQogICAgICAgICAgICAgICAgICAgICAgOzsgSGFuZGxlIGBtb3VzZS1hdXRv
c2VsZWN0LXdpbmRvdycuCi0gICAgICAgICAgICAgICAgICAgICAoZXEgKGNhci1zYWZlIGV2
ZW50KSAnc2VsZWN0LXdpbmRvdykpKQorICAgICAgICAgICAgICAgICAgICAgKG1lbXEgKGNh
ciBldmVudCkgJyhzZWxlY3Qtd2luZG93IHN3aXRjaC1mcmFtZSkpKSkKICAgICAgICAgICA7
OyBPYnRhaW4gdGhlIGRyYWdnZWQgdGV4dCBpbiByZWdpb24uICBXaGVuIHRoZSBsb29wIHdh
cwogICAgICAgICAgIDs7IHNraXBwZWQsIHZhbHVlLXNlbGVjdGlvbiByZW1haW5zIG5pbC4K
ICAgICAgICAgICAodW5sZXNzIHZhbHVlLXNlbGVjdGlvbgpkaWZmIC0tZ2l0IGEvc3JjL2Rp
c3BuZXcuYyBiL3NyYy9kaXNwbmV3LmMKaW5kZXggMDEzMWI2Mzc2Ny4uNzRkNTNmYjQ2ZCAx
MDA2NDQKLS0tIGEvc3JjL2Rpc3BuZXcuYworKysgYi9zcmMvZGlzcG5ldy5jCkBAIC0zNDAy
LDkgKzM0MDIsOSBAQCB1cGRhdGVfd2luZG93IChzdHJ1Y3Qgd2luZG93ICp3LCBib29sIGZv
cmNlX3ApCiAgIGlmICghZm9yY2VfcCkKICAgICBkZXRlY3RfaW5wdXRfcGVuZGluZ19pZ25v
cmVfc3F1ZWV6YWJsZXMgKCk7CiAKLSAgLyogSWYgZm9yY2VkIHRvIGNvbXBsZXRlIHRoZSB1
cGRhdGUsIG9yIGlmIG5vIGlucHV0IGlzIHBlbmRpbmcsIGRvCi0gICAgIHRoZSB1cGRhdGUu
ICAqLwotICBpZiAoZm9yY2VfcCB8fCAhaW5wdXRfcGVuZGluZyB8fCAhTklMUCAoZG9fbW91
c2VfdHJhY2tpbmcpKQorICAvKiBJZiBmb3JjZWQgdG8gY29tcGxldGUgdGhlIHVwZGF0ZSwg
bm8gaW5wdXQgaXMgcGVuZGluZyBvciB3ZSBhcmUKKyAgICAgdHJhY2tpbmcgdGhlIG1vdXNl
IGRvIHRoZSB1cGRhdGUuICAqLworICBpZiAoZm9yY2VfcCB8fCAhaW5wdXRfcGVuZGluZyB8
fCAhTklMUCAodHJhY2tfbW91c2UpKQogICAgIHsKICAgICAgIHN0cnVjdCBnbHlwaF9yb3cg
KnJvdywgKmVuZDsKICAgICAgIHN0cnVjdCBnbHlwaF9yb3cgKm1vZGVfbGluZV9yb3c7CmRp
ZmYgLS1naXQgYS9zcmMva2V5Ym9hcmQuYyBiL3NyYy9rZXlib2FyZC5jCmluZGV4IGI4NmFk
MDM4NTEuLjQyMjRhYjAxYjMgMTAwNjQ0Ci0tLSBhL3NyYy9rZXlib2FyZC5jCisrKyBiL3Ny
Yy9rZXlib2FyZC5jCkBAIC0xMTU5LDE0ICsxMTU5LDE0IEBAIERFRlVOICgiYWJvcnQtcmVj
dXJzaXZlLWVkaXQiLCBGYWJvcnRfcmVjdXJzaXZlX2VkaXQsIFNhYm9ydF9yZWN1cnNpdmVf
ZWRpdCwgMCwKICAgdXNlcl9lcnJvciAoIk5vIHJlY3Vyc2l2ZSBlZGl0IGlzIGluIHByb2dy
ZXNzIik7CiB9CiAMCi0vKiBSZXN0b3JlIG1vdXNlIHRyYWNraW5nIGVuYWJsZW1lbnQuICBT
ZWUgRnRyYWNrX21vdXNlIGZvciB0aGUgb25seSB1c2UKLSAgIG9mIHRoaXMgZnVuY3Rpb24u
ICAqLworLyogUmVzdG9yZSBtb3VzZSB0cmFja2luZyBlbmFibGVtZW50LiAgU2VlIEZpbnRl
cm5hbF90cmFja19tb3VzZSBmb3IKKyAgIHRoZSBvbmx5IHVzZSBvZiB0aGlzIGZ1bmN0aW9u
LiAgKi8KIAogc3RhdGljIHZvaWQKLXRyYWNraW5nX29mZiAoTGlzcF9PYmplY3Qgb2xkX3Zh
bHVlKQordHJhY2tpbmdfb2ZmIChMaXNwX09iamVjdCBvbGRfdHJhY2tfbW91c2UpCiB7Ci0g
IGRvX21vdXNlX3RyYWNraW5nID0gb2xkX3ZhbHVlOwotICBpZiAoTklMUCAob2xkX3ZhbHVl
KSkKKyAgdHJhY2tfbW91c2UgPSBvbGRfdHJhY2tfbW91c2U7CisgIGlmIChOSUxQIChvbGRf
dHJhY2tfbW91c2UpKQogICAgIHsKICAgICAgIC8qIFJlZGlzcGxheSBtYXkgaGF2ZSBiZWVu
IHByZWVtcHRlZCBiZWNhdXNlIHRoZXJlIHdhcyBpbnB1dAogCSBhdmFpbGFibGUsIGFuZCBp
dCBhc3N1bWVzIGl0IHdpbGwgYmUgY2FsbGVkIGFnYWluIGFmdGVyIHRoZQpAQCAtMTE4MSwy
NCArMTE4MSwyNCBAQCB0cmFja2luZ19vZmYgKExpc3BfT2JqZWN0IG9sZF92YWx1ZSkKICAg
ICB9CiB9CiAKLURFRlVOICgiaW50ZXJuYWwtLXRyYWNrLW1vdXNlIiwgRnRyYWNrX21vdXNl
LCBTdHJhY2tfbW91c2UsIDEsIDEsIDAsCitERUZVTiAoImludGVybmFsLS10cmFjay1tb3Vz
ZSIsIEZpbnRlcm5hbF90cmFja19tb3VzZSwgU2ludGVybmFsX3RyYWNrX21vdXNlLAorICAg
ICAgIDEsIDEsIDAsCiAgICAgICAgZG9jOiAvKiBDYWxsIEJPRFlGVU4gd2l0aCBtb3VzZSBt
b3ZlbWVudCBldmVudHMgZW5hYmxlZC4gICovKQogICAoTGlzcF9PYmplY3QgYm9keWZ1bikK
IHsKICAgcHRyZGlmZl90IGNvdW50ID0gU1BFQ1BETF9JTkRFWCAoKTsKICAgTGlzcF9PYmpl
Y3QgdmFsOwogCi0gIHJlY29yZF91bndpbmRfcHJvdGVjdCAodHJhY2tpbmdfb2ZmLCBkb19t
b3VzZV90cmFja2luZyk7CisgIHJlY29yZF91bndpbmRfcHJvdGVjdCAodHJhY2tpbmdfb2Zm
LCB0cmFja19tb3VzZSk7CiAKLSAgZG9fbW91c2VfdHJhY2tpbmcgPSBRdDsKKyAgdHJhY2tf
bW91c2UgPSBRdDsKIAogICB2YWwgPSBjYWxsMCAoYm9keWZ1bik7CiAgIHJldHVybiB1bmJp
bmRfdG8gKGNvdW50LCB2YWwpOwogfQogCi0vKiBJZiBtb3VzZSBoYXMgbW92ZWQgb24gc29t
ZSBmcmFtZSwgcmV0dXJuIG9uZSBvZiB0aG9zZSBmcmFtZXMuCi0KLSAgIFJldHVybiAwIG90
aGVyd2lzZS4KKy8qIElmIG1vdXNlIGhhcyBtb3ZlZCBvbiBzb21lIGZyYW1lIGFuZCB3ZSBh
cmUgdHJhY2tpbmcgdGhlIG1vdXNlLAorICAgcmV0dXJuIG9uZSBvZiB0aG9zZSBmcmFtZXMu
ICBSZXR1cm4gTlVMTCBvdGhlcndpc2UuCiAKICAgIElmIGlnbm9yZV9tb3VzZV9kcmFnX3Ag
aXMgbm9uLXplcm8sIGlnbm9yZSAoaW1wbGljaXQpIG1vdXNlIG1vdmVtZW50CiAgICBhZnRl
ciByZXNpemluZyB0aGUgdG9vbC1iYXIgd2luZG93LiAgKi8KQEAgLTEyMTAsMTEgKzEyMTAs
OCBAQCBzb21lX21vdXNlX21vdmVkICh2b2lkKQogewogICBMaXNwX09iamVjdCB0YWlsLCBm
cmFtZTsKIAotICBpZiAoaWdub3JlX21vdXNlX2RyYWdfcCkKLSAgICB7Ci0gICAgICAvKiBp
Z25vcmVfbW91c2VfZHJhZ19wID0gZmFsc2U7ICovCi0gICAgICByZXR1cm4gMDsKLSAgICB9
CisgIGlmIChOSUxQICh0cmFja19tb3VzZSkgfHwgaWdub3JlX21vdXNlX2RyYWdfcCkKKyAg
ICByZXR1cm4gTlVMTDsKIAogICBGT1JfRUFDSF9GUkFNRSAodGFpbCwgZnJhbWUpCiAgICAg
ewpAQCAtMTIyMiw3ICsxMjE5LDcgQEAgc29tZV9tb3VzZV9tb3ZlZCAodm9pZCkKIAlyZXR1
cm4gWEZSQU1FIChmcmFtZSk7CiAgICAgfQogCi0gIHJldHVybiAwOworICByZXR1cm4gTlVM
TDsKIH0KIAogDApAQCAtMjA3MSw3ICsyMDY4LDggQEAgc2hvd19oZWxwX2VjaG8gKExpc3Bf
T2JqZWN0IGhlbHAsIExpc3BfT2JqZWN0IHdpbmRvdywgTGlzcF9PYmplY3Qgb2JqZWN0LAog
CSBUaGlzIGNhdXNlcyB0cm91YmxlIGlmIHdlIGFyZSB0cnlpbmcgdG8gcmVhZCBhIG1vdXNl
IG1vdGlvbgogCSBldmVudCAoaS5lLiwgaWYgd2UgYXJlIGluc2lkZSBhIGB0cmFjay1tb3Vz
ZScgZm9ybSksIHNvIHdlCiAJIHJlc3RvcmUgdGhlIG1vdXNlX21vdmVkIGZsYWcuICAqLwot
ICAgICAgc3RydWN0IGZyYW1lICpmID0gTklMUCAoZG9fbW91c2VfdHJhY2tpbmcpID8gTlVM
TCA6IHNvbWVfbW91c2VfbW92ZWQgKCk7CisgICAgICBzdHJ1Y3QgZnJhbWUgKmYgPSBzb21l
X21vdXNlX21vdmVkICgpOworCiAgICAgICBoZWxwID0gY2FsbDEgKFFtb3VzZV9maXh1cF9o
ZWxwX21lc3NhZ2UsIGhlbHApOwogICAgICAgaWYgKGYpCiAJZi0+bW91c2VfbW92ZWQgPSB0
cnVlOwpAQCAtMzQwMyw4ICszNDAxLDcgQEAgcmVhZGFibGVfZXZlbnRzIChpbnQgZmxhZ3Mp
CiAJcmV0dXJuIDE7CiAgICAgfQogCi0gIGlmICghKGZsYWdzICYgUkVBREFCTEVfRVZFTlRT
X0lHTk9SRV9TUVVFRVpBQkxFUykKLSAgICAgICYmICFOSUxQIChkb19tb3VzZV90cmFja2lu
ZykgJiYgc29tZV9tb3VzZV9tb3ZlZCAoKSkKKyAgaWYgKCEoZmxhZ3MgJiBSRUFEQUJMRV9F
VkVOVFNfSUdOT1JFX1NRVUVFWkFCTEVTKSAmJiBzb21lX21vdXNlX21vdmVkICgpKQogICAg
IHJldHVybiAxOwogICBpZiAoc2luZ2xlX2tib2FyZCkKICAgICB7CkBAIC0zNzg2LDcgKzM3
ODMsNyBAQCBrYmRfYnVmZmVyX2dldF9ldmVudCAoS0JPQVJEICoqa2JwLAogCiAgICAgICBp
ZiAoa2JkX2ZldGNoX3B0ciAhPSBrYmRfc3RvcmVfcHRyKQogCWJyZWFrOwotICAgICAgaWYg
KCFOSUxQIChkb19tb3VzZV90cmFja2luZykgJiYgc29tZV9tb3VzZV9tb3ZlZCAoKSkKKyAg
ICAgIGlmIChzb21lX21vdXNlX21vdmVkICgpKQogCWJyZWFrOwogCiAgICAgICAvKiBJZiB0
aGUgcXVpdCBmbGFnIGlzIHNldCwgdGhlbiByZWFkX2NoYXIgd2lsbCByZXR1cm4KQEAgLTM4
MDIsNyArMzc5OSw3IEBAIGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKiprYnAsCiAj
ZW5kaWYKICAgICAgIGlmIChrYmRfZmV0Y2hfcHRyICE9IGtiZF9zdG9yZV9wdHIpCiAJYnJl
YWs7Ci0gICAgICBpZiAoIU5JTFAgKGRvX21vdXNlX3RyYWNraW5nKSAmJiBzb21lX21vdXNl
X21vdmVkICgpKQorICAgICAgaWYgKHNvbWVfbW91c2VfbW92ZWQgKCkpCiAJYnJlYWs7CiAg
ICAgICBpZiAoZW5kX3RpbWUpCiAJewpAQCAtMzk0MSw4ICszOTM4LDkgQEAga2JkX2J1ZmZl
cl9nZXRfZXZlbnQgKEtCT0FSRCAqKmticCwKICAgICAgICAgYnJlYWs7CiAgICAgICBkZWZh
dWx0OgogCXsKLQkgIC8qIElmIHRoaXMgZXZlbnQgaXMgb24gYSBkaWZmZXJlbnQgZnJhbWUs
IHJldHVybiBhIHN3aXRjaC1mcmFtZSB0aGlzCi0JICAgICB0aW1lLCBhbmQgbGVhdmUgdGhl
IGV2ZW50IGluIHRoZSBxdWV1ZSBmb3IgbmV4dCB0aW1lLiAgKi8KKwkgIC8qIElmIHRoaXMg
ZXZlbnQgaXMgb24gYSBkaWZmZXJlbnQgZnJhbWUsIHJldHVybiBhCisJICAgICBzd2l0Y2gt
ZnJhbWUgdGhpcyB0aW1lIGFuZCBsZWF2ZSB0aGUgZXZlbnQgaW4gdGhlIHF1ZXVlCisJICAg
ICBmb3IgbmV4dCB0aW1lLiAgKi8KIAkgIExpc3BfT2JqZWN0IGZyYW1lOwogCSAgTGlzcF9P
YmplY3QgZm9jdXM7CiAKQEAgLTM5NTYsMTQgKzM5NTQsMTMgQEAga2JkX2J1ZmZlcl9nZXRf
ZXZlbnQgKEtCT0FSRCAqKmticCwKIAkgIGlmICghIE5JTFAgKGZvY3VzKSkKIAkgICAgZnJh
bWUgPSBmb2N1czsKIAotCSAgaWYgKCEgRVEgKGZyYW1lLCBpbnRlcm5hbF9sYXN0X2V2ZW50
X2ZyYW1lKQorCSAgaWYgKCFFUSAoZnJhbWUsIGludGVybmFsX2xhc3RfZXZlbnRfZnJhbWUp
CiAJICAgICAgJiYgIUVRIChmcmFtZSwgc2VsZWN0ZWRfZnJhbWUpKQogCSAgICBvYmogPSBt
YWtlX2xpc3B5X3N3aXRjaF9mcmFtZSAoZnJhbWUpOwogCSAgaW50ZXJuYWxfbGFzdF9ldmVu
dF9mcmFtZSA9IGZyYW1lOwogCiAJICAvKiBJZiB3ZSBkaWRuJ3QgZGVjaWRlIHRvIG1ha2Ug
YSBzd2l0Y2gtZnJhbWUgZXZlbnQsIGdvIGFoZWFkCiAJICAgICBhbmQgYnVpbGQgYSByZWFs
IGV2ZW50IGZyb20gdGhlIHF1ZXVlIGVudHJ5LiAgKi8KLQogCSAgaWYgKE5JTFAgKG9iaikp
CiAJICAgIHsKIAkgICAgICBvYmogPSBtYWtlX2xpc3B5X2V2ZW50ICgmZXZlbnQtPmllKTsK
QEAgLTM5OTUsNyArMzk5Miw3IEBAIGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKipr
YnAsCiAgICAgICB9CiAgICAgfQogICAvKiBUcnkgZ2VuZXJhdGluZyBhIG1vdXNlIG1vdGlv
biBldmVudC4gICovCi0gIGVsc2UgaWYgKCFOSUxQIChkb19tb3VzZV90cmFja2luZykgJiYg
c29tZV9tb3VzZV9tb3ZlZCAoKSkKKyAgZWxzZSBpZiAoc29tZV9tb3VzZV9tb3ZlZCAoKSkK
ICAgICB7CiAgICAgICBzdHJ1Y3QgZnJhbWUgKmYgPSBzb21lX21vdXNlX21vdmVkICgpOwog
ICAgICAgTGlzcF9PYmplY3QgYmFyX3dpbmRvdzsKQEAgLTQwMjcsNyArNDAyNCw3IEBAIGti
ZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKiprYnAsCiAJICBpZiAoTklMUCAoZnJhbWUp
KQogCSAgICBYU0VURlJBTUUgKGZyYW1lLCBmKTsKIAotCSAgaWYgKCEgRVEgKGZyYW1lLCBp
bnRlcm5hbF9sYXN0X2V2ZW50X2ZyYW1lKQorCSAgaWYgKCFFUSAoZnJhbWUsIGludGVybmFs
X2xhc3RfZXZlbnRfZnJhbWUpCiAJICAgICAgJiYgIUVRIChmcmFtZSwgc2VsZWN0ZWRfZnJh
bWUpKQogCSAgICBvYmogPSBtYWtlX2xpc3B5X3N3aXRjaF9mcmFtZSAoZnJhbWUpOwogCSAg
aW50ZXJuYWxfbGFzdF9ldmVudF9mcmFtZSA9IGZyYW1lOwpAQCAtMTA5MzUsNyArMTA5MzIs
NyBAQCBpbml0X2tleWJvYXJkICh2b2lkKQogICByZWNlbnRfa2V5c19pbmRleCA9IDA7CiAg
IGtiZF9mZXRjaF9wdHIgPSBrYmRfYnVmZmVyOwogICBrYmRfc3RvcmVfcHRyID0ga2JkX2J1
ZmZlcjsKLSAgZG9fbW91c2VfdHJhY2tpbmcgPSBRbmlsOworICB0cmFja19tb3VzZSA9IFFu
aWw7CiAgIGlucHV0X3BlbmRpbmcgPSBmYWxzZTsKICAgaW50ZXJydXB0X2lucHV0X2Jsb2Nr
ZWQgPSAwOwogICBwZW5kaW5nX3NpZ25hbHMgPSBmYWxzZTsKQEAgLTExMjk3LDcgKzExMjk0
LDcgQEAgc3ltc19vZl9rZXlib2FyZCAodm9pZCkKICAgZGVmc3ViciAoJlNyZWFkX2tleV9z
ZXF1ZW5jZSk7CiAgIGRlZnN1YnIgKCZTcmVhZF9rZXlfc2VxdWVuY2VfdmVjdG9yKTsKICAg
ZGVmc3ViciAoJlNyZWN1cnNpdmVfZWRpdCk7Ci0gIGRlZnN1YnIgKCZTdHJhY2tfbW91c2Up
OworICBkZWZzdWJyICgmU2ludGVybmFsX3RyYWNrX21vdXNlKTsKICAgZGVmc3ViciAoJlNp
bnB1dF9wZW5kaW5nX3ApOwogICBkZWZzdWJyICgmU3JlY2VudF9rZXlzKTsKICAgZGVmc3Vi
ciAoJlN0aGlzX2NvbW1hbmRfa2V5cyk7CkBAIC0xMTY0Miw4ICsxMTYzOSwxNSBAQCBhbmQg
dGhlIG1pbm9yIG1vZGUgbWFwcyByZWdhcmRsZXNzIG9mIGBvdmVycmlkaW5nLWxvY2FsLW1h
cCcuICAqLyk7CiAJICAgICAgIGRvYzogLyogS2V5bWFwIGRlZmluaW5nIGJpbmRpbmdzIGZv
ciBzcGVjaWFsIGV2ZW50cyB0byBleGVjdXRlIGF0IGxvdyBsZXZlbC4gICovKTsKICAgVnNw
ZWNpYWxfZXZlbnRfbWFwID0gbGlzdDEgKFFrZXltYXApOwogCi0gIERFRlZBUl9MSVNQICgi
dHJhY2stbW91c2UiLCBkb19tb3VzZV90cmFja2luZywKLQkgICAgICAgZG9jOiAvKiBOb24t
bmlsIG1lYW5zIGdlbmVyYXRlIG1vdGlvbiBldmVudHMgZm9yIG1vdXNlIG1vdGlvbi4gICov
KTsKKyAgREVGVkFSX0xJU1AgKCJ0cmFjay1tb3VzZSIsIHRyYWNrX21vdXNlLAorCSAgICAg
ICBkb2M6IC8qIE5vbi1uaWwgbWVhbnMgZ2VuZXJhdGUgbW90aW9uIGV2ZW50cyBmb3IgbW91
c2UgbW90aW9uLgorVGhlIHNlcGVjaWFsIHZhbHVlcyAnZHJhZ2dpbmcnIGFuZCAnZHJvcHBp
bmcnIGFzc2VydCB0aGF0IHRoZSBtb3VlCitjdXJzb3IgcmV0YWlucyBpdHMgYXBwZWFyYW5j
ZSBkdXJpbmcgbW91c2UgbW90aW9uLiAgQW55IG5vbi1uaWwgdmFsdWUKK2J1dCAnZHJvcHBp
bmcnIGFzc2VydHMgdGhhdCBtb3Rpb24gZXZlbnRzIGFsd2F5cyByZWxhdGUgdG8gdGhlIGZy
YW1lCit3aGVyZSB0aGUgdGhlIG1vdXNlIG1vdmVtZW50IHN0YXJ0ZWQuICBUaGUgdmFsdWUg
J2Ryb3BwaW5nJyBhc3NlcnRzCit0aGF0IG1vdGlvbiBldmVudHMgcmVsYXRlIHRvIHRoZSBm
cmFtZSB3aGVyZSB0aGUgbW91c2UgY3Vyc29yIGlzIHNlZW4KK3doZW4gZ2VuZXJhdGluZyB0
aGUgZXZlbnQuICBJZiB0aGVyZSdzIG5vIHN1Y2ggZnJhbWUsIHN1Y2ggbW90aW9uCitldmVu
dHMgcmVsYXRlIHRvIHRoZSBmcmFtZSB3aGVyZSB0aGUgbW91c2UgbW92ZW1lbnQgc3RhcnRl
ZC4gICovKTsKIAogICBERUZWQVJfS0JPQVJEICgic3lzdGVtLWtleS1hbGlzdCIsIFZzeXN0
ZW1fa2V5X2FsaXN0LAogCQkgZG9jOiAvKiBBbGlzdCBvZiBzeXN0ZW0tc3BlY2lmaWMgWCB3
aW5kb3dzIGtleSBzeW1ib2xzLgpkaWZmIC0tZ2l0IGEvc3JjL25zdGVybS5tIGIvc3JjL25z
dGVybS5tCmluZGV4IDAyMzMxODI2ZDkuLjc1YmY4NTYxN2IgMTAwNjQ0Ci0tLSBhL3NyYy9u
c3Rlcm0ubQorKysgYi9zcmMvbnN0ZXJtLm0KQEAgLTI0ODAsNyArMjQ4MCwxMSBAQCBzbyBz
b21lIGtleSBwcmVzc2VzIChUQUIpIGFyZSBzd2FsbG93ZWQgYnkgdGhlIHN5c3RlbS4gICov
CiAgICAgICBYRlJBTUUgKGZyYW1lKS0+bW91c2VfbW92ZWQgPSAwOwogCiAgIGRweWluZm8t
Pmxhc3RfbW91c2Vfc2Nyb2xsX2JhciA9IG5pbDsKKyAgZiA9IGRweWluZm8tPm5zX2ZvY3Vz
X2ZyYW1lID8gZHB5aW5mby0+bnNfZm9jdXNfZnJhbWUgOiBTRUxFQ1RFRF9GUkFNRSAoKTsK
ICAgaWYgKGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWUKKyAgICAgIC8qIFdoaWxlIGRyb3Bw
aW5nIHVzZSB0aGUgbGFzdCBtb3VzZSBmcmFtZSBvbmx5IGlmIHRoZXJlIGlzIG5vCisJIGN1
cnJlbnRseSBmb2N1c2VkIGZyYW1lLiAgKi8KKyAgICAgICYmICghRVEgKHRyYWNrX21vdXNl
LCBRZHJvcHBpbmcpIHx8ICFmKQogICAgICAgJiYgRlJBTUVfTElWRV9QIChkcHlpbmZvLT5s
YXN0X21vdXNlX2ZyYW1lKSkKICAgICBmID0gZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZTsK
ICAgZWxzZQpkaWZmIC0tZ2l0IGEvc3JjL3Rlcm0uYyBiL3NyYy90ZXJtLmMKaW5kZXggYjA1
OGQ4YmRhZC4uYTg4ZDQ3ZjkyMyAxMDA2NDQKLS0tIGEvc3JjL3Rlcm0uYworKysgYi9zcmMv
dGVybS5jCkBAIC0zMDMzLDE4ICszMDMzLDE4IEBAIHJlYWRfbWVudV9pbnB1dCAoc3RydWN0
IGZyYW1lICpzZiwgaW50ICp4LCBpbnQgKnksIGludCBtaW5feSwgaW50IG1heF95LAogICAg
ICAgYm9vbCB1c2FibGVfaW5wdXQgPSAxOwogICAgICAgbWlfcmVzdWx0IHN0ID0gTUlfQ09O
VElOVUU7CiAgICAgICBzdHJ1Y3QgdHR5X2Rpc3BsYXlfaW5mbyAqdHR5ID0gRlJBTUVfVFRZ
IChzZik7Ci0gICAgICBMaXNwX09iamVjdCBzYXZlZF9tb3VzZV90cmFja2luZyA9IGRvX21v
dXNlX3RyYWNraW5nOworICAgICAgTGlzcF9PYmplY3Qgb2xkX3RyYWNrX21vdXNlID0gdHJh
Y2tfbW91c2U7CiAKICAgICAgIC8qIFNpZ25hbCB0aGUga2V5Ym9hcmQgcmVhZGluZyByb3V0
aW5lcyB3ZSBhcmUgZGlzcGxheWluZyBhIG1lbnUKIAkgb24gdGhpcyB0ZXJtaW5hbC4gICov
CiAgICAgICB0dHktPnNob3dpbmdfbWVudSA9IDE7CiAgICAgICAvKiBXZSB3YW50IG1vdXNl
IG1vdmVtZW50cyBiZSByZXBvcnRlZCBieSByZWFkX21lbnVfY29tbWFuZC4gICovCi0gICAg
ICBkb19tb3VzZV90cmFja2luZyA9IFF0OworICAgICAgdHJhY2tfbW91c2UgPSBRdDsKICAg
ICAgIGRvIHsKIAljbWQgPSByZWFkX21lbnVfY29tbWFuZCAoKTsKICAgICAgIH0gd2hpbGUg
KE5JTFAgKGNtZCkpOwogICAgICAgdHR5LT5zaG93aW5nX21lbnUgPSAwOwotICAgICAgZG9f
bW91c2VfdHJhY2tpbmcgPSBzYXZlZF9tb3VzZV90cmFja2luZzsKKyAgICAgIHRyYWNrX21v
dXNlID0gb2xkX3RyYWNrX21vdXNlOwogCiAgICAgICBpZiAoRVEgKGNtZCwgUXQpIHx8IEVR
IChjbWQsIFF0dHlfbWVudV9leGl0KQogCSAgLyogSWYgc29tZSBpbnB1dCBzd2l0Y2hlZCBm
cmFtZXMgdW5kZXIgb3VyIGZlZXQsIGV4aXQgdGhlCmRpZmYgLS1naXQgYS9zcmMvdzMyZm5z
LmMgYi9zcmMvdzMyZm5zLmMKaW5kZXggYWNkOWM4MDUyOC4uYTJhODhiMjU4OCAxMDA2NDQK
LS0tIGEvc3JjL3czMmZucy5jCisrKyBiL3NyYy93MzJmbnMuYwpAQCAtNDU4Niw3ICs0NTg2
LDggQEAgdzMyX3duZF9wcm9jIChIV05EIGh3bmQsIFVJTlQgbXNnLCBXUEFSQU0gd1BhcmFt
LCBMUEFSQU0gbFBhcmFtKQogCWlmIChidXR0b25fc3RhdGUgJiB0aGlzKQogCSAgcmV0dXJu
IDA7CiAKLQlpZiAoYnV0dG9uX3N0YXRlID09IDApCisJLyogRG9uJ3QgY2FwdHVyZSBtb3Vz
ZSB3aGVuIGRyb3BwaW5nLiAgKi8KKwlpZiAoYnV0dG9uX3N0YXRlID09IDAgJiYgIUVRICh0
cmFja19tb3VzZSwgUWRyb3BwaW5nKSkKIAkgIFNldENhcHR1cmUgKGh3bmQpOwogCiAJYnV0
dG9uX3N0YXRlIHw9IHRoaXM7CkBAIC00NzA3LDggKzQ3MDgsMTEgQEAgdzMyX3duZF9wcm9j
IChIV05EIGh3bmQsIFVJTlQgbXNnLCBXUEFSQU0gd1BhcmFtLCBMUEFSQU0gbFBhcmFtKQog
CiAJaWYgKHBhcnNlX2J1dHRvbiAobXNnLCBISVdPUkQgKHdQYXJhbSksICZidXR0b24sICZ1
cCkpCiAJICB7Ci0JICAgIGlmICh1cCkgUmVsZWFzZUNhcHR1cmUgKCk7Ci0JICAgIGVsc2Ug
U2V0Q2FwdHVyZSAoaHduZCk7CisJICAgIGlmICh1cCkKKwkgICAgICBSZWxlYXNlQ2FwdHVy
ZSAoKTsKKwkgICAgLyogRG9uJ3QgY2FwdHVyZSBtb3VzZSB3aGVuIGRyb3BwaW5nLiAgKi8K
KwkgICAgZWxzZSBpZiAoIUVRICh0cmFja19tb3VzZSwgUWRyb3BwaW5nKSkKKwkgICAgICBT
ZXRDYXB0dXJlIChod25kKTsKIAkgICAgYnV0dG9uID0gKGJ1dHRvbiA9PSAwKSA/IExNT1VT
RSA6CiAJICAgICAgKChidXR0b24gPT0gMSkgPyBNTU9VU0UgIDogUk1PVVNFKTsKIAkgICAg
aWYgKHVwKQpAQCAtNTM1MSw4ICs1MzU1LDkgQEAgdzMyX3duZF9wcm9jIChIV05EIGh3bmQs
IFVJTlQgbXNnLCBXUEFSQU0gd1BhcmFtLCBMUEFSQU0gbFBhcmFtKQogCWVsc2UgaWYgKGJ1
dHRvbl9zdGF0ZSAmIFJNT1VTRSkKIAkgIGZsYWdzIHw9IFRQTV9SSUdIVEJVVFRPTjsKIAot
CS8qIFJlbWVtYmVyIHdlIGRpZCBhIFNldENhcHR1cmUgb24gdGhlIGluaXRpYWwgbW91c2Ug
ZG93biBldmVudCwKLQkgICBzbyBmb3Igc2FmZXR5LCB3ZSBtYWtlIHN1cmUgdGhlIGNhcHR1
cmUgaXMgY2FuY2VsZWQgbm93LiAgKi8KKwkvKiBXZSBtYXkgaGF2ZSBkb25lIGEgU2V0Q2Fw
dHVyZSBvbiB0aGUgaW5pdGlhbCBtb3VzZSBkb3duCisJICAgZXZlbnQsIHNvIGZvciBzYWZl
dHksIG1ha2Ugc3VyZSB0aGUgY2FwdHVyZSBpcyBjYW5jZWxlZAorCSAgIG5vdy4gICovCiAJ
UmVsZWFzZUNhcHR1cmUgKCk7CiAJYnV0dG9uX3N0YXRlID0gMDsKIApkaWZmIC0tZ2l0IGEv
c3JjL3czMnRlcm0uYyBiL3NyYy93MzJ0ZXJtLmMKaW5kZXggYzZlMTc1ZTdlNS4uYWQ5NjI4
N2E0MyAxMDA2NDQKLS0tIGEvc3JjL3czMnRlcm0uYworKysgYi9zcmMvdzMydGVybS5jCkBA
IC0zNTI1LDcyICszNTI1LDc4IEBAIHczMl9tb3VzZV9wb3NpdGlvbiAoc3RydWN0IGZyYW1l
ICoqZnAsIGludCBpbnNpc3QsIExpc3BfT2JqZWN0ICpiYXJfd2luZG93LAogCiAgICAgICAv
KiBOb3cgd2UgaGF2ZSBhIHBvc2l0aW9uIG9uIHRoZSByb290OyBmaW5kIHRoZSBpbm5lcm1v
c3Qgd2luZG93CiAJIGNvbnRhaW5pbmcgdGhlIHBvaW50ZXIuICAqLwotICAgICAgewotCS8q
IElmIG1vdXNlIHdhcyBncmFiYmVkIG9uIGEgZnJhbWUsIGdpdmUgY29vcmRzIGZvciB0aGF0
Ci0JICAgZnJhbWUgZXZlbiBpZiB0aGUgbW91c2UgaXMgbm93IG91dHNpZGUgaXQuICBPdGhl
cndpc2UKLQkgICBjaGVjayBmb3Igd2luZG93IHVuZGVyIG1vdXNlIG9uIG9uZSBvZiBvdXIg
ZnJhbWVzLiAgKi8KLQlpZiAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pKQotCSAgZjEg
PSBkcHlpbmZvLT5sYXN0X21vdXNlX2ZyYW1lOwotCWVsc2UKLQkgIHsKLQkgICAgSFdORCB3
ZnAgPSBXaW5kb3dGcm9tUG9pbnQgKHB0KTsKIAotCSAgICBpZiAod2ZwKQotCSAgICAgIHsK
LQkJZjEgPSB3MzJfd2luZG93X3RvX2ZyYW1lIChkcHlpbmZvLCB3ZnApOwotCQlpZiAoZjEp
Ci0JCSAgewotCQkgICAgSFdORCBjd2ZwID0gQ2hpbGRXaW5kb3dGcm9tUG9pbnQgKHdmcCwg
cHQpOworICAgICAgLyogSWYgbW91c2Ugd2FzIGdyYWJiZWQgb24gYSBmcmFtZSBhbmQgd2Ug
YXJlIG5vdCBkcm9wcGluZywKKwkgZ2l2ZSBjb29yZHMgZm9yIHRoYXQgZnJhbWUgZXZlbiBp
ZiB0aGUgbW91c2UgaXMgbm93IG91dHNpZGUKKwkgaXQuICBPdGhlcndpc2UgY2hlY2sgZm9y
IHdpbmRvdyB1bmRlciBtb3VzZSBvbiBvbmUgb2Ygb3VyCisJIGZyYW1lcy4gICovCisgICAg
ICBpZiAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pICYmICFFUSAodHJhY2tfbW91c2Us
IFFkcm9wcGluZykpCisJZjEgPSBkcHlpbmZvLT5sYXN0X21vdXNlX2ZyYW1lOworICAgICAg
ZWxzZQorCXsKKwkgIEhXTkQgd2ZwID0gV2luZG93RnJvbVBvaW50IChwdCk7CiAKLQkJICAg
IGlmIChjd2ZwKQotCQkgICAgICB7Ci0JCQlzdHJ1Y3QgZnJhbWUgKmYyID0gdzMyX3dpbmRv
d190b19mcmFtZSAoZHB5aW5mbywgY3dmcCk7CisJICBpZiAod2ZwKQorCSAgICB7CisJICAg
ICAgZjEgPSB3MzJfd2luZG93X3RvX2ZyYW1lIChkcHlpbmZvLCB3ZnApOworCSAgICAgIGlm
IChmMSkKKwkJeworCQkgIEhXTkQgY3dmcCA9IENoaWxkV2luZG93RnJvbVBvaW50ICh3ZnAs
IHB0KTsKIAotCQkJLyogSWYgYSBjaGlsZCB3aW5kb3cgd2FzIGZvdW5kLCBtYWtlIHN1cmUg
dGhhdCBpdHMKLQkJCSAgIGZyYW1lIGlzIGEgY2hpbGQgZnJhbWUgKEJ1ZyMyNjYxNSwgbWF5
YmUpLiAgKi8KLQkJCWlmIChmMiAmJiBGUkFNRV9QQVJFTlRfRlJBTUUgKGYyKSkKLQkJCSAg
ZjEgPSBmMjsKLQkJICAgICAgfQotCQkgIH0KLQkgICAgICB9Ci0JICB9CisJCSAgaWYgKGN3
ZnApCisJCSAgICB7CisJCSAgICAgIHN0cnVjdCBmcmFtZSAqZjIgPSB3MzJfd2luZG93X3Rv
X2ZyYW1lIChkcHlpbmZvLCBjd2ZwKTsKIAotCS8qIElmIG5vdCwgaXMgaXQgb25lIG9mIG91
ciBzY3JvbGwgYmFycz8gICovCi0JaWYgKCEgZjEpCi0JICB7Ci0JICAgIHN0cnVjdCBzY3Jv
bGxfYmFyICpiYXIKLSAgICAgICAgICAgICAgPSB3MzJfd2luZG93X3RvX3Njcm9sbF9iYXIg
KFdpbmRvd0Zyb21Qb2ludCAocHQpLCAyKTsKKwkJICAgICAgLyogSWYgYSBjaGlsZCB3aW5k
b3cgd2FzIGZvdW5kLCBtYWtlIHN1cmUgdGhhdCBpdHMKKwkJCSBmcmFtZSBpcyBhIGNoaWxk
IGZyYW1lIChCdWcjMjY2MTUsIG1heWJlKS4gICovCisJCSAgICAgIGlmIChmMiAmJiBGUkFN
RV9QQVJFTlRfRlJBTUUgKGYyKSkKKwkJCWYxID0gZjI7CisJCSAgICB9CisJCX0KKwkgICAg
fQorCX0KIAotCSAgICBpZiAoYmFyKQotCSAgICAgIGYxID0gWEZSQU1FIChXSU5ET1dfRlJB
TUUgKFhXSU5ET1cgKGJhci0+d2luZG93KSkpOwotCSAgfQorICAgICAgaWYgKCFmMSB8fCBG
UkFNRV9UT09MVElQX1AgKGYxKSkKKwkvKiBEb24ndCB1c2UgYSB0b29sdGlwIGZyYW1lLiAg
Ki8KKwlmMSA9ICgoRVEgKHRyYWNrX21vdXNlLCBRZHJvcHBpbmcpICYmIGd1aV9tb3VzZV9n
cmFiYmVkIChkcHlpbmZvKSkKKwkgICAgICA/IGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWUK
KwkgICAgICA6IE5VTEwpOwogCi0JaWYgKGYxID09IDAgJiYgaW5zaXN0ID4gMCkKLQkgIGYx
ID0gU0VMRUNURURfRlJBTUUgKCk7CisgICAgICAvKiBJZiBub3QsIGlzIGl0IG9uZSBvZiBv
dXIgc2Nyb2xsIGJhcnM/ICAqLworICAgICAgaWYgKCFmMSkKKwl7CisJICBzdHJ1Y3Qgc2Ny
b2xsX2JhciAqYmFyCisJICAgID0gdzMyX3dpbmRvd190b19zY3JvbGxfYmFyIChXaW5kb3dG
cm9tUG9pbnQgKHB0KSwgMik7CiAKLQlpZiAoZjEpCi0JICB7Ci0JICAgIC8qIE9rLCB3ZSBm
b3VuZCBhIGZyYW1lLiAgU3RvcmUgYWxsIHRoZSB2YWx1ZXMuCi0JICAgICAgIGxhc3RfbW91
c2VfZ2x5cGggaXMgYSByZWN0YW5nbGUgdXNlZCB0byByZWR1Y2UgdGhlCi0JICAgICAgIGdl
bmVyYXRpb24gb2YgbW91c2UgZXZlbnRzLiAgVG8gbm90IG1pc3MgYW55IG1vdGlvbgotCSAg
ICAgICBldmVudHMsIHdlIG11c3QgZGl2aWRlIHRoZSBmcmFtZSBpbnRvIHJlY3RhbmdsZXMg
b2YgdGhlCi0JICAgICAgIHNpemUgb2YgdGhlIHNtYWxsZXN0IGNoYXJhY3RlciB0aGF0IGNv
dWxkIGJlIGRpc3BsYXllZAotCSAgICAgICBvbiBpdCwgaS5lLiBpbnRvIHRoZSBzYW1lIHJl
Y3RhbmdsZXMgdGhhdCBtYXRyaWNlcyBvbgotCSAgICAgICB0aGUgZnJhbWUgYXJlIGRpdmlk
ZWQgaW50by4gICovCi0KLQkgICAgZHB5aW5mbyA9IEZSQU1FX0RJU1BMQVlfSU5GTyAoZjEp
OwotCSAgICBTY3JlZW5Ub0NsaWVudCAoRlJBTUVfVzMyX1dJTkRPVyAoZjEpLCAmcHQpOwot
CSAgICByZW1lbWJlcl9tb3VzZV9nbHlwaCAoZjEsIHB0LngsIHB0LnksICZkcHlpbmZvLT5s
YXN0X21vdXNlX2dseXBoKTsKLQkgICAgZHB5aW5mby0+bGFzdF9tb3VzZV9nbHlwaF9mcmFt
ZSA9IGYxOwotCi0JICAgICpiYXJfd2luZG93ID0gUW5pbDsKLQkgICAgKnBhcnQgPSBzY3Jv
bGxfYmFyX2Fib3ZlX2hhbmRsZTsKLQkgICAgKmZwID0gZjE7Ci0JICAgIFhTRVRJTlQgKCp4
LCBwdC54KTsKLQkgICAgWFNFVElOVCAoKnksIHB0LnkpOwotCSAgICAqdGltZSA9IGRweWlu
Zm8tPmxhc3RfbW91c2VfbW92ZW1lbnRfdGltZTsKLQkgIH0KLSAgICAgIH0KKwkgIGlmIChi
YXIpCisJICAgIGYxID0gWEZSQU1FIChXSU5ET1dfRlJBTUUgKFhXSU5ET1cgKGJhci0+d2lu
ZG93KSkpOworCX0KKworICAgICAgaWYgKCFmMSAmJiBpbnNpc3QgPiAwKQorCWYxID0gU0VM
RUNURURfRlJBTUUgKCk7CisKKyAgICAgIGlmIChmMSkKKwl7CisJICAvKiBPaywgd2UgZm91
bmQgYSBmcmFtZS4gIFN0b3JlIGFsbCB0aGUgdmFsdWVzLgorCSAgICAgbGFzdF9tb3VzZV9n
bHlwaCBpcyBhIHJlY3RhbmdsZSB1c2VkIHRvIHJlZHVjZSB0aGUKKwkgICAgIGdlbmVyYXRp
b24gb2YgbW91c2UgZXZlbnRzLiAgVG8gbm90IG1pc3MgYW55IG1vdGlvbgorCSAgICAgZXZl
bnRzLCB3ZSBtdXN0IGRpdmlkZSB0aGUgZnJhbWUgaW50byByZWN0YW5nbGVzIG9mIHRoZQor
CSAgICAgc2l6ZSBvZiB0aGUgc21hbGxlc3QgY2hhcmFjdGVyIHRoYXQgY291bGQgYmUgZGlz
cGxheWVkCisJICAgICBvbiBpdCwgaS5lLiBpbnRvIHRoZSBzYW1lIHJlY3RhbmdsZXMgdGhh
dCBtYXRyaWNlcyBvbgorCSAgICAgdGhlIGZyYW1lIGFyZSBkaXZpZGVkIGludG8uICAqLwor
CisJICBkcHlpbmZvID0gRlJBTUVfRElTUExBWV9JTkZPIChmMSk7CisJICBTY3JlZW5Ub0Ns
aWVudCAoRlJBTUVfVzMyX1dJTkRPVyAoZjEpLCAmcHQpOworCSAgcmVtZW1iZXJfbW91c2Vf
Z2x5cGggKGYxLCBwdC54LCBwdC55LCAmZHB5aW5mby0+bGFzdF9tb3VzZV9nbHlwaCk7CisJ
ICBkcHlpbmZvLT5sYXN0X21vdXNlX2dseXBoX2ZyYW1lID0gZjE7CisKKwkgICpiYXJfd2lu
ZG93ID0gUW5pbDsKKwkgICpwYXJ0ID0gc2Nyb2xsX2Jhcl9hYm92ZV9oYW5kbGU7CisJICAq
ZnAgPSBmMTsKKwkgIFhTRVRJTlQgKCp4LCBwdC54KTsKKwkgIFhTRVRJTlQgKCp5LCBwdC55
KTsKKwkgICp0aW1lID0gZHB5aW5mby0+bGFzdF9tb3VzZV9tb3ZlbWVudF90aW1lOworCX0K
ICAgICB9CiAKICAgdW5ibG9ja19pbnB1dCAoKTsKQEAgLTQ2NjcsNiArNDY3MywzNyBAQCBz
dGF0aWMgc2hvcnQgdGVtcF9idWZmZXJbMTAwXTsKIC8qIFRlbXBvcmFyaWx5IHN0b3JlIGxl
YWQgYnl0ZSBvZiBEQkNTIGlucHV0IHNlcXVlbmNlcy4gICovCiBzdGF0aWMgY2hhciBkYmNz
X2xlYWQgPSAwOwogCisvKioKKyAgbW91c2Vfb3Jfd2Rlc2NfZnJhbWU6IFdoZW4gbm90IGRy
b3BwaW5nIGFuZCB0aGUgbW91c2Ugd2FzIGdyYWJiZWQKKyAgZm9yIERQWUlORk8sIHJldHVy
biB0aGUgZnJhbWUgd2hlcmUgdGhlIG1vdXNlIHdhcyBzZWVuIGxhc3QuICBJZgorICB0aGVy
ZSdzIG5vIHN1Y2ggZnJhbWUsIHJldHVybiB0aGUgZnJhbWUgYWNjb3JkaW5nIHRvIFdERVND
LiAgV2hlbgorICBkcm9wcGluZywgcmV0dXJuIHRoZSBmcmFtZSBhY2NvcmRpbmcgdG8gV0RF
U0MuICBJZiB0aGVyZSdzIG5vIHN1Y2gKKyAgZnJhbWUgYW5kIHRoZSBtb3VzZSB3YXMgZ3Jh
YmJlZCBmb3IgRFBZSU5GTywgcmV0dXJuIHRoZSBmcmFtZSB3aGVyZQorICB0aGUgbW91c2Ug
d2FzIHNlZW4gbGFzdC4gIEluIGVpdGhlciBjYXNlLCBuZXZlciByZXR1cm4gYSB0b29sdGlw
CisgIGZyYW1lLiAgKi8KK3N0YXRpYyBzdHJ1Y3QgZnJhbWUgKgorbW91c2Vfb3Jfd2Rlc2Nf
ZnJhbWUgKHN0cnVjdCB3MzJfZGlzcGxheV9pbmZvICpkcHlpbmZvLCBIV05EIHdkZXNjKQor
eworICBzdHJ1Y3QgZnJhbWUgKmxtX2YgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8p
CisJCQk/IGRweWluZm8tPmxhc3RfbW91c2VfZnJhbWUKKwkJCTogTlVMTCk7CisKKyAgaWYg
KGxtX2YgJiYgIUVRICh0cmFja19tb3VzZSwgUWRyb3BwaW5nKSkKKyAgICByZXR1cm4gbG1f
ZjsKKyAgZWxzZQorICAgIHsKKyAgICAgIHN0cnVjdCBmcmFtZSAqd19mID0gdzMyX3dpbmRv
d190b19mcmFtZSAoZHB5aW5mbywgd2Rlc2MpOworCisgICAgICAvKiBEbyBub3QgcmV0dXJu
IGEgdG9vbHRpcCBmcmFtZS4gICovCisgICAgICBpZiAoIXdfZiB8fCBGUkFNRV9UT09MVElQ
X1AgKHdfZikpCisJcmV0dXJuIEVRICh0cmFja19tb3VzZSwgUWRyb3BwaW5nKSA/IGxtX2Yg
OiBOVUxMOworICAgICAgZWxzZQorCS8qIFdoZW4gZHJvcHBpbmcgaXQgd291bGQgYmUgcHJv
YmFibHkgbmljZSB0byByYWlzZSB3X2YKKwkgICBoZXJlLiAgKi8KKwlyZXR1cm4gd19mOwor
ICAgIH0KK30KKwogLyogUmVhZCBldmVudHMgY29taW5nIGZyb20gdGhlIFczMiBzaGVsbC4K
ICAgIFRoaXMgcm91dGluZSBpcyBjYWxsZWQgYnkgdGhlIFNJR0lPIGhhbmRsZXIuCiAgICBX
ZSByZXR1cm4gYXMgc29vbiBhcyB0aGVyZSBhcmUgbm8gbW9yZSBldmVudHMgdG8gYmUgcmVh
ZC4KQEAgLTQ5NDAsMTUgKzQ5NzcsMTMgQEAgdzMyX3JlYWRfc29ja2V0IChzdHJ1Y3QgdGVy
bWluYWwgKnRlcm1pbmFsLAogICAgICAgICAgIHByZXZpb3VzX2hlbHBfZWNob19zdHJpbmcg
PSBoZWxwX2VjaG9fc3RyaW5nOwogCSAgaGVscF9lY2hvX3N0cmluZyA9IFFuaWw7CiAKLQkg
IGYgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFzdF9tb3Vz
ZV9mcmFtZQotCSAgICAgICA6IHczMl93aW5kb3dfdG9fZnJhbWUgKGRweWluZm8sIG1zZy5t
c2cuaHduZCkpOwotCiAJICBpZiAoaGxpbmZvLT5tb3VzZV9mYWNlX2hpZGRlbikKIAkgICAg
ewogCSAgICAgIGhsaW5mby0+bW91c2VfZmFjZV9oaWRkZW4gPSBmYWxzZTsKIAkgICAgICBj
bGVhcl9tb3VzZV9mYWNlIChobGluZm8pOwogCSAgICB9CiAKKwkgIGYgPSBtb3VzZV9vcl93
ZGVzY19mcmFtZSAoZHB5aW5mbywgbXNnLm1zZy5od25kKTsKIAkgIGlmIChmKQogCSAgICB7
CiAJICAgICAgLyogTWF5YmUgZ2VuZXJhdGUgU0VMRUNUX1dJTkRPV19FVkVOVHMgZm9yCkBA
IC01MDIwLDkgKzUwNTUsNyBAQCB3MzJfcmVhZF9zb2NrZXQgKHN0cnVjdCB0ZXJtaW5hbCAq
dGVybWluYWwsCiAJICAgIGludCBidXR0b24gPSAwOwogCSAgICBpbnQgdXAgPSAwOwogCi0J
ICAgIGYgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFzdF9t
b3VzZV9mcmFtZQotCQkgOiB3MzJfd2luZG93X3RvX2ZyYW1lIChkcHlpbmZvLCBtc2cubXNn
Lmh3bmQpKTsKLQorCSAgICBmID0gbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKGRweWluZm8sIG1z
Zy5tc2cuaHduZCk7CiAJICAgIGlmIChmKQogCSAgICAgIHsKICAgICAgICAgICAgICAgICB3
MzJfY29uc3RydWN0X21vdXNlX2NsaWNrICgmaW5ldiwgJm1zZywgZik7CkBAIC01MDgxLDkg
KzUxMTQsNyBAQCB3MzJfcmVhZF9zb2NrZXQgKHN0cnVjdCB0ZXJtaW5hbCAqdGVybWluYWws
CiAJY2FzZSBXTV9NT1VTRVdIRUVMOgogICAgICAgICBjYXNlIFdNX01PVVNFSFdIRUVMOgog
CSAgewotCSAgICBmID0gKGd1aV9tb3VzZV9ncmFiYmVkIChkcHlpbmZvKSA/IGRweWluZm8t
Pmxhc3RfbW91c2VfZnJhbWUKLQkJIDogdzMyX3dpbmRvd190b19mcmFtZSAoZHB5aW5mbywg
bXNnLm1zZy5od25kKSk7Ci0KKwkgICAgZiA9IG1vdXNlX29yX3dkZXNjX2ZyYW1lIChkcHlp
bmZvLCBtc2cubXNnLmh3bmQpOwogCSAgICBpZiAoZikKIAkgICAgICB7CiAJCWlmICghZHB5
aW5mby0+dzMyX2ZvY3VzX2ZyYW1lCkBAIC01NDM5LDYgKzU0NzAsNyBAQCB3MzJfcmVhZF9z
b2NrZXQgKHN0cnVjdCB0ZXJtaW5hbCAqdGVybWluYWwsCiAJICAgICAgaWYgKGFueV9oZWxw
X2V2ZW50X3ApCiAJCWRvX2hlbHAgPSAtMTsKIAkgICAgfQorCiAJICBicmVhazsKIAogCWNh
c2UgV01fU0VURk9DVVM6CmRpZmYgLS1naXQgYS9zcmMveGRpc3AuYyBiL3NyYy94ZGlzcC5j
CmluZGV4IDFiYjVmNWUwZjIuLjczMzhkMmI3ZDQgMTAwNjQ0Ci0tLSBhL3NyYy94ZGlzcC5j
CisrKyBiL3NyYy94ZGlzcC5jCkBAIC0xNzI4OSw3ICsxNzI4OSw3IEBAIHJlZGlzcGxheV93
aW5kb3cgKExpc3BfT2JqZWN0IHdpbmRvdywgYm9vbCBqdXN0X3RoaXNfb25lX3ApCiAJIHRo
ZSBtb3VzZSwgcmVzdWx0aW5nIGluIGFuIHVud2FudGVkIG1vdXNlLW1vdmVtZW50IHJhdGhl
cgogCSB0aGFuIGEgc2ltcGxlIG1vdXNlLWNsaWNrLiAgKi8KICAgICAgIGlmICghdy0+c3Rh
cnRfYXRfbGluZV9iZWcKLQkgICYmIE5JTFAgKGRvX21vdXNlX3RyYWNraW5nKQorCSAgJiYg
TklMUCAodHJhY2tfbW91c2UpCiAgICAgICAJICAmJiBDSEFSUE9TIChzdGFydHApID4gQkVH
VgogCSAgJiYgQ0hBUlBPUyAoc3RhcnRwKSA+IEJFRyArIGJlZ191bmNoYW5nZWQKIAkgICYm
IENIQVJQT1MgKHN0YXJ0cCkgPD0gWiAtIGVuZF91bmNoYW5nZWQKQEAgLTMwMjc5LDcgKzMw
Mjc5LDcgQEAgc2hvd19tb3VzZV9mYWNlIChNb3VzZV9ITEluZm8gKmhsaW5mbywgZW51bSBk
cmF3X2dseXBoc19mYWNlIGRyYXcpCiAKICNpZmRlZiBIQVZFX1dJTkRPV19TWVNURU0KICAg
LyogQ2hhbmdlIHRoZSBtb3VzZSBjdXJzb3IuICAqLwotICBpZiAoRlJBTUVfV0lORE9XX1Ag
KGYpICYmIE5JTFAgKGRvX21vdXNlX3RyYWNraW5nKSkKKyAgaWYgKEZSQU1FX1dJTkRPV19Q
IChmKSAmJiBOSUxQICh0cmFja19tb3VzZSkpCiAgICAgewogI2lmbmRlZiBIQVZFX0VYVF9U
T09MX0JBUgogICAgICAgaWYgKGRyYXcgPT0gRFJBV19OT1JNQUxfVEVYVApAQCAtMzEyMjYs
NyArMzEyMjYsNyBAQCBkZWZpbmVfZnJhbWVfY3Vyc29yMSAoc3RydWN0IGZyYW1lICpmLCBF
bWFjc19DdXJzb3IgY3Vyc29yLCBMaXNwX09iamVjdCBwb2ludGVyKQogICAgIHJldHVybjsK
IAogICAvKiBEbyBub3QgY2hhbmdlIGN1cnNvciBzaGFwZSB3aGlsZSBkcmFnZ2luZyBtb3Vz
ZS4gICovCi0gIGlmIChFUSAoZG9fbW91c2VfdHJhY2tpbmcsIFFkcmFnZ2luZykpCisgIGlm
IChFUSAodHJhY2tfbW91c2UsIFFkcmFnZ2luZykgfHwgRVEgKHRyYWNrX21vdXNlLCBRZHJv
cHBpbmcpKQogICAgIHJldHVybjsKIAogICBpZiAoIU5JTFAgKHBvaW50ZXIpKQpAQCAtMzI5
NTYsNiArMzI5NTYsNyBAQCBiZSBsZXQtYm91bmQgYXJvdW5kIGNvZGUgdGhhdCBuZWVkcyB0
byBkaXNhYmxlIG1lc3NhZ2VzIHRlbXBvcmFyaWx5LiAqLyk7CiAgIC8qIGFsc28gUXRleHQg
Ki8KIAogICBERUZTWU0gKFFkcmFnZ2luZywgImRyYWdnaW5nIik7CisgIERFRlNZTSAoUWRy
b3BwaW5nLCAiZHJvcHBpbmciKTsKIAogICBERUZTWU0gKFFpbmhpYml0X2ZyZWVfcmVhbGl6
ZWRfZmFjZXMsICJpbmhpYml0LWZyZWUtcmVhbGl6ZWQtZmFjZXMiKTsKIApkaWZmIC0tZ2l0
IGEvc3JjL3h0ZXJtLmMgYi9zcmMveHRlcm0uYwppbmRleCBjOTZhYTc0YTdhLi45N2QxNGY3
ZDQ1IDEwMDY0NAotLS0gYS9zcmMveHRlcm0uYworKysgYi9zcmMveHRlcm0uYwpAQCAtNTE2
NywyMCArNTE2NywxNSBAQCBYVG1vdXNlX3Bvc2l0aW9uIChzdHJ1Y3QgZnJhbWUgKipmcCwg
aW50IGluc2lzdCwgTGlzcF9PYmplY3QgKmJhcl93aW5kb3csCiAgICAgICAvKiBGaWd1cmUg
b3V0IHdoaWNoIHJvb3Qgd2luZG93IHdlJ3JlIG9uLiAgKi8KICAgICAgIFhRdWVyeVBvaW50
ZXIgKEZSQU1FX1hfRElTUExBWSAoKmZwKSwKIAkJICAgICBEZWZhdWx0Um9vdFdpbmRvdyAo
RlJBTUVfWF9ESVNQTEFZICgqZnApKSwKLQogCQkgICAgIC8qIFRoZSByb290IHdpbmRvdyB3
aGljaCBjb250YWlucyB0aGUgcG9pbnRlci4gICovCiAJCSAgICAgJnJvb3QsCi0KIAkJICAg
ICAvKiBUcmFzaCB3aGljaCB3ZSBjYW4ndCB0cnVzdCBpZiB0aGUgcG9pbnRlciBpcyBvbgog
CQkJYSBkaWZmZXJlbnQgc2NyZWVuLiAgKi8KIAkJICAgICAmZHVtbXlfd2luZG93LAotCiAJ
CSAgICAgLyogVGhlIHBvc2l0aW9uIG9uIHRoYXQgcm9vdCB3aW5kb3cuICAqLwogCQkgICAg
ICZyb290X3gsICZyb290X3ksCi0KIAkJICAgICAvKiBNb3JlIHRyYXNoIHdlIGNhbid0IHRy
dXN0LiAgKi8KIAkJICAgICAmZHVtbXksICZkdW1teSwKLQogCQkgICAgIC8qIE1vZGlmaWVy
IGtleXMgYW5kIHBvaW50ZXIgYnV0dG9ucywgYWJvdXQgd2hpY2gKIAkJCXdlIGRvbid0IGNh
cmUuICAqLwogCQkgICAgICh1bnNpZ25lZCBpbnQgKikgJmR1bW15KTsKQEAgLTUyMDMsMjEg
KzUxOTgsMTcgQEAgWFRtb3VzZV9wb3NpdGlvbiAoc3RydWN0IGZyYW1lICoqZnAsIGludCBp
bnNpc3QsIExpc3BfT2JqZWN0ICpiYXJfd2luZG93LAogCiAJeF9jYXRjaF9lcnJvcnMgKEZS
QU1FX1hfRElTUExBWSAoKmZwKSk7CiAKLQlpZiAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWlu
Zm8pKQorCWlmIChndWlfbW91c2VfZ3JhYmJlZCAoZHB5aW5mbykgJiYgIUVRICh0cmFja19t
b3VzZSwgUWRyb3BwaW5nKSkKIAkgIHsKIAkgICAgLyogSWYgbW91c2Ugd2FzIGdyYWJiZWQg
b24gYSBmcmFtZSwgZ2l2ZSBjb29yZHMgZm9yIHRoYXQgZnJhbWUKIAkgICAgICAgZXZlbiBp
ZiB0aGUgbW91c2UgaXMgbm93IG91dHNpZGUgaXQuICAqLwogCSAgICBYVHJhbnNsYXRlQ29v
cmRpbmF0ZXMgKEZSQU1FX1hfRElTUExBWSAoKmZwKSwKLQogCQkJCSAgIC8qIEZyb20td2lu
ZG93LiAgKi8KIAkJCQkgICByb290LAotCiAJCQkJICAgLyogVG8td2luZG93LiAgKi8KIAkJ
CQkgICBGUkFNRV9YX1dJTkRPVyAoZHB5aW5mby0+bGFzdF9tb3VzZV9mcmFtZSksCi0KIAkJ
CQkgICAvKiBGcm9tLXBvc2l0aW9uLCB0by1wb3NpdGlvbi4gICovCiAJCQkJICAgcm9vdF94
LCByb290X3ksICZ3aW5feCwgJndpbl95LAotCiAJCQkJICAgLyogQ2hpbGQgb2Ygd2luLiAg
Ki8KIAkJCQkgICAmY2hpbGQpOwogCSAgICBmMSA9IGRweWluZm8tPmxhc3RfbW91c2VfZnJh
bWU7CkBAIC01MjI3LDE2ICs1MjE4LDEyIEBAIFhUbW91c2VfcG9zaXRpb24gKHN0cnVjdCBm
cmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09iamVjdCAqYmFyX3dpbmRvdywKIAkgICAg
d2hpbGUgKHRydWUpCiAJICAgICAgewogCQlYVHJhbnNsYXRlQ29vcmRpbmF0ZXMgKEZSQU1F
X1hfRElTUExBWSAoKmZwKSwKLQogCQkJCSAgICAgICAvKiBGcm9tLXdpbmRvdywgdG8td2lu
ZG93LiAgKi8KIAkJCQkgICAgICAgcm9vdCwgd2luLAotCiAJCQkJICAgICAgIC8qIEZyb20t
cG9zaXRpb24sIHRvLXBvc2l0aW9uLiAgKi8KIAkJCQkgICAgICAgcm9vdF94LCByb290X3ks
ICZ3aW5feCwgJndpbl95LAotCiAJCQkJICAgICAgIC8qIENoaWxkIG9mIHdpbi4gICovCiAJ
CQkJICAgICAgICZjaGlsZCk7Ci0KIAkJaWYgKGNoaWxkID09IE5vbmUgfHwgY2hpbGQgPT0g
d2luKQogCQkgIHsKICNpZmRlZiBVU0VfR1RLCkBAIC01Mjk5LDEzICs1Mjg2LDM1IEBAIFhU
bW91c2VfcG9zaXRpb24gKHN0cnVjdCBmcmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09i
amVjdCAqYmFyX3dpbmRvdywKICNlbmRpZiAvKiBVU0VfWF9UT09MS0lUICovCiAJICB9CiAK
KwlpZiAoKCFmMSB8fCBGUkFNRV9UT09MVElQX1AgKGYxKSkKKwkgICAgJiYgRVEgKHRyYWNr
X21vdXNlLCBRZHJvcHBpbmcpCisJICAgICYmIGd1aV9tb3VzZV9ncmFiYmVkIChkcHlpbmZv
KSkKKwkgIHsKKwkgICAgLyogV2hlbiBkcm9wcGluZyB0aGVuIGlmIHdlIGRpZG4ndCBnZXQg
YSBmcmFtZSBvciBvbmx5IGEKKwkgICAgICAgdG9vbHRpcCBmcmFtZSBhbmQgdGhlIG1vdXNl
IHdhcyBncmFiYmVkIG9uIGEgZnJhbWUsCisJICAgICAgIGdpdmUgY29vcmRzIGZvciB0aGF0
IGZyYW1lIGV2ZW4gaWYgdGhlIG1vdXNlIGlzIG5vdworCSAgICAgICBvdXRzaWRlIGl0LiAg
Ki8KKwkgICAgWFRyYW5zbGF0ZUNvb3JkaW5hdGVzIChGUkFNRV9YX0RJU1BMQVkgKCpmcCks
CisJCQkJICAgLyogRnJvbS13aW5kb3cuICAqLworCQkJCSAgIHJvb3QsCisJCQkJICAgLyog
VG8td2luZG93LiAgKi8KKwkJCQkgICBGUkFNRV9YX1dJTkRPVyAoZHB5aW5mby0+bGFzdF9t
b3VzZV9mcmFtZSksCisJCQkJICAgLyogRnJvbS1wb3NpdGlvbiwgdG8tcG9zaXRpb24uICAq
LworCQkJCSAgIHJvb3RfeCwgcm9vdF95LCAmd2luX3gsICZ3aW5feSwKKwkJCQkgICAvKiBD
aGlsZCBvZiB3aW4uICAqLworCQkJCSAgICZjaGlsZCk7CisJICAgIGYxID0gZHB5aW5mby0+
bGFzdF9tb3VzZV9mcmFtZTsKKwkgIH0KKwllbHNlIGlmIChmMSAmJiBGUkFNRV9UT09MVElQ
X1AgKGYxKSkKKwkgIGYxID0gTlVMTDsKKwogCWlmICh4X2hhZF9lcnJvcnNfcCAoRlJBTUVf
WF9ESVNQTEFZICgqZnApKSkKLQkgIGYxID0gMDsKKwkgIGYxID0gTlVMTDsKIAogCXhfdW5j
YXRjaF9lcnJvcnNfYWZ0ZXJfY2hlY2sgKCk7CiAKIAkvKiBJZiBub3QsIGlzIGl0IG9uZSBv
ZiBvdXIgc2Nyb2xsIGJhcnM/ICAqLwotCWlmICghIGYxKQorCWlmICghZjEpCiAJICB7CiAJ
ICAgIHN0cnVjdCBzY3JvbGxfYmFyICpiYXI7CiAKQEAgLTUzMTksNyArNTMyOCw3IEBAIFhU
bW91c2VfcG9zaXRpb24gKHN0cnVjdCBmcmFtZSAqKmZwLCBpbnQgaW5zaXN0LCBMaXNwX09i
amVjdCAqYmFyX3dpbmRvdywKIAkgICAgICB9CiAJICB9CiAKLQlpZiAoZjEgPT0gMCAmJiBp
bnNpc3QgPiAwKQorCWlmICghZjEgJiYgaW5zaXN0ID4gMCkKIAkgIGYxID0gU0VMRUNURURf
RlJBTUUgKCk7CiAKIAlpZiAoZjEpCkBAIC03Nzg4LDYgKzc3OTcsMzcgQEAgZmx1c2hfZGly
dHlfYmFja19idWZmZXJzICh2b2lkKQogICB1bmJsb2NrX2lucHV0ICgpOwogfQogCisvKioK
KyAgbW91c2Vfb3Jfd2Rlc2NfZnJhbWU6IFdoZW4gbm90IGRyb3BwaW5nIGFuZCB0aGUgbW91
c2Ugd2FzIGdyYWJiZWQKKyAgZm9yIERQWUlORk8sIHJldHVybiB0aGUgZnJhbWUgd2hlcmUg
dGhlIG1vdXNlIHdhcyBzZWVuIGxhc3QuICBJZgorICB0aGVyZSdzIG5vIHN1Y2ggZnJhbWUs
IHJldHVybiB0aGUgZnJhbWUgYWNjb3JkaW5nIHRvIFdERVNDLiAgV2hlbgorICBkcm9wcGlu
ZywgcmV0dXJuIHRoZSBmcmFtZSBhY2NvcmRpbmcgdG8gV0RFU0MuICBJZiB0aGVyZSdzIG5v
IHN1Y2gKKyAgZnJhbWUgYW5kIHRoZSBtb3VzZSB3YXMgZ3JhYmJlZCBmb3IgRFBZSU5GTywg
cmV0dXJuIHRoZSBmcmFtZSB3aGVyZQorICB0aGUgbW91c2Ugd2FzIHNlZW4gbGFzdC4gIElu
IGVpdGhlciBjYXNlLCBuZXZlciByZXR1cm4gYSB0b29sdGlwCisgIGZyYW1lLiAgKi8KK3N0
YXRpYyBzdHJ1Y3QgZnJhbWUgKgorbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKHN0cnVjdCB4X2Rp
c3BsYXlfaW5mbyAqZHB5aW5mbywgaW50IHdkZXNjKQoreworICBzdHJ1Y3QgZnJhbWUgKmxt
X2YgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pCisJCQk/IGRweWluZm8tPmxhc3Rf
bW91c2VfZnJhbWUKKwkJCTogTlVMTCk7CisKKyAgaWYgKGxtX2YgJiYgIUVRICh0cmFja19t
b3VzZSwgUWRyb3BwaW5nKSkKKyAgICByZXR1cm4gbG1fZjsKKyAgZWxzZQorICAgIHsKKyAg
ICAgIHN0cnVjdCBmcmFtZSAqd19mID0geF93aW5kb3dfdG9fZnJhbWUgKGRweWluZm8sIHdk
ZXNjKTsKKworICAgICAgLyogRG8gbm90IHJldHVybiBhIHRvb2x0aXAgZnJhbWUuICAqLwor
ICAgICAgaWYgKCF3X2YgfHwgRlJBTUVfVE9PTFRJUF9QICh3X2YpKQorCXJldHVybiBFUSAo
dHJhY2tfbW91c2UsIFFkcm9wcGluZykgPyBsbV9mIDogTlVMTDsKKyAgICAgIGVsc2UKKwkv
KiBXaGVuIGRyb3BwaW5nIGl0IHdvdWxkIGJlIHByb2JhYmx5IG5pY2UgdG8gcmFpc2Ugd19m
CisJICAgaGVyZS4gICovCisJcmV0dXJuIHdfZjsKKyAgICB9Cit9CisKIC8qIEhhbmRsZXMg
dGhlIFhFdmVudCBFVkVOVCBvbiBkaXNwbGF5IERQWUlORk8uCiAKICAgICpGSU5JU0ggaXMg
WF9FVkVOVF9HT1RPX09VVCBpZiBjYWxsZXIgc2hvdWxkIHN0b3AgcmVhZGluZyBldmVudHMu
CkBAIC04NzIwLDE1ICs4NzYwLDE0IEBAIGhhbmRsZV9vbmVfeGV2ZW50IChzdHJ1Y3QgeF9k
aXNwbGF5X2luZm8gKmRweWluZm8sCiAgICAgICAgIHByZXZpb3VzX2hlbHBfZWNob19zdHJp
bmcgPSBoZWxwX2VjaG9fc3RyaW5nOwogICAgICAgICBoZWxwX2VjaG9fc3RyaW5nID0gUW5p
bDsKIAotCWYgPSAoZ3VpX21vdXNlX2dyYWJiZWQgKGRweWluZm8pID8gZHB5aW5mby0+bGFz
dF9tb3VzZV9mcmFtZQotCSAgICAgOiB4X3dpbmRvd190b19mcmFtZSAoZHB5aW5mbywgZXZl
bnQtPnhtb3Rpb24ud2luZG93KSk7Ci0KLSAgICAgICAgaWYgKGhsaW5mby0+bW91c2VfZmFj
ZV9oaWRkZW4pCisJaWYgKGhsaW5mby0+bW91c2VfZmFjZV9oaWRkZW4pCiAgICAgICAgICAg
ewogICAgICAgICAgICAgaGxpbmZvLT5tb3VzZV9mYWNlX2hpZGRlbiA9IGZhbHNlOwogICAg
ICAgICAgICAgY2xlYXJfbW91c2VfZmFjZSAoaGxpbmZvKTsKICAgICAgICAgICB9CiAKKwlm
ID0gbW91c2Vfb3Jfd2Rlc2NfZnJhbWUgKGRweWluZm8sIGV2ZW50LT54bW90aW9uLndpbmRv
dyk7CisKICNpZmRlZiBVU0VfR1RLCiAgICAgICAgIGlmIChmICYmIHhnX2V2ZW50X2lzX2Zv
cl9zY3JvbGxiYXIgKGYsIGV2ZW50KSkKICAgICAgICAgICBmID0gMDsKQEAgLTg5NzAsMzMg
KzkwMDksMjcgQEAgaGFuZGxlX29uZV94ZXZlbnQgKHN0cnVjdCB4X2Rpc3BsYXlfaW5mbyAq
ZHB5aW5mbywKIAlkcHlpbmZvLT5sYXN0X21vdXNlX2dseXBoX2ZyYW1lID0gTlVMTDsKIAl4
X2Rpc3BsYXlfc2V0X2xhc3RfdXNlcl90aW1lIChkcHlpbmZvLCBldmVudC0+eGJ1dHRvbi50
aW1lKTsKIAotCWlmIChndWlfbW91c2VfZ3JhYmJlZCAoZHB5aW5mbykpCi0JICBmID0gZHB5
aW5mby0+bGFzdF9tb3VzZV9mcmFtZTsKLQllbHNlCisJZiA9IG1vdXNlX29yX3dkZXNjX2Zy
YW1lIChkcHlpbmZvLCBldmVudC0+eG1vdGlvbi53aW5kb3cpOworCWlmIChmICYmIGV2ZW50
LT54YnV0dG9uLnR5cGUgPT0gQnV0dG9uUHJlc3MKKwkgICAgJiYgIXBvcHVwX2FjdGl2YXRl
ZCAoKQorCSAgICAmJiAheF93aW5kb3dfdG9fc2Nyb2xsX2JhciAoZXZlbnQtPnhidXR0b24u
ZGlzcGxheSwKKwkJCQkJZXZlbnQtPnhidXR0b24ud2luZG93LCAyKQorCSAgICAmJiAhRlJB
TUVfTk9fQUNDRVBUX0ZPQ1VTIChmKSkKIAkgIHsKLQkgICAgZiA9IHhfd2luZG93X3RvX2Zy
YW1lIChkcHlpbmZvLCBldmVudC0+eGJ1dHRvbi53aW5kb3cpOworCSAgICAvKiBXaGVuIGNs
aWNraW5nIGludG8gYSBjaGlsZCBmcmFtZSBvciB3aGVuIGNsaWNraW5nCisJICAgICAgIGlu
dG8gYSBwYXJlbnQgZnJhbWUgd2l0aCB0aGUgY2hpbGQgZnJhbWUgc2VsZWN0ZWQgYW5kCisJ
ICAgICAgIGBuby1hY2NlcHQtZm9jdXMnIGlzIG5vdCBzZXQsIHNlbGVjdCB0aGUgY2xpY2tl
ZAorCSAgICAgICBmcmFtZS4gICovCisJICAgIHN0cnVjdCBmcmFtZSAqaGYgPSBkcHlpbmZv
LT5oaWdobGlnaHRfZnJhbWU7CiAKLQkgICAgaWYgKGYgJiYgZXZlbnQtPnhidXR0b24udHlw
ZSA9PSBCdXR0b25QcmVzcwotCQkmJiAhcG9wdXBfYWN0aXZhdGVkICgpCi0JCSYmICF4X3dp
bmRvd190b19zY3JvbGxfYmFyIChldmVudC0+eGJ1dHRvbi5kaXNwbGF5LAotCQkJCQkgICAg
ZXZlbnQtPnhidXR0b24ud2luZG93LCAyKQotCQkmJiAhRlJBTUVfTk9fQUNDRVBUX0ZPQ1VT
IChmKSkKKwkgICAgaWYgKEZSQU1FX1BBUkVOVF9GUkFNRSAoZikgfHwgKGhmICYmIGZyYW1l
X2FuY2VzdG9yX3AgKGYsIGhmKSkpCiAJICAgICAgewotCQkvKiBXaGVuIGNsaWNraW5nIGlu
dG8gYSBjaGlsZCBmcmFtZSBvciB3aGVuIGNsaWNraW5nCi0JCSAgIGludG8gYSBwYXJlbnQg
ZnJhbWUgd2l0aCB0aGUgY2hpbGQgZnJhbWUgc2VsZWN0ZWQgYW5kCi0JCSAgIGBuby1hY2Nl
cHQtZm9jdXMnIGlzIG5vdCBzZXQsIHNlbGVjdCB0aGUgY2xpY2tlZAotCQkgICBmcmFtZS4g
ICovCi0JCXN0cnVjdCBmcmFtZSAqaGYgPSBkcHlpbmZvLT5oaWdobGlnaHRfZnJhbWU7Ci0K
LQkJaWYgKEZSQU1FX1BBUkVOVF9GUkFNRSAoZikgfHwgKGhmICYmIGZyYW1lX2FuY2VzdG9y
X3AgKGYsIGhmKSkpCi0JCSAgewotCQkgICAgYmxvY2tfaW5wdXQgKCk7Ci0JCSAgICBYU2V0
SW5wdXRGb2N1cyAoRlJBTUVfWF9ESVNQTEFZIChmKSwgRlJBTUVfT1VURVJfV0lORE9XIChm
KSwKLQkJCQkgICAgUmV2ZXJ0VG9QYXJlbnQsIEN1cnJlbnRUaW1lKTsKLQkJICAgIGlmIChG
UkFNRV9QQVJFTlRfRlJBTUUgKGYpKQotCQkgICAgICBYUmFpc2VXaW5kb3cgKEZSQU1FX1hf
RElTUExBWSAoZiksIEZSQU1FX09VVEVSX1dJTkRPVyAoZikpOwotCQkgICAgdW5ibG9ja19p
bnB1dCAoKTsKLQkJICB9CisJCWJsb2NrX2lucHV0ICgpOworCQlYU2V0SW5wdXRGb2N1cyAo
RlJBTUVfWF9ESVNQTEFZIChmKSwgRlJBTUVfT1VURVJfV0lORE9XIChmKSwKKwkJCQlSZXZl
cnRUb1BhcmVudCwgQ3VycmVudFRpbWUpOworCQlpZiAoRlJBTUVfUEFSRU5UX0ZSQU1FIChm
KSkKKwkJICBYUmFpc2VXaW5kb3cgKEZSQU1FX1hfRElTUExBWSAoZiksIEZSQU1FX09VVEVS
X1dJTkRPVyAoZikpOworCQl1bmJsb2NrX2lucHV0ICgpOwogCSAgICAgIH0KIAkgIH0KIAoK

--------------B7922B75546CE207C9316044--




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; 21 Oct 2017 18:05:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 21 14:05:37 2017
Received: from localhost ([127.0.0.1]:54529 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e5y9R-0005WH-D5
	for submit <at> debbugs.gnu.org; Sat, 21 Oct 2017 14:05:37 -0400
Received: from eggs.gnu.org ([208.118.235.92]:54100)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rms@HIDDEN>) id 1e5y9O-0005W3-B0
 for 28620 <at> debbugs.gnu.org; Sat, 21 Oct 2017 14:05:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rms@HIDDEN>) id 1e5y9I-0001pY-9P
 for 28620 <at> debbugs.gnu.org; Sat, 21 Oct 2017 14:05: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.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57132)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rms@HIDDEN>)
 id 1e5y8q-0001Le-Nj; Sat, 21 Oct 2017 14:05:00 -0400
Received: from rms by fencepost.gnu.org with local (Exim 4.82)
 (envelope-from <rms@HIDDEN>)
 id 1e5y8q-00061c-3W; Sat, 21 Oct 2017 14:05:00 -0400
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@HIDDEN>
To: martin rudalics <rudalics@HIDDEN>
In-reply-to: <59EAFFAF.70303@HIDDEN> (message from martin rudalics on Sat, 21
 Oct 2017 10:05:03 +0200)
Subject: Re: bug#28620: Interact directly on Emacs bug#28620: mouse drag event
 records wrong release window
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@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>
 <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
 <59E9AC02.8090202@HIDDEN>
 <CA+OMD9g22KgB4qp0-HkYjLgjgN7q70GPiJE5HhUVzjaoM7Vk=g@HIDDEN>
 <59EAFFAF.70303@HIDDEN>
Message-Id: <E1e5y8q-00061c-3W@HIDDEN>
Date: Sat, 21 Oct 2017 14:05:00 -0400
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: alan@HIDDEN, rswgnu@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: rms@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 (-----)

I am trying to imagine what a mouse drag event would look like.
Since mice don't wear clothing, or makeup, what would distinguish
it from any other mouse event?

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.





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; 21 Oct 2017 08:05:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 21 04:05:28 2017
Received: from localhost ([127.0.0.1]:53023 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e5ome-00057j-Fm
	for submit <at> debbugs.gnu.org; Sat, 21 Oct 2017 04:05:28 -0400
Received: from mout.gmx.net ([212.227.17.21]:62561)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e5omc-00057M-Og
 for 28620 <at> debbugs.gnu.org; Sat, 21 Oct 2017 04:05:27 -0400
Received: from [192.168.1.100] ([46.125.249.29]) by mail.gmx.com (mrgmx102
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lm6IP-1dWkwW0G9J-00ZhQN; Sat, 21
 Oct 2017 10:05:09 +0200
Message-ID: <59EAFFAF.70303@HIDDEN>
Date: Sat, 21 Oct 2017 10:05:03 +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>
 <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>
 <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
 <59E9AC02.8090202@HIDDEN>
 <CA+OMD9g22KgB4qp0-HkYjLgjgN7q70GPiJE5HhUVzjaoM7Vk=g@HIDDEN>
In-Reply-To: <CA+OMD9g22KgB4qp0-HkYjLgjgN7q70GPiJE5HhUVzjaoM7Vk=g@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:qctLOmGQYyASSYabDTo7riKut8M7EVAedFFyS5m7LQtpBUB5nS5
 389fWL9x9UpiVupWQEMfcg9F9j8IOmzARboZ5rd9ooEt7SfX6F7n9ozmDeWEzw8+6qHiGV1
 17LY0dvwXv6rDJkwLX2sL76llEL44YsFefrGnTW+jUY2a7RTPpIvzC6JsQjOIQ+E/p0JS0Z
 g7OYf44jUmvdf5LEVgxxQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:yuPZpm9hdyM=:WPo7BG/NgFb1Hb8YLNX4Id
 hdPI655wNNGhuXERP/AgEh2qNqzqRyFwnrLJj5UeGCnLm+2xfo+ubGgDdkG9gRkte5PQ+N/wB
 s83P4iAFLXApaJtr7pitbuqhNdwZLkGH/TgvPrZ+LBn1gGNHGBeavQXATEbxGU40XxSBltRWb
 eyhF4Em7iEpiyEkQanQXWBtqL0FyhXEDxXL4Ln1zcZM+0suArVhQaInf9ensUwuV2Er3FNz+r
 L8Y7b9E7nx94U4T2XmYNGUZEBm4jsuMjQg4wDlzuzHiRUU/k1AXx+xlseDn166tehXkD04ba4
 qLct17oOw1j+7LOSN6j5sFsi5D8PKcLJrN3V5MLVVPAIufGNLXUrqSIVIGOFwvi/oHsElYHh8
 9MVVKVBRfjHI7YLQ8OTyVGj2+T3LeEI6E0htlgPo3hKgZ1cptqa1yV+WpBEgJxqs+A1MGO/vp
 czVtJhjBUqIRR+juvEFrkSoCInq9aPt/2oN82n3GTAER+7DJ4ilaidNNhbk1bi/XACSG/fV3f
 SnHoITxXRY2Ulk4bWAkfhPkMUg/AnbehdABKg7Eqe9o50AmmItofssnYjJH0Dv9Floj0ugVom
 K5DDNDUYM2+l0d6glXusOD4Lt4TEQumbssJz/HtHF4EVb+m/PbIhxxZ8w8a9PaWH/vkqawDCW
 wgPgrNoe1FKYdlgao5GClC2dCY2Riff9zux4DkJMkPLm5egPO61Cv/hxjQTspv7Ooj5w+g+m4
 57xuotHWuUyVWpPW8mF9ImCAz8uIVW+q2IVxyo95UzSHC9nBwZCC13AMJYyTvgCj3cZmzGWeZ
 gmyLxRSJmRcn7eMgxPSJz0oMmStRvALhVnqo6a0hlTmx+gH9lbZ8gg0uxRc20HmwHy6bLiR
X-Spam-Score: -3.5 (---)
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.5 (---)

 > =E2=80=8BYes, I see.  I am having similar issues when trying to replic=
ate the size
 > of a frame under the macOS window system.  I can't seem to get the new=

 > frame to match the old frame by using (frame-edges nil 'outer-edges) o=
r
 > (frame-edges nil 'native-edges).  In earlier versions of Emacs, I don'=
t
 > remember this being a problem but I can't recall when that was.  What =
is
 > the best way available to replicate the size of one frame to another g=
iven
 > the limitations that exist now?

There should be no "limitations".  As a rule,

(setq frame-resize-pixelwise t)
(make-frame (frame-parameters))

should give you an exact replica of the selected frame.  If you only
want to clone the size of the selected frame use

(setq frame-resize-pixelwise t)
(make-frame `((width . ,(frame-parameter nil 'width))
	      (height . ,(frame-parameter nil 'height))))

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; 20 Oct 2017 14:27:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 20 10:27:05 2017
Received: from localhost ([127.0.0.1]:52494 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e5YGO-0005XS-PI
	for submit <at> debbugs.gnu.org; Fri, 20 Oct 2017 10:27:04 -0400
Received: from eggs.gnu.org ([208.118.235.92]:58457)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rsw@HIDDEN>) id 1e5YGM-0005Wt-Bt
 for 28620 <at> debbugs.gnu.org; Fri, 20 Oct 2017 10:27:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <rsw@HIDDEN>) id 1e5YGD-00034Q-Ta
 for 28620 <at> debbugs.gnu.org; Fri, 20 Oct 2017 10:26:57 -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]:36215)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <rsw@HIDDEN>)
 id 1e5YGD-00034G-Pc
 for 28620 <at> debbugs.gnu.org; Fri, 20 Oct 2017 10:26:53 -0400
Received: from mail-qt0-f174.google.com ([209.85.216.174]:53016)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <rsw@HIDDEN>) id 1e5YGD-0002zP-GP
 for 28620 <at> debbugs.gnu.org; Fri, 20 Oct 2017 10:26:53 -0400
Received: by mail-qt0-f174.google.com with SMTP id 31so18631451qtz.9
 for <28620 <at> debbugs.gnu.org>; Fri, 20 Oct 2017 07:26:53 -0700 (PDT)
X-Gm-Message-State: AMCzsaWlP2dC6RQMF+lxspkVQyReJlr8zq1Cqst3EsVCUJ7PB9d3ouHD
 m3CdbUFX0rTLuLuz1vqJnLXvC3E6t1GM+4/Fnpk=
X-Google-Smtp-Source: ABhQp+TecqB6oiORgo3yQ0ZOzYfDGddyfQOd2DEzpZnRVpklBsKzk13LJrTQudqARHncq/J5P92Yw0/YNdMeTboSqz0=
X-Received: by 10.237.59.249 with SMTP id s54mr7577237qte.34.1508509613025;
 Fri, 20 Oct 2017 07:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.12.74 with HTTP; Fri, 20 Oct 2017 07:26:22 -0700 (PDT)
In-Reply-To: <59E9AC02.8090202@HIDDEN>
References: <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@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>
 <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
 <59E9AC02.8090202@HIDDEN>
From: Robert Weiner <rsw@HIDDEN>
Date: Fri, 20 Oct 2017 10:26:22 -0400
X-Gmail-Original-Message-ID: <CA+OMD9g22KgB4qp0-HkYjLgjgN7q70GPiJE5HhUVzjaoM7Vk=g@HIDDEN>
Message-ID: <CA+OMD9g22KgB4qp0-HkYjLgjgN7q70GPiJE5HhUVzjaoM7Vk=g@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="94eb2c0e6e329fed5d055bfb4309"
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 (----)

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

On Fri, Oct 20, 2017 at 3:55 AM, martin rudalics <rudalics@HIDDEN> wrote:

> > =E2=80=8BOk.  It would be more helpful if you explained which problems =
you feel
> are
> > relevant to the discussion at hand.
>
> For example that of getting the screen dimensions of a window.  Have a
> look at x_real_pos_and_offsets to get an idea of the tribulations needed
> to do that for an Emacs frame.  These are by far the most complicated
> operations we do in the X specific code and I have reports that we still
> do not get the right results everywhere.


=E2=80=8BYes, I see.  I am having similar issues when trying to replicate t=
he size
of a frame under the macOS window system.  I can't seem to get the new
frame to match the old frame by using (frame-edges nil 'outer-edges) or
(frame-edges nil 'native-edges).  In earlier versions of Emacs, I don't
remember this being a problem but I can't recall when that was.  What is
the best way available to replicate the size of one frame to another given
the limitations that exist now?

Bob

--94eb2c0e6e329fed5d055bfb4309
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 Fri, Oct 20, 2=
017 at 3:55 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=8BOk.=C2=
=A0 It would be more helpful if you explained which problems you feel are<b=
r>
&gt; relevant to the discussion at hand.<br>
<br></span>
For example that of getting the screen dimensions of a window.=C2=A0 Have a=
<br>
look at x_real_pos_and_offsets to get an idea of the tribulations needed<br=
>
to do that for an Emacs frame.=C2=A0 These are by far the most complicated<=
br>
operations we do in the X specific code and I have reports that we still<br=
>
do not get the right results everywhere.</blockquote><div><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2=80=8BYe=
s, I see.=C2=A0 I am having similar issues when trying to replicate the siz=
e of a frame under the macOS window system.=C2=A0 I can&#39;t seem to get t=
he new frame to match the old frame by using (frame-edges nil &#39;outer-ed=
ges) or (frame-edges nil &#39;native-edges).=C2=A0 In earlier versions of E=
macs, I don&#39;t remember this being a problem but I can&#39;t recall when=
 that was.=C2=A0 What is the best way available to replicate the size of on=
e frame to another given the limitations that exist now?<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:monospace,monospace">Bob</di=
v><div class=3D"gmail_default" style=3D"font-family:monospace,monospace"><b=
r></div></div></div></div>

--94eb2c0e6e329fed5d055bfb4309--




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; 20 Oct 2017 07:56:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 20 03:56:11 2017
Received: from localhost ([127.0.0.1]:51051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1e5SA7-0001iJ-9X
	for submit <at> debbugs.gnu.org; Fri, 20 Oct 2017 03:56:11 -0400
Received: from mout.gmx.net ([212.227.17.21]:64569)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1e5SA5-0001i4-OS
 for 28620 <at> debbugs.gnu.org; Fri, 20 Oct 2017 03:56:10 -0400
Received: from [192.168.1.100] ([46.125.250.4]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M0LtB-1dDCZt1kXV-00ucmq; Fri, 20
 Oct 2017 09:55:48 +0200
Message-ID: <59E9AC02.8090202@HIDDEN>
Date: Fri, 20 Oct 2017 09:55:46 +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>
 <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>
 <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
In-Reply-To: <CA+OMD9j28jkQ6YbAFf6PAYxBYsMNimbPsg1m+owY9pqp1vuBwQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:OMm0XE4cd1xiKvqqxn/xIjit39iG8yWdoE0cI+8vHTKUgWWrabm
 rP8XdXk8gkuF1n2O47uluTK0UQT8eZUk4wO8Y2UIIHOq5sI01NnLpjlezwXLbAVfHAQP10d
 TXVbt8zeS2Pw44sB/lMZ1NPELSkgxOjyYgVfMgmoQS8KL9EkseKdFQncBqCbpb3HzJKnWVX
 IGDHc/+nUql3L+3rQriOQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:84c249s3u0Q=:X/dUIfNYl5Ef+sBi+0CKFx
 xXuv3NoGnp59M4PYsspn5wT8I+MHztNiv9D25VUWyWHSJNzBBBBt7g96284VpmnaujDA/J81F
 Iw73Vbm7kB6T5aBMU83KPwnR0xqddWesa88P9kmQEpg5U6+9ueONnBgMoidzDHMHCNIGP6bly
 Y0gziBAOmNFPIJTuY+bxRvdaEFvxqsyNcYZ3KYeL9Cevo9+FVAxfmmJCsl6lC8bvc7hzilg0n
 tCYhOeEbEqTLacW0l51GzTUsWgGgaI7LWCIxPpcVZsu4xEAMPZ8Taq4bIaW69jSWcMAZqEMbC
 zcdng3HC5GXbfvJKJjtDYW4dUPQFSrrB2sYr8oo9bBQtc9jCtYD7XKe+P4n2HYqXG3r2Hpjla
 XGC9mFoSRS+a59vw+fUz43CvV3JD+Oa1IWmCp5zW8BI7MU6YoI04hDILF2dxetnd0l/MKgGb0
 DObJVhsiv/C/1wPyD0mL3B9Y9WYL+/XMtbXUERXNoU68BZlzhDFOsT3M3EGg3U6y58Ft2zECZ
 BjFiZWfDn6Che4Spms25hWV5gMiPzFQwR2kB2S1QFAnFSO8Ibgzr33/ZiUgoROTgD/JPlMtg4
 4FVqc799HtAiY/M6pFRp/EKjORaY5ELHVxxZE7SZeFy5uNFHbzU0wdVVSh9Eiw1bhmZD+YX0k
 2y4tTGSBZyimm4juA5F8VYNFBxMl2m0RsXZz9inCQ++JcJGeSvMhzS9MzG/rqjwwqxkrE+CmD
 XldLJUm9PzpJ3YioF7pcoH765a7krNRxbyJm6z9vZ7kXoq4jvYqKJqi8FcR7co1SFa5GFgZgI
 NJFAyZITYutPodLmm5TczWJ4q/RbrEqTSHmurHazwOBgIhMEs3Ba5yUVTvGZxsUiUwexiXe
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.  It would be more helpful if you explained which problems=
 you feel are
 > relevant to the discussion at hand.

For example that of getting the screen dimensions of a window.  Have a
look at x_real_pos_and_offsets to get an idea of the tribulations needed
to do that for an Emacs frame.  These are by far the most complicated
operations we do in the X specific code and I have reports that we still
do not get the right results everywhere.

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; 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: Mon, 25 Nov 2019 12:00:02 UTC

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