From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66655: 29.1; Clicking buttons sometimes doesn't work Date: Thu, 26 Oct 2023 08:07:52 +0300 Message-ID: <837cnahsyf.fsf@gnu.org> References: <1d9187b71e7288eaf08ac9a2f0559bdf@gmail.com> <83v8axmbsh.fsf@gnu.org> <83y1fskyjj.fsf@gnu.org> <83il6wktxt.fsf@gnu.org> <83h6mgkst3.fsf@gnu.org> <83edhkkrzd.fsf@gnu.org> <83bkcokoxu.fsf@gnu.org> <83pm12kj44.fsf@gnu.org> <83msw6it17.fsf@gnu.org> <83h6meiraw.fsf@gnu.org> <83fs1yimho.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24153"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomasralph2000@gmail.com, 66655@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 26 07:08:51 2023 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 1qvsbz-000657-7N for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Oct 2023 07:08:51 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qvsbh-0001zn-TG; Thu, 26 Oct 2023 01:08:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvsbg-0001vV-KL for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 01:08:32 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qvsbg-0000Ud-8m for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 01:08:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qvscA-0002vO-Gz for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 01:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2023 05:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66655 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 66655-submit@debbugs.gnu.org id=B66655.169829691111200 (code B ref 66655); Thu, 26 Oct 2023 05:09:02 +0000 Original-Received: (at 66655) by debbugs.gnu.org; 26 Oct 2023 05:08:31 +0000 Original-Received: from localhost ([127.0.0.1]:60412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qvsbe-0002ua-Ol for submit@debbugs.gnu.org; Thu, 26 Oct 2023 01:08:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qvsbZ-0002uJ-IP for 66655@debbugs.gnu.org; Thu, 26 Oct 2023 01:08:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qvsaz-0000Oa-1O; Thu, 26 Oct 2023 01:07:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ad2S2MvMqNb2eqwd9i5zdFfa4eIWXAyVeyOUBD0mZo8=; b=SScifwojW+rq mIhpq8kdpZg0y9WUIcHTgKJ7JeOFom9Q3am3GK36cLpxx7YYYDJ2OPORbJBMOafihZixNlDxOp9EN o7AmeYy/DdjpXxbDm5kQKGBHBftK+JM+ulhXM7eWjWJbdgFXCC9p0M7vpyu1hUJdC7tDidEh2JXQZ tn7TCPV7vrbXsaM+1xKm21ytozGLJ3/M2FM5j+unUAE4G7nqMqFBa9Tp6ACpXXSgbg1wj5+JagQvu nUgX7jTvzfqjbE5R+o03PH5ofmN2hvUy9qoEhsWiWkM8PiO2fCcQrdf4jxHh6jUB9jbj+5SkMoGLu 3dB6cbb/vIomnGYNl57KTA==; In-Reply-To: (message from Stefan Monnier on Wed, 25 Oct 2023 17:22:41 -0400) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273238 Archived-At: > From: Stefan Monnier > Cc: tomasralph2000@gmail.com, 66655@debbugs.gnu.org > Date: Wed, 25 Oct 2023 17:22:41 -0400 > > >> In my "in short is approximately" I used `mouse_has_moved` but that > >> was an oversimplification: in the new code `mouse_has_moved` doesn't > >> revert to "false" when the mouse returns to the original position, > >> contrary to what happen in the current code. > > > > How exactly does that happen? > > Because as soon as `note_mouse_highlight` receives information that the > mouse is outside of the fuzz, the var is set to `false` [ And it's only > set to true when we get the mouse-down event ]. I don't think I understand this explanation. (Did you mean "true" instead of "false"?) You started by saying that your code detects mouse movement, and I asked how does it detect it. AFAIR, Emacs doesn't receive mouse-motion events unless we turn on track-mouse, which we usually avoid doing. So this code was originally detecting mouse movement by comparing the screen coordinates of the down- and up-events. I'm asking how is your code different? > >> The comment above talks about buffer positions (i.e. the Fcar+Fcdr > >> part of the positions), whereas this `EQ` tests the windows, and the > >> only relevant comment I see is > >> > >> /* Different window */ > >> > >> which reminds the reader that it's comparing windows but doesn't say why. > >> Did I miss something? > > > > Yes: we can be at the same buffer position, but a different window. > > Right, but what's the problem with that? You could have redisplay change the windows under your feet, such that the screen coordinates are the same, the buffer position is the same, but the window is not the same. That test wants to emit a drag event in such a case. That is my understanding of the test. > I see now that this was done (in commit > 6e2d3bce087d30a535b1f01715d7820576ffe390) to handle the case where > a mouse click causes some window-shuffle, so the up event ends up > pointing into another window. Exactly. > I think my code is immune to this problem since with it we only ever > generate a drag event if the mouse actually moved. Which leads to > a further simplification of the code, see patch below. I still don't understand the implication of the mouse_has_moved part.