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

[martin rudalics <rudalics@gmx.at>]

 > 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.

 > 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.

 > 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.  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?

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.
But do we really want to show echo area messages even when there is no
echo in the first place?  Or am I missing something?

martin