From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#48409: Text runs away before user can copy it Date: Sat, 22 May 2021 10:05:05 +0200 Message-ID: <844b5fd3-7d5a-a00a-00e6-4b853de199fa@gmx.at> References: <83fsypztd4.fsf@gnu.org> <87cztt9qdj.fsf@mail.linkov.net> <83mtsxxfo8.fsf@gnu.org> <87h7j12j93.fsf@mail.linkov.net> <83bl98rxqo.fsf@gnu.org> <83k0nvrhgg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6391"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48409@debbugs.gnu.org, juri@linkov.net To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 22 10:06:24 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lkMeM-0001QN-VU for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 10:06:22 +0200 Original-Received: from localhost ([::1]:43196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkMeM-0003Fx-1e for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 04:06:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkMe6-0003Cq-9X for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 04:06:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54969) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkMe3-00007X-5B for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 04:06:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lkMe3-00059a-0h for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 04:06:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 May 2021 08:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48409 X-GNU-PR-Package: emacs Original-Received: via spool by 48409-submit@debbugs.gnu.org id=B48409.162167071719736 (code B ref 48409); Sat, 22 May 2021 08:06:02 +0000 Original-Received: (at 48409) by debbugs.gnu.org; 22 May 2021 08:05:17 +0000 Original-Received: from localhost ([127.0.0.1]:38278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkMdI-00058F-PI for submit@debbugs.gnu.org; Sat, 22 May 2021 04:05:17 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:45095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkMdG-000581-Jg for 48409@debbugs.gnu.org; Sat, 22 May 2021 04:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1621670707; bh=67sXMTlXOYFVP67JvgXSUAd/2H0T0kRpwYtKsiEpQM4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VPlQfYSC4iMFQm/Ndy525SCSB09wd/GFs949/UAg1zh3NyQqA5IFZSTV6uNLtBPtj 0J+oQNKsGU2TlV0GoUnZGPfSL/niqL3ornuOfqMLTj5Qz0QZSVn9I0C5kVtu1VrDG6 RbE7OV/MzYH4tht5WcgDne3VsxCr2mElOSBcUmUU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([213.142.96.249]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M8ykW-1lqOlo3Lr4-0066dB; Sat, 22 May 2021 10:05:06 +0200 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:BEJ9N4NYfZeYAwTqX1ZgaQjKV1CUb8AKSWCz6JtYnhlG8RPIkTX G166K+HcXjhPDogVUteUYSJYX1qfarn2KuLWwVMr/DckhPVKujrRhkx3n+6t/VdylhgOvVr Yjd8Nfew+1JzlqBMmziV2dQzsQSSadmPgKcK9FzRHVkuhEuFKGNQUY6XZX+9J+3QgUo1uBz 4c5cazeHvqHLzZ0EE0CzA== X-UI-Out-Filterresults: notjunk:1;V03:K0:1w2ioJTElq8=:PooLQpGMomPXhKM99QtQST Ju1u068vuh48JZZS7go/TnlHFoI8GvxF6dIxUTl+vE0nzNl0fpVXAYJYkRFlvdltK1VHESoFp RcBP6Vlogt5lauA7rZBjbf1DWmNQhWv7T/DI06z8ZRhlhOIyl4Acjrsz20CsHpUIYt+ndc5s+ 3WlhS1mmr/i2rrJtnKH07SXl7dw5G1XUUjvByqupJEON0SmaE81XfglCN3YJ+cacsABTXnMY+ o24+A9EWbZ1/Vj7E9RFhjMb3p4GLP0dLJErP7PVsWNMd6NQW+Tr5JNSlwao/cXDBeQXSGNrYT pMlWyGA1GGOc4mvGKzFDA+Hmor+oyqAL8a4HIUzyxm025IP8hGX506QBKkOvMhea8MLwjV9Iw ImOcN+Mfkitqx1I5gh3ydQZsQDCiGRY5iA6YRIAg57kPtcYGR1YrUZuBAAozg5xs8BmkRPiec XKQE3qLF7kk3ZV+desJzA40QpOv0lAXBZ3xVMo2QB8a2etRz6KcEkFKEVwR8ZO7Aj9NKf9+1n mA8EZORA5NECcTax6YqUrgsCknqxxUxBY0KWY91QJKzpyRLF6imQlHLTg1Kk/cbQMcTxBpzsy hKcT4gFEjNe0NkJ6J7pYIcocb+83eF4S3fhks6rMkN8Ki2SYiNshayVh962885ARoX66iTdaJ LWK3cu4PwtOiGcLLXvbwUFkdDJv9Khc7bXa2xo4w73XQ6SQg9RG7hvjNymrq+UMOIpbha6n5R SeQZhC0mQS03wUq2ivFCFmZcMjy2e65RyTT0VCUP1jJ/Y3QEjzkba5lvh6pwM1efwmb3Pp7M X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:207017 Archived-At: > I've been laboriously working out a patch, too, and have come up with > the one below. It takes a surprisingly similar approach to your own > patch [snipped], but doesn't test for a minibuffer, so perhaps is more > general. I didn't actually study your patch till my own was nearly > finished. I didn't include the minibuffer check initially. But since I can't think of any other occasion where we would change window coordinates in between a down and up event, I thought it's cheaper to use it. > To detect mouse movement, my patch changes from comparing window > relative x, y to frame relative x, y. In order to identify clicks on the bottom line, I check whether the top y-coordinate of the (mini-)window has changed. If it has changed, I simply declare that no mouse movement occurred. Comparing frame relative coordinates is cleaner at the expense of having to store them always for each button down event. > If the code detects no movement, > but a different window, the position of the up event is changed to be > inside the window of the down event. I didn't check that part but I think that using `window-edges' here is slightly over-engineered. OTOH, it gives you the body of the minibuffer window at no cost. So I'm undecided what's better. Am I right that you return a position near the upper right corner of the window? If so why? Finally, I'm now completely lost wrt what our patches are trying to achieve. Ruling out drag events when there are none is not a bad idea. But do we really want to show echo area messages even when there is no echo in the first place? Or am I missing something? martin