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

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

The conversation about this bug has gone a bit quiet.  It seems neither
of us has got much more to say about it.

I propose committing my patch in the next day or two.  If there's
anything more to say about it, please let me know, soon.  Thanks!


On Sat, May 22, 2021 at 11:42:18 +0000, Alan Mackenzie wrote:
> On Sat, May 22, 2021 at 10:05:05 +0200, martin rudalics wrote:
> >  > 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.

> I can't think of any other sensible use where the window layout might
> change, either.  But if somebody puts a command on down-mouse-1 which
> does this, we might end up generating a spurious drag event.  It's
> difficult to predict precisely what people might do with Emacs.

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

> Yes.  Such are the decisions one has, somewhat arbitrarily, to make.  ;-)

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

> I was considering using the available C functions, but in the end decided
> it was too much bother.  ;-(  At least the processing here isn't
> time-critical.

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

> No, I don't think that's the case.  If the up event position is outside
> the window, I move it to the nearest border (at a left/top border, or (1-
> border) for a right/bottom border).

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

> I think it's a good idea.  Diagnosing the original symptoms was quite a
> bit harder than for most bugs, so it would be good to try to avoid
> similar things happening again.

> > But do we really want to show echo area messages even when there is no
> > echo in the first place?

> You mean, is view-echo-area-messages really a sensible command to bind to
> mouse-1?  I wasn't actually aware of this facility until Juri (or was it
> Drew?) pointed it out in the bug report.  It's not something I use myself
> (on a Linux tty with gpm-mouse-mode disabled).

> > Or am I missing something?

> I don't think so.

> > martin

-- 
Alan Mackenzie (Nuremberg, Germany).