From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#48409: Text runs away before user can copy it Date: Sat, 22 May 2021 11:42:18 +0000 Message-ID: References: <83mtsxxfo8.fsf@gnu.org> <87h7j12j93.fsf@mail.linkov.net> <83bl98rxqo.fsf@gnu.org> <83k0nvrhgg.fsf@gnu.org> <844b5fd3-7d5a-a00a-00e6-4b853de199fa@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 48409@debbugs.gnu.org, juri@linkov.net To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 22 13:43:17 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 1lkQ2H-00082N-0G for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 13:43:17 +0200 Original-Received: from localhost ([::1]:59732 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkQ2E-0002jg-Ej for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 07:43:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkQ22-0002jY-KB for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkQ22-0007NQ-Cq for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lkQ22-00049c-Am for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 May 2021 11:43: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.162168374915930 (code B ref 48409); Sat, 22 May 2021 11:43:02 +0000 Original-Received: (at 48409) by debbugs.gnu.org; 22 May 2021 11:42:29 +0000 Original-Received: from localhost ([127.0.0.1]:38397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkQ1U-00048s-Iz for submit@debbugs.gnu.org; Sat, 22 May 2021 07:42:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:21547 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lkQ1R-00048c-Pz for 48409@debbugs.gnu.org; Sat, 22 May 2021 07:42:26 -0400 Original-Received: (qmail 15306 invoked by uid 3782); 22 May 2021 11:42:19 -0000 Original-Received: from acm.muc.de (p4fe1563e.dip0.t-ipconnect.de [79.225.86.62]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 22 May 2021 13:42:19 +0200 Original-Received: (qmail 4843 invoked by uid 1000); 22 May 2021 11:42:18 -0000 Content-Disposition: inline In-Reply-To: <844b5fd3-7d5a-a00a-00e6-4b853de199fa@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:207030 Archived-At: Hello, Martin. On Sat, May 22, 2021 at 10:05:05 +0200, martin rudalics wrote: > > 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. I can't think of any other sensible use where the window layout might change, either. But if somebody puts a command on down-mouse-1 which does this, we might end up generating a spurious drag event. It's difficult to predict precisely what people might do with Emacs. > > 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. Yes. Such are the decisions one has, somewhat arbitrarily, to make. ;-) > > 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. I was considering using the available C functions, but in the end decided it was too much bother. ;-( At least the processing here isn't time-critical. > 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? No, I don't think that's the case. If the up event position is outside the window, I move it to the nearest border (at a left/top border, or (1- border) for a right/bottom border). > 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. I think it's a good idea. Diagnosing the original symptoms was quite a bit harder than for most bugs, so it would be good to try to avoid similar things happening again. > But do we really want to show echo area messages even when there is no > echo in the first place? You mean, is view-echo-area-messages really a sensible command to bind to mouse-1? I wasn't actually aware of this facility until Juri (or was it Drew?) pointed it out in the bug report. It's not something I use myself (on a Linux tty with gpm-mouse-mode disabled). > Or am I missing something? I don't think so. > martin -- Alan Mackenzie (Nuremberg, Germany).