bug#48409: Text runs away before user can copy it

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, May 19, 2021 at 15:12:35 +0300, Eli Zaretskii wrote:
> > Date: Tue, 18 May 2021 20:23:55 +0000
> > Cc: juri@linkov.net, 48409@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@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?

Yes, that should work.  The Lisp function window-edges, with appropriate
arguments, appears to do what we need.  I'll try that, and see if it
works.

-- 
Alan Mackenzie (Nuremberg, Germany).