GNU bug report logs - #48409
Text runs away before user can copy it

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>, 48409 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#48409: Text runs away before user can copy it
Date: Sat, 22 May 2021 11:42:18 +0000

Hello, Martin.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.