bug#24755: 25.1; Selection continues with no mouse button pressed

bug#24755: 25.1; Selection continues with no mouse button pressed

[Mats Palmgren]

1. Visit a buffer with some text
2. Press the left mouse button
3. Drag the mouse to select some text
4. Press the Control key
5. Release the mouse button
6. Continue to move the mouse

Actual Result:
Moving the mouse continues to select text, even though no mouse button
or keys are pressed.

Expected Result:
Selection should stop at 5.

Unfortunately, it's fairly common for me to do 4 before 5 (in
preparation for deleting the selection with C-w for example) so
version 25 is unusable for me with this bug.  This is a new
behavior in v25, it's not present in v23 or earlier versions
that I've used.

In GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description:	Ubuntu 16.04.1 LTS


Thanks,
Mats

bug#24755: 25.1; Selection continues with no mouse button pressed

[Eli Zaretskii]

> From: Mats Palmgren <matspal@gmail.com>
> Date: Fri, 21 Oct 2016 16:56:00 +0200
> 
> 1. Visit a buffer with some text
> 2. Press the left mouse button
> 3. Drag the mouse to select some text
> 4. Press the Control key
> 5. Release the mouse button
> 6. Continue to move the mouse
> 
> Actual Result:
> Moving the mouse continues to select text, even though no mouse button
> or keys are pressed.
> 
> Expected Result:
> Selection should stop at 5.

Stefan, could you please fix this?  It seems to be due to changes in
how mouse-drag-track handles mouse events: in Emacs 24.5, the code
handled mouse clicks as well, whereas now it doesn't seem to.  So
releasing the mouse button while Ctrl or Shift is pressed signals an
error now, instead of finishing the drag event.

The fix should go to the emacs-25 branch.

Thanks.

bug#24755: 25.1; Selection continues with no mouse button pressed

[Stefan Monnier]

> Stefan, could you please fix this?  It seems to be due to changes in
> how mouse-drag-track handles mouse events: in Emacs 24.5, the code
> handled mouse clicks as well, whereas now it doesn't seem to.  So
> releasing the mouse button while Ctrl or Shift is pressed signals an
> error now, instead of finishing the drag event.

> The fix should go to the emacs-25 branch.

I pushed the patch below to emacs-25, which should fix it.


        Stefan


diff --git a/lisp/subr.el b/lisp/subr.el
index 573f238..07909b8 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4507,8 +4507,10 @@ set-transient-map
                         ;; exit C-u.
                         t)
                        ((eq t keep-pred)
-                        (eq this-command
-                            (lookup-key map (this-command-keys-vector))))
+                        (let ((mc (lookup-key map (this-command-keys-vector))))
+                          ;; If the key is unbound `this-command` is
+                          ;; nil and so is `mc`.
+                          (and mc (eq this-command mc))))
                        (t (funcall keep-pred)))
                 (funcall exitfun)))))
     (add-hook 'pre-command-hook clearfun)

bug#24755: 25.1; Selection continues with no mouse button pressed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Mats Palmgren <matspal@gmail.com>,  24755-done@debbugs.gnu.org
> Date: Wed, 26 Oct 2016 15:29:55 -0400
> 
> > Stefan, could you please fix this?  It seems to be due to changes in
> > how mouse-drag-track handles mouse events: in Emacs 24.5, the code
> > handled mouse clicks as well, whereas now it doesn't seem to.  So
> > releasing the mouse button while Ctrl or Shift is pressed signals an
> > error now, instead of finishing the drag event.
> 
> > The fix should go to the emacs-25 branch.
> 
> I pushed the patch below to emacs-25, which should fix it.

Thanks.  It fixes the original bug, but the resulting behavior is not
identical to Emacs 24.5, because once you release mouse-1, the
selected text loses its highlight.  In Emacs 24.5, the highlight would
stay.

bug#24755: 25.1; Selection continues with no mouse button pressed

[Stefan Monnier]

> Thanks.  It fixes the original bug, but the resulting behavior is not
> identical to Emacs 24.5, because once you release mouse-1, the
> selected text loses its highlight.  In Emacs 24.5, the highlight would
> stay.

That's because C-mouse-1 and C-drag-mouse-1 aren't bound to anything.
It's different, indeed, but the previous behavior was somewhat
accidental, I think (e.g. I'm pretty sure it didn't work that way in all
cases either, since the old code would sometimes push back the events to
be looked up in the global-map, tho not always).

We could try to reproduce it, but I think the necessary code would be
somewhat ugly/hackish.


        Stefan

bug#24755: 25.1; Selection continues with no mouse button pressed

[Mats Palmgren]

On 10/26/2016 09:52 PM, Eli Zaretskii wrote:
> Thanks.  It fixes the original bug, but the resulting behavior is not
> identical to Emacs 24.5, because once you release mouse-1, the
> selected text loses its highlight.

Fwiw, losing the selection in this situation isn't acceptable to me.
I'll certainly stay on emacs < 25 until this is fixed to behave as
it used to.

/Mats

bug#24755: 25.1; Selection continues with no mouse button pressed

[Stefan Monnier]

> Fwiw, losing the selection in this situation isn't acceptable to me.
> I'll certainly stay on emacs < 25 until this is fixed to behave as
> it used to.

Could you explain a bit more of the background for your use-case.
E.g. how/why do you end up pressing `control` on the mouse-release?
E.g. Is it only/always `control` or are there other modifiers
involved sometimes?

As for a workaround, you should be able to get back the old behavior for
that specific case with

    (global-set-key [C-drag-mouse-1] 'mouse-set-region)


        Stefan

bug#24755: 25.1; Selection continues with no mouse button pressed

[Mats Palmgren]

On 10/26/2016 10:27 PM, Stefan Monnier wrote:
>> Fwiw, losing the selection in this situation isn't acceptable to me.
>> I'll certainly stay on emacs < 25 until this is fixed to behave as
>> it used to.
>
> Could you explain a bit more of the background for your use-case.
> E.g. how/why do you end up pressing `control` on the mouse-release?

Sure.  While I'm drag-selecting the region I want, I'm unconsciously
preparing for the operation I intend to do on that region, mostly C-w
to delete it or C-c C-c to comment it out etc, so more often than not
I've already pressed Ctrl before I've finished the selection.  It's
a convenient behavior to not have to time the Ctrl-press exactly, and
it also saves me a fraction of a second to do what I intended. :-)

> E.g. Is it only/always `control` or are there other modifiers
> involved sometimes?

Only Control as far as I'm aware.  I'm on Linux though, so perhaps there
are other modifiers that are frequently used on other platforms, e.g.
OSX (Fn, Option, Cmd) that I'm unaware of.

> As for a workaround, you should be able to get back the old behavior for
> that specific case with
>
>     (global-set-key [C-drag-mouse-1] 'mouse-set-region)

Yes, that seems to work, thanks.


/Mats