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: Sun, 30 May 2021 15:44:00 +0000 Message-ID: References: <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="36081"; 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 Sun May 30 17:45:18 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 1lnNcr-0009EF-Ry for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 May 2021 17:45:17 +0200 Original-Received: from localhost ([::1]:50648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lnNcq-0004IC-V1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 May 2021 11:45:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnNcc-0004Hr-GV for bug-gnu-emacs@gnu.org; Sun, 30 May 2021 11:45:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lnNcc-0002eW-0V for bug-gnu-emacs@gnu.org; Sun, 30 May 2021 11:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lnNcb-0001pz-Tx for bug-gnu-emacs@gnu.org; Sun, 30 May 2021 11:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 May 2021 15:45:01 +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.16223894516985 (code B ref 48409); Sun, 30 May 2021 15:45:01 +0000 Original-Received: (at 48409) by debbugs.gnu.org; 30 May 2021 15:44:11 +0000 Original-Received: from localhost ([127.0.0.1]:60203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lnNbm-0001ob-NA for submit@debbugs.gnu.org; Sun, 30 May 2021 11:44:10 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:60885 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lnNbj-0001ny-Ed for 48409@debbugs.gnu.org; Sun, 30 May 2021 11:44:10 -0400 Original-Received: (qmail 33468 invoked by uid 3782); 30 May 2021 15:44:01 -0000 Original-Received: from acm.muc.de (p2e5d5a0f.dip0.t-ipconnect.de [46.93.90.15]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 30 May 2021 17:44:01 +0200 Original-Received: (qmail 18876 invoked by uid 1000); 30 May 2021 15:44:00 -0000 Content-Disposition: inline In-Reply-To: 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:207628 Archived-At: Hello, Martin. The conversation about this bug has gone a bit quiet. It seems neither of us has got much more to say about it. I propose committing my patch in the next day or two. If there's anything more to say about it, please let me know, soon. Thanks! On Sat, May 22, 2021 at 11:42:18 +0000, Alan Mackenzie wrote: > 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).