GNU bug report logs -
#48409
Text runs away before user can copy it
Previous Next
Full log
Message #61 received at 48409 <at> debbugs.gnu.org (full text, mbox):
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 <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?
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).
This bug report was last modified 4 years and 51 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.