[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48409: Text runs away before user can copy it
From: |
Alan Mackenzie |
Subject: |
bug#48409: Text runs away before user can copy it |
Date: |
Tue, 18 May 2021 20:23:55 +0000 |
Hello, Eli.
On Tue, May 18, 2021 at 22:05:03 +0300, Eli Zaretskii wrote:
> > Date: Tue, 18 May 2021 18:42:16 +0000
> > Cc: Juri Linkov <juri@linkov.net>, 48409@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > How can a simple stationary click in the echo area become a drag event?
> > I'm guessing there's some subtle bug in some function such as
> > make_lispy_event in keyboard.c. Any mouse experts who have suggestions,
> > please chime in, here!
> I think this is explained at the end of the node "Drag Events" in the
> ELisp manual.
Erm, not really. That bit explains how a drag event can become a click
event, not the other way around. Thanks anyhow.
I think I know why the problem is happening. When there are two lines
of text in the miniwindow:
(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. Or, maybe
the resizing of the miniwindow could be postponed till after the
up-mouse event.
Who is the mouse expert in Emacs? What does he say?
--
Alan Mackenzie (Nuremberg, Germany).
- bug#48409: Text runs away before user can copy it, (continued)
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/14
- bug#48409: [External] : bug#48409: Text runs away before user can copy it, Drew Adams, 2021/05/14
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/14
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/14
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/15
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/15
- bug#48409: Text runs away before user can copy it, Juri Linkov, 2021/05/17
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/18
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/18
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/18
- bug#48409: Text runs away before user can copy it,
Alan Mackenzie <=
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/19
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/19
- bug#48409: Text runs away before user can copy it, martin rudalics, 2021/05/19
- bug#48409: Text runs away before user can copy it, martin rudalics, 2021/05/20
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/21
- bug#48409: Text runs away before user can copy it, martin rudalics, 2021/05/22
- bug#48409: Text runs away before user can copy it, Alan Mackenzie, 2021/05/22
- bug#48409: Text runs away before user can copy it, martin rudalics, 2021/05/22
- bug#48409: Text runs away before user can copy it, Eli Zaretskii, 2021/05/22
- bug#48409: Text runs away before user can copy it, martin rudalics, 2021/05/22