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

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

[積丹尼 Dan Jacobson]

Do e.g.,
M-! cat /etc/motd

OK now in the minibuffer are several lines of juicy text.

Now grab the mouse and attempt to copy that text.

Alas, upon clicking, the text disappears.

Pro users know better, but average bumpkin users will be frustrated.

So maybe have the minibuffer stay put / stay open during this sequence of events.

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

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson
>  <jidanni@jidanni.org>
> Date: Fri, 14 May 2021 14:32:54 +0800
> 
> Do e.g.,
> M-! cat /etc/motd
> 
> OK now in the minibuffer are several lines of juicy text.
> 
> Now grab the mouse and attempt to copy that text.
> 
> Alas, upon clicking, the text disappears.
> 
> Pro users know better, but average bumpkin users will be frustrated.
> 
> So maybe have the minibuffer stay put / stay open during this sequence of events.

Please RTFM.  The doc string of M-! says, inter alia:

  If COMMAND ends in ‘&’, execute it asynchronously.
  The output appears in the buffer ‘*Async Shell Command*’.
  That buffer is in shell mode.  You can also use
  ‘async-shell-command’ that automatically adds ‘&’.

  Otherwise, COMMAND is executed synchronously.  The output appears in
  the buffer ‘*Shell Command Output*’.  If the output is short enough to
  display in the echo area (which is determined by the variables
  ‘resize-mini-windows’ and ‘max-mini-window-height’), it is shown
  there, but it is nonetheless available in buffer ‘*Shell Command
  Output*’ even though that buffer is not automatically displayed.

(The user manual has a similar text.)

So the text you want is still available in an Emacs buffer, and you
can take it from there.

Closing.

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

[Juri Linkov]

>   Otherwise, COMMAND is executed synchronously.  The output appears in
>   the buffer ‘*Shell Command Output*’.  If the output is short enough to
>   display in the echo area (which is determined by the variables
>   ‘resize-mini-windows’ and ‘max-mini-window-height’), it is shown
>   there, but it is nonetheless available in buffer ‘*Shell Command
>   Output*’ even though that buffer is not automatically displayed.
>
> (The user manual has a similar text.)
>
> So the text you want is still available in an Emacs buffer, and you
> can take it from there.

I vaguely remember a feature that clicking on the echo area
pops up the *Messages* buffer with the recent messages
at the end of the *Messages* buffer.  So Jidanni could just click
on the shell output in the echo area, and copy the complete output
from the displayed *Messages* buffer.

But this feature doesn't work anymore.  Searching the source code
indicates that such a feature existed before.  In minibuffer.el:

(defvar minibuffer-inactive-mode-map
  (let ((map (make-keymap)))
    ...
    (define-key map [mouse-1] 'view-echo-area-messages)

But now clicking mouse-1 reports an error.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eliz@gnu.org,  jidanni@jidanni.org
> Date: Fri, 14 May 2021 20:58:24 +0300
> 
> I vaguely remember a feature that clicking on the echo area
> pops up the *Messages* buffer with the recent messages
> at the end of the *Messages* buffer.  So Jidanni could just click
> on the shell output in the echo area, and copy the complete output
> from the displayed *Messages* buffer.
> 
> But this feature doesn't work anymore.

He is using Emacs 27, where it does work.

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: eliz@gnu.org,  jidanni@jidanni.org
> Date: Fri, 14 May 2021 20:58:24 +0300
> 
> I vaguely remember a feature that clicking on the echo area
> pops up the *Messages* buffer with the recent messages
> at the end of the *Messages* buffer.  So Jidanni could just click
> on the shell output in the echo area, and copy the complete output
> from the displayed *Messages* buffer.
> 
> But this feature doesn't work anymore.  Searching the source code
> indicates that such a feature existed before.  In minibuffer.el:
> 
> (defvar minibuffer-inactive-mode-map
>   (let ((map (make-keymap)))
>     ...
>     (define-key map [mouse-1] 'view-echo-area-messages)
> 
> But now clicking mouse-1 reports an error.

It reports an error because it doesn't invoke view-echo-area-messages.

Alan, this minibuffer-inactive-mode-map thing doesn't seem to work
with mouse clocks, please take a look.

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

[Drew Adams]

> Alan, this minibuffer-inactive-mode-map thing doesn't
> seem to work with mouse clocks, please take a look.

Perhaps the mice just need to wind their clocks?

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

[Eli Zaretskii]

> Date: Fri, 14 May 2021 22:45:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 48409@debbugs.gnu.org
> 
> > (defvar minibuffer-inactive-mode-map
> >   (let ((map (make-keymap)))
> >     ...
> >     (define-key map [mouse-1] 'view-echo-area-messages)
> > 
> > But now clicking mouse-1 reports an error.
> 
> It reports an error because it doesn't invoke view-echo-area-messages.
> 
> Alan, this minibuffer-inactive-mode-map thing doesn't seem to work
> with mouse clocks, please take a look.

Alan, is the below the right fix?  The problem is that no one is
setting up the minibuffer in inactive mode until after the first time
the minibuffer is activated.

diff --git a/src/minibuf.c b/src/minibuf.c
index 428998a..9ec93a0 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -2297,6 +2297,8 @@ init_minibuf_once_for_pdumper (void)
   minibuf_prompt = Qnil;
   minibuf_save_list = Qnil;
   last_minibuf_string = Qnil;
+  Lisp_Object minibuf = get_minibuffer (0);
+  set_minibuffer_mode (minibuf, 0);
 }
 
 void

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

[Alan Mackenzie]

Hello, Eli.

On Fri, May 14, 2021 at 23:13:50 +0300, Eli Zaretskii wrote:
> > Date: Fri, 14 May 2021 22:45:43 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 48409@debbugs.gnu.org

> > > (defvar minibuffer-inactive-mode-map
> > >   (let ((map (make-keymap)))
> > >     ...
> > >     (define-key map [mouse-1] 'view-echo-area-messages)

> > > But now clicking mouse-1 reports an error.

> > It reports an error because it doesn't invoke view-echo-area-messages.

> > Alan, this minibuffer-inactive-mode-map thing doesn't seem to work
> > with mouse clocks, please take a look.

> Alan, is the below the right fix?  The problem is that no one is
> setting up the minibuffer in inactive mode until after the first time
> the minibuffer is activated.

> diff --git a/src/minibuf.c b/src/minibuf.c
> index 428998a..9ec93a0 100644
> --- a/src/minibuf.c
> +++ b/src/minibuf.c
> @@ -2297,6 +2297,8 @@ init_minibuf_once_for_pdumper (void)
>    minibuf_prompt = Qnil;
>    minibuf_save_list = Qnil;
>    last_minibuf_string = Qnil;
> +  Lisp_Object minibuf = get_minibuffer (0);
> +  set_minibuffer_mode (minibuf, 0);
>  }
> 
>  void

I'm not entirely sure.  I actually added a "get_minibuffer (0);" to
init_minibuf_once in my commit earlier on today, so perhaps the
"set_minibuffer_mode (minibuf, 0);" really belongs in that function.

I'm not quite sure in my own mind what should go into init_minibuf_once
and what into init_minibuf_once_for_pdumper.  I've taken as the
criterion what the comment there says:

  /* We run this function on first initialization and whenever we
     restore from a dump file.  pdumper doesn't try to preserve
     frames, windows, and so on, so reset everything related here.  */

, and thus put the creation of  *Minibuf-0* into init_minibuf_once.

It would be good to have a relatively simple fix for something in
minibuf.c, for once.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Fri, 14 May 2021 20:53:38 +0000
> Cc: juri@linkov.net, 48409@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Alan, is the below the right fix?  The problem is that no one is
> > setting up the minibuffer in inactive mode until after the first time
> > the minibuffer is activated.
> 
> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 428998a..9ec93a0 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -2297,6 +2297,8 @@ init_minibuf_once_for_pdumper (void)
> >    minibuf_prompt = Qnil;
> >    minibuf_save_list = Qnil;
> >    last_minibuf_string = Qnil;
> > +  Lisp_Object minibuf = get_minibuffer (0);
> > +  set_minibuffer_mode (minibuf, 0);
> >  }
> > 
> >  void
> 
> I'm not entirely sure.  I actually added a "get_minibuffer (0);" to
> init_minibuf_once in my commit earlier on today, so perhaps the
> "set_minibuffer_mode (minibuf, 0);" really belongs in that function.

init_minibuf_once isn't called after dumping, so that would not help.
We need to make sure the minibuffer is put in inactive mode when we
start Emacs.

> I'm not quite sure in my own mind what should go into init_minibuf_once
> and what into init_minibuf_once_for_pdumper.  I've taken as the
> criterion what the comment there says:
> 
>   /* We run this function on first initialization and whenever we
>      restore from a dump file.  pdumper doesn't try to preserve
>      frames, windows, and so on, so reset everything related here.  */
> 
> , and thus put the creation of  *Minibuf-0* into init_minibuf_once.

See above: this won't survive the dumping because the minibuffer's
mode isn't dumped.  And I see no reason to dump it; after all, it
only makes sense to dump things whose preparation is time-consuming.

> It would be good to have a relatively simple fix for something in
> minibuf.c, for once.  ;-)

And I thought I was fine providing a very simple fix.  Oh well...

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

[Alan Mackenzie]

Hello, Eli.

On Sat, May 15, 2021 at 08:56:41 +0300, Eli Zaretskii wrote:
> > Date: Fri, 14 May 2021 20:53:38 +0000
> > Cc: juri@linkov.net, 48409@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Alan, is the below the right fix?  The problem is that no one is
> > > setting up the minibuffer in inactive mode until after the first time
> > > the minibuffer is activated.

> > > diff --git a/src/minibuf.c b/src/minibuf.c
> > > index 428998a..9ec93a0 100644
> > > --- a/src/minibuf.c
> > > +++ b/src/minibuf.c
> > > @@ -2297,6 +2297,8 @@ init_minibuf_once_for_pdumper (void)
> > >    minibuf_prompt = Qnil;
> > >    minibuf_save_list = Qnil;
> > >    last_minibuf_string = Qnil;
> > > +  Lisp_Object minibuf = get_minibuffer (0);
> > > +  set_minibuffer_mode (minibuf, 0);
> > >  }

> > >  void

> > I'm not entirely sure.  I actually added a "get_minibuffer (0);" to
> > init_minibuf_once in my commit earlier on today, so perhaps the
> > "set_minibuffer_mode (minibuf, 0);" really belongs in that function.

> init_minibuf_once isn't called after dumping, so that would not help.
> We need to make sure the minibuffer is put in inactive mode when we
> start Emacs.

> > I'm not quite sure in my own mind what should go into
> > init_minibuf_once and what into init_minibuf_once_for_pdumper.  I've
> > taken as the criterion what the comment there says:

> >   /* We run this function on first initialization and whenever we
> >      restore from a dump file.  pdumper doesn't try to preserve
> >      frames, windows, and so on, so reset everything related here.  */

> > , and thus put the creation of  *Minibuf-0* into init_minibuf_once.

> See above: this won't survive the dumping because the minibuffer's
> mode isn't dumped.  And I see no reason to dump it; after all, it
> only makes sense to dump things whose preparation is time-consuming.

Thanks for clarifying that.  I'd misunderstood the comments, and got
those two functions' purposes mixed up.

So, your patch is then entirely correct, and what I'd put in yesterday
afternoon is not correct.  I'll get that fixed and committed now.

> > It would be good to have a relatively simple fix for something in
> > minibuf.c, for once.  ;-)

> And I thought I was fine providing a very simple fix.  Oh well...

Sorry, bad wording on my part.  The fix was simple, and I was rejoicing
in that simplicity.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> He is using Emacs 27, where it does work.

I'm not too sure about that.

Anyway my point is "Average Job Blubb user, who has never been to Emacs
School, will feel bad."

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

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: Juri Linkov <juri@linkov.net>,  48409@debbugs.gnu.org
> Date: Sat, 15 May 2021 20:29:06 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> EZ> He is using Emacs 27, where it does work.
> 
> I'm not too sure about that.
> 
> Anyway my point is "Average Job Blubb user, who has never been to Emacs
> School, will feel bad."

Averag Job Blubb is well advised to read the docs when he or she
encounters some issue.

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

[Juri Linkov]

>> (defvar minibuffer-inactive-mode-map
>>   (let ((map (make-keymap)))
>>     ...
>>     (define-key map [mouse-1] 'view-echo-area-messages)
>>
>> But now clicking mouse-1 reports an error.
>
> It reports an error because it doesn't invoke view-echo-area-messages.
>
> Alan, this minibuffer-inactive-mode-map thing doesn't seem to work
> with mouse clocks, please take a look.

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

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

[Eli Zaretskii]

> 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

Alan, are you looking into this?  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.

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

[Alan Mackenzie]

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

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

[Eli Zaretskii]

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

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

[Alan Mackenzie]

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

[Eli Zaretskii]

> Date: Tue, 18 May 2021 20:23:55 +0000
> Cc: juri@linkov.net, 48409@debbugs.gnu.org, acm@muc.de
> From: Alan Mackenzie <acm@muc.de>
> 
> (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.

You could simply recalculate the position to be frame-relative, and if
so, invoke the click-event binding.  Right?

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

[Alan Mackenzie]

Hello, Eli.

On Wed, May 19, 2021 at 15:12:35 +0300, Eli Zaretskii wrote:
> > Date: Tue, 18 May 2021 20:23:55 +0000
> > Cc: juri@linkov.net, 48409@debbugs.gnu.org, acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

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

> You could simply recalculate the position to be frame-relative, and if
> so, invoke the click-event binding.  Right?

Yes, that should work.  The Lisp function window-edges, with appropriate
arguments, appears to do what we need.  I'll try that, and see if it
works.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

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

Are you sure?  If the click happens on the bottom line, it's still here
reported for the minibuffer window only that now the double click fuzz
rigmarole breaks in and says that the mouse has moved.

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

For clicks into the bottom line the attached might help.  Clicks above
must be caught elsewhere.  But you don't get a drag event and no error
message for them.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: keyboard.c.diff --]
[-- Type: text/x-patch; name="keyboard.c.diff", Size: 992 bytes --]

diff --git a/src/keyboard.c b/src/keyboard.c
index 47b5e59024..2aa47b57fa 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5727,9 +5727,21 @@ make_lispy_event (struct input_event *event)
 			  it's probably OK to ignore it as well.  */
 		       && EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position)))))
 		  {
-		    /* Mouse has moved enough.  */
-		    button_down_time = 0;
-		    click_or_drag_modifier = drag_modifier;
+		    Lisp_Object pos_window = XCAR (position);
+
+		    if (EQ (XCAR (start_pos), pos_window)
+			&& (!WINDOW_LIVE_P (pos_window)
+			  /* Make sure down has still valid coordinates
+			     within position's window.  */
+			    || ((XWINDOW (pos_window)->pixel_height
+				 >= XFIXNUM (XCDR (down)))
+				&& (XWINDOW (pos_window)->pixel_width
+				    >= XFIXNUM (XCAR (down))))))
+		      /* Mouse has moved enough.  */
+		      {
+			button_down_time = 0;
+			click_or_drag_modifier = drag_modifier;
+		      }
 		  }
 	      }

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

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

 > For clicks into the bottom line the attached might help.  Clicks above
 > must be caught elsewhere.  But you don't get a drag event and no error
 > message for them.

The attached patch should allow clicking anywhere in the minibuffer
window.  Its more than kludgy but this is a bug that has annoyed me
for years.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: keyboard.c.diff --]
[-- Type: text/x-patch; name="keyboard.c.diff", Size: 2385 bytes --]

diff --git a/src/keyboard.c b/src/keyboard.c
index 47b5e59024..92f842f2d7 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5625,11 +5625,12 @@ make_lispy_event (struct input_event *event)
 	start_pos = *start_pos_ptr;
 	*start_pos_ptr = Qnil;

+	struct frame *f;
+
 	{
 	  /* On window-system frames, use the value of
 	     double-click-fuzz as is.  On other frames, interpret it
 	     as a multiple of 1/8 characters.  */
-	  struct frame *f;
 	  intmax_t fuzz;

 	  if (WINDOWP (event->frame_or_window))
@@ -5727,9 +5728,48 @@ make_lispy_event (struct input_event *event)
 			  it's probably OK to ignore it as well.  */
 		       && EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position)))))
 		  {
-		    /* Mouse has moved enough.  */
-		    button_down_time = 0;
-		    click_or_drag_modifier = drag_modifier;
+		    Lisp_Object start_window = XCAR (start_pos);
+		    Lisp_Object pos_window = XCAR (position);
+
+		    /* For the minibuffer window special precautions are
+		       needed because it may change its height in between
+		       two clicks.  */
+		    if (WINDOW_LIVE_P (pos_window)
+			&& WINDOW_LIVE_P (start_window)
+			&& MINI_WINDOW_P (XWINDOW (start_window)))
+		      {
+			struct window *start_w = XWINDOW (start_window);
+			struct window *pos_w = XWINDOW (pos_window);
+
+			if (start_w == pos_w
+			    && WINDOW_PIXEL_HEIGHT (pos_w) >= XFIXNUM (XCDR (down))
+			    && WINDOW_PIXEL_WIDTH (pos_w) >= XFIXNUM (XCAR (down)))
+			  /* Mouse has moved enough.  */
+			  {
+			    button_down_time = 0;
+			    click_or_drag_modifier = drag_modifier;
+			  }
+			else if (start_w != pos_w
+				 && (WINDOW_PIXEL_HEIGHT (start_w) >= XFIXNUM (XCDR (down))
+				     || WINDOW_PIXEL_WIDTH (start_w) >= XFIXNUM (XCDR (down))))
+			  /* Artificially move mouse into the minibuffer
+			     window's new text area.  */
+			  position
+			    = make_lispy_position (f,
+						   make_fixnum (WINDOW_BOX_LEFT_EDGE_X (start_w)
+								+ WINDOW_LEFT_FRINGE_WIDTH (start_w)
+								+ WINDOW_LEFT_MARGIN_WIDTH (start_w)
+								+ 1),
+						   make_fixnum (WINDOW_TOP_EDGE_Y (start_w) + 1),
+						   event->timestamp);
+		      }
+		    else
+		      /* Mouse has moved enough.  */
+		      {
+			button_down_time = 0;
+			click_or_drag_modifier = drag_modifier;
+		      }
+
 		  }
 	      }

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

[Alan Mackenzie]

Hello, Martin.

On Thu, May 20, 2021 at 18:54:45 +0200, martin rudalics wrote:
>  > For clicks into the bottom line the attached might help.  Clicks above
>  > must be caught elsewhere.  But you don't get a drag event and no error
>  > message for them.

> The attached patch should allow clicking anywhere in the minibuffer
> window.  Its more than kludgy but this is a bug that has annoyed me
> for years.

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.

To detect mouse movement, my patch changes from comparing window
relative x, y to frame relative x, y.  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.



diff --git a/src/keyboard.c b/src/keyboard.c
index 47b5e59024..08386e0685 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -5022,6 +5022,10 @@ static short const internal_border_parts[] = {
 
 static Lisp_Object button_down_location;
 
+/* A cons recording the original frame-relative x and y coordinates of
+   the down mouse event.  */
+static Lisp_Object frame_relative_event_pos;
+
 /* Information about the most recent up-going button event:  Which
    button, what location, and what time.  */
 
@@ -5673,6 +5677,7 @@ make_lispy_event (struct input_event *event)
 	      double_click_count = 1;
 	    button_down_time = event->timestamp;
 	    *start_pos_ptr = Fcopy_alist (position);
+	    frame_relative_event_pos = Fcons (event->x, event->y);
 	    ignore_mouse_drag_p = false;
 	  }
 
@@ -5695,20 +5700,12 @@ make_lispy_event (struct input_event *event)
 	      ignore_mouse_drag_p = false;
 	    else
 	      {
-		Lisp_Object new_down, down;
 		intmax_t xdiff = double_click_fuzz, ydiff = double_click_fuzz;
 
-		/* The third element of every position
-		   should be the (x,y) pair.  */
-		down = Fcar (Fcdr (Fcdr (start_pos)));
-		new_down = Fcar (Fcdr (Fcdr (position)));
-
-		if (CONSP (down)
-		    && FIXNUMP (XCAR (down)) && FIXNUMP (XCDR (down)))
-		  {
-		    xdiff = XFIXNUM (XCAR (new_down)) - XFIXNUM (XCAR (down));
-		    ydiff = XFIXNUM (XCDR (new_down)) - XFIXNUM (XCDR (down));
-		  }
+		xdiff = XFIXNUM (event->x)
+		  - XFIXNUM (XCAR (frame_relative_event_pos));
+		ydiff = XFIXNUM (event->y)
+		  - XFIXNUM (XCDR (frame_relative_event_pos));
 
 		if (! (0 < double_click_fuzz
 		       && - double_click_fuzz < xdiff
@@ -5725,12 +5722,51 @@ make_lispy_event (struct input_event *event)
 			  a click.  But mouse-drag-region completely ignores
 			  this case and it hasn't caused any real problem, so
 			  it's probably OK to ignore it as well.  */
-		       && EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position)))))
+		       && (EQ (Fcar (Fcdr (start_pos)),
+			       Fcar (Fcdr (position))) /* Same buffer pos */
+			   || !EQ (Fcar (start_pos),
+				   Fcar (position))))) /* Different window */
 		  {
 		    /* Mouse has moved enough.  */
 		    button_down_time = 0;
 		    click_or_drag_modifier = drag_modifier;
 		  }
+		else if (((!EQ (Fcar (start_pos), Fcar (position)))
+			  || (!EQ (Fcar (Fcdr (start_pos)),
+				   Fcar (Fcdr (position)))))
+			 /* Was the down event in a window body? */
+			 && FIXNUMP (Fcar (Fcdr (start_pos)))
+			 && WINDOW_LIVE_P (Fcar (start_pos))
+			 && Ffboundp (Qwindow_edges))
+		  /* If the window (etc.) at the mouse position has
+		     changed between the down event and the up event,
+		     we assume there's been a redisplay between the
+		     two events, and we pretend the mouse is still in
+		     the old window to prevent a spurious drag event
+		     being generated.  */
+		  {
+		    Lisp_Object edges
+		      = call4 (Qwindow_edges, Fcar (start_pos), Qt, Qnil, Qt);
+		    int new_x = XFIXNUM (Fcar (frame_relative_event_pos));
+		    int new_y = XFIXNUM (Fcdr (frame_relative_event_pos));
+
+		    /* If the up-event is outside the down-event's
+		       window, use coordinates that are within it.  */
+		    if (new_x < XFIXNUM (Fcar (edges)))
+		      new_x = XFIXNUM (Fcar (edges));
+		    else if (new_x >= XFIXNUM (Fcar (Fcdr (Fcdr (edges)))))
+		      new_x = XFIXNUM (Fcar (Fcdr (Fcdr (edges)))) - 1;
+		    if (new_y < XFIXNUM (Fcar (Fcdr (edges))))
+		      new_y = XFIXNUM (Fcar (Fcdr (edges)));
+		    else if (new_y
+			     >= XFIXNUM (Fcar (Fcdr (Fcdr (Fcdr (edges))))))
+		      new_y = XFIXNUM (Fcar (Fcdr (Fcdr (Fcdr (edges))))) - 1;
+
+		    position = make_lispy_position
+		      (XFRAME (event->frame_or_window),
+		       make_fixnum (new_x), make_fixnum (new_y),
+		       event->timestamp);
+		  }
 	      }
 
 	    /* Don't check is_double; treat this as multiple if the
@@ -11649,6 +11685,7 @@ syms_of_keyboard (void)
   DEFSYM (Qmake_frame_visible, "make-frame-visible");
   DEFSYM (Qselect_window, "select-window");
   DEFSYM (Qselection_request, "selection-request");
+  DEFSYM (Qwindow_edges, "window-edges");
   {
     int i;
 
@@ -11665,6 +11702,7 @@ syms_of_keyboard (void)
 
   button_down_location = make_nil_vector (5);
   staticpro (&button_down_location);
+  staticpro (&frame_relative_event_pos);
   mouse_syms = make_nil_vector (5);
   staticpro (&mouse_syms);
   wheel_syms = make_nil_vector (ARRAYELTS (lispy_wheel_names));


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[martin rudalics]

 > 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

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

[Alan Mackenzie]

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

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

[martin rudalics]

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

I just wouldn't want to have the echo area messages pop up whenever I
accidentally click into an empty minibuffer window.  So far this was no
issue because the mouse code prevented it ...

martin

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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 48409@debbugs.gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 22 May 2021 16:36:40 +0200
> 
> I just wouldn't want to have the echo area messages pop up whenever I
> accidentally click into an empty minibuffer window.

But that exactly what has been happening in Emacs 27 and before, since
this feature was added in Emacs 24.  And it _is_ a feature.

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

[martin rudalics]

 >> I just wouldn't want to have the echo area messages pop up whenever I
 >> accidentally click into an empty minibuffer window.
 >
 > But that exactly what has been happening in Emacs 27 and before, since
 > this feature was added in Emacs 24.  And it _is_ a feature.

It never worked with an auto-resizing minibuffer window where it might
be a feature.  But since I never noticed it before, it's apparently no
great nuisance either.

martin

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

[Alan Mackenzie]

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

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

[martin rudalics]

 > I propose committing my patch in the next day or two.

Please go ahead.

 > If there's
 > anything more to say about it, please let me know, soon.  Thanks!

Thanks for fixing it, martin

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

[Alan Mackenzie]

Hello, Eli.

On Fri, May 14, 2021 at 22:45:43 +0300, Eli Zaretskii wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: eliz@gnu.org,  jidanni@jidanni.org
> > Date: Fri, 14 May 2021 20:58:24 +0300

> > I vaguely remember a feature that clicking on the echo area
> > pops up the *Messages* buffer with the recent messages
> > at the end of the *Messages* buffer.  So Jidanni could just click
> > on the shell output in the echo area, and copy the complete output
> > from the displayed *Messages* buffer.

> > But this feature doesn't work anymore.  Searching the source code
> > indicates that such a feature existed before.  In minibuffer.el:

> > (defvar minibuffer-inactive-mode-map
> >   (let ((map (make-keymap)))
> >     ...
> >     (define-key map [mouse-1] 'view-echo-area-messages)

> > But now clicking mouse-1 reports an error.

> It reports an error because it doesn't invoke view-echo-area-messages.

> Alan, this minibuffer-inactive-mode-map thing doesn't seem to work
> with mouse clicks, please take a look.

This has now been fixed with

commit 6e2d3bce087d30a535b1f01715d7820576ffe390
Author: Alan Mackenzie <acm@muc.de>
Date:   Mon May 31 10:33:10 2021 +0000

    Correct mouse handling when window origin changes between down and up events


-- 
Alan Mackenzie (Nuremberg, Germany).