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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli and Juri.

On Tue, May 18, 2021 at 16:13:19 +0300, Eli Zaretskii wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: Alan Mackenzie <acm@muc.de>,  48409@debbugs.gnu.org
> > Date: Mon, 17 May 2021 23:53:12 +0300

> > Something strange is going on here:

> > 1. when the shell output displayed in the echo area is only 1 line:

> >   M-! echo -e "line1" RET

> > then clicking on the echo area displays the *Messages* buffer correctly.

> > 2. But when the output has more lines:

> >   M-! echo -e "line1\nline2" RET

> > then clicking on the echo area signals an error:

> >   mouse-minibuffer-check: Minibuffer window is not active

> You don't need M-! for this, 'message' is enough:

>   emacs -Q
>   (message "line1\nline2") C-x C-e
>   click mouse-1 in the mini-window

Yes.  But I think Juri's right about it being the number of lines in the
echo area which is the key to the error.

> Alan, are you looking into this?

I am now, yes.

> My guess is that this has something to do with the fact the the
> echo-area buffer is displayed in the mini-window, and the
> view-echo-area-messages binding is only active in the minibuffer, not
> in an echo-area buffer.  But that's a guess.

The error message "Minibuffer window is not active" comes from  the
function mouse-minibuffer-check (mouse.el), which has just been called
from mouse-set-region, which has somehow been given a drag event as
argument.

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!

-- 
Alan Mackenzie (Nuremberg, Germany).