GNU bug report logs - #48409
Text runs away before user can copy it

Previous Next

Full log

Message #58 received at 48409 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: acm <at> muc.de, 48409 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#48409: Text runs away before user can copy it
Date: Wed, 19 May 2021 15:12:35 +0300

> Date: Tue, 18 May 2021 20:23:55 +0000
> Cc: juri <at> linkov.net, 48409 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> (i) A down-mouse event occurs in the miniwindow:
>   o - the mouse position relative to the top of the two-line miniwindow
>     is stored somewhere.
>   o - redisplay (or something) changes the two-line miniwindow into a
>     one-line miniwindow.
> (ii) The up-mouse event occurs in the same place:
>   o - the mouse position is determined 	RELATIVE TO THE NEWLY SIZED
>     MINIWINDOW.
>   o - The y coordinate is significantly different from that of the
>     stored mouse position.
>   o - Due to this difference, make_lispy_event thinks the mouse has
>     moved, so returns a drag event.
> 
> The above is the basic scenario.  If the mouse is on the top line of the
> miniwindow when the mouse is clicked, the returned y coordinate at (ii)
> is in the mode line of the window above, and is determined relative to
> that window.
> 
> I don't have any workable ideas on how to fix this bug.  The only idea
> which springs to mind is to move from expressing mouse positions
> relative to a window to expressing it relative to a frame.

You could simply recalculate the position to be frame-relative, and if
so, invoke the click-event binding.  Right?

Previous Next

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