bug#34014: 25.2; binding down mouse event with modifier to mouse-drag-region does not work

[Adolf Mathias]

The commit which destroyed the ability to bind a user function
containing mouse-drag-track to arbitrary mouse button press and
modifier combinations seems to be

commit 41f03f4da76827e8611267ee5283a5df8071a617
Author: Glenn Morris <rgm@gnu.org>
Date:   Mon Apr 16 20:04:53 2012 -0400

which replaced the (track-mouse...) with (set-transient-map...)

The transient map that gets established does not catch the
S-drag-mouse1 that I'm after.
I think that this transient map would have to be huge in order to
swallow all motion events with whatever mouse buttons and modifiers
pressed when mouse-drag-track gets invoked by a user command.

The ugly thing about the commit is that it does not say the slightest
why this was rewritten that way.
So, what am I breaking if I restore the functionality with (track-mouse...)  ?

On Sun, Aug 16, 2020 at 10:54 PM Adolf Mathias <adolf.mathias@gmail.com> wrote:
>
> Ah yes, track-mouse is almost  what I need, as I said I wrote my
> replacement for mouse-drag-track, but the double and triple click
> behaviour is tricky in its own right, with all those timeouts and
> motion bounds to keep in mind when pursuing the multiple-click
> hypothesis, and mouse-drag-track did that all perfectly until Emacs
> 25, yada yada yada.... A bit frustrating.
>
> Sorry :) Let's try to come to a constructive conclusion. By the way,
> Emacs is a great piece of software, and I am slightly ashamed that I
> did not contribute to it, given that it is my editor of choice, and
> given the numerous Emacs-Lisp goodies that I  use a lot daily, enabled
> by Stallman's fabulous basic design.
>
> On Sun, Aug 16, 2020 at 7:10 PM Stefan Kangas <stefan@marxist.se> wrote:
> >
> > Adolf Mathias <adolf.mathias@gmail.com> writes:
> >
> > > No, it doesn't. With emacs -Q, mouse-1 then mouse-3 does the same as
> > > simply dragging out a region. Clicking mouse-3 at the same spot, the
> > > region gets killed, otherwise readjusted.
> > > With (setq mouse-drag-copy-region t), the region also gets copied to
> > > the kill ring, otherwise it just disappears.
> > >
> > > Assume the text cursor is at position A. I want the region from B to C
> > > copied to the text cursor position, and then continue editing right
> > > behind the copied text.
> > >
> > > 1. Workflow with mouse-stay-and-copy bound to S-mouse-1:
> > > press S-mouse-1 at B, release mouse-1 at C.
> > >
> > > 2. Workflow with mouse-copy-then-kill and (setq mouse-drag-copy-region t):
> > > click mouse-1 at B, click mouse-3 at C, click mouse-1 at A, hit Ctrl-Y.
> > >
> > > 3. Workflow with standard dragged region:
> > > drag out region from B to C. Hit Ctrl-W. Click mouse-1 at A. Hit Ctrl-Y.
> > >
> > > Workflow 1 saves me one or two mouse clicks and a keystroke and the
> > > navigation back to A. It is that navigation back to A that bothers me
> > > most - the dexterity issue, you know.
> >
> > Thank you for the detailed explanation.
> >
> > Perhaps the easiest would be to expand `mouse-drag-copy-region' et al.
> > to optionally support the behavior you are describing?  I'm sure we
> > would consider a patch to Emacs along those lines.
> >
> > Best regards,
> > Stefan Kangas