GNU bug report logs - #34014
Make mouse-drag-copy-region support immediate yanking at point

Previous Next

To reply to this bug, email your comments to 34014 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; binding down mouse event with modifier to mouse-drag-region
 does not work
Date: Tue, 8 Jan 2019 10:51:19 +0100

======================

From 'emacs -Q' under X11, Ubuntu Bionic Beaver, enter:
M-: (define-key global-map '[S-down-mouse-1] 'mouse-drag-region)

Now attempting to drag a region with held down shift key gives the
error message:

<S-drag-mouse-1> is undefined

Redefining the mouse key without shift modifier, and then dragging,
works as intended:
M-: (define-key global-map '[down-mouse-1] 'mouse-drag-region)

This used to work in Emacs 24 and before.

======================



In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-09-22, modified by Debian built on lgw01-amd64-050
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description:    Ubuntu 18.04.1 LTS

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --build x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-x=yes --with-x-toolkit=gtk3
 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs25-jYekUr/emacs25-25.2+1=.
-fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_CTYPE: en_US.utf8
  value of $LC_MONETARY: de_DE.UTF-8
  value of $LC_NUMERIC: C
  value of $LC_TIME: C
  value of $LANG: C
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
For information about GNU Emacs and the GNU system, type C-h C-a.
gui-get-primary-selection: No selection is available
Mark set
mouse-drag-region
Mark set
mouse-drag-region
Mark set
<S-drag-mouse-1> is undefined
C-c RET is undefined

Load-path shadows:
/usr/share/emacs/25.2/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/cmake-data/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs25/site-lisp/auctex/context-nl hides
/usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs25/site-lisp/auctex/tex hides
/usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs25/site-lisp/auctex/tex-style hides
/usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs25/site-lisp/auctex/latex hides
/usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs25/site-lisp/auctex/tex-font hides
/usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs25/site-lisp/auctex/context-en hides
/usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs25/site-lisp/auctex/tex-ispell hides
/usr/share/emacs/site-lisp/auctex/tex-ispell
/usr/share/emacs25/site-lisp/auctex/font-latex hides
/usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs25/site-lisp/auctex/texmathp hides
/usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs25/site-lisp/auctex/toolbar-x hides
/usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs25/site-lisp/auctex/multi-prompt hides
/usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs25/site-lisp/auctex/context hides
/usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs25/site-lisp/auctex/tex-jp hides
/usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs25/site-lisp/auctex/preview hides
/usr/share/emacs/site-lisp/auctex/preview
/usr/share/emacs25/site-lisp/auctex/prv-emacs hides
/usr/share/emacs/site-lisp/auctex/prv-emacs
/usr/share/emacs25/site-lisp/auctex/tex-info hides
/usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs25/site-lisp/auctex/tex-fold hides
/usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs25/site-lisp/auctex/bib-cite hides
/usr/share/emacs/site-lisp/auctex/bib-cite
/usr/share/emacs25/site-lisp/auctex/tex-mik hides
/usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs25/site-lisp/auctex/tex-buf hides
/usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs25/site-lisp/auctex/tex-bar hides
/usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs25/site-lisp/auctex/plain-tex hides
/usr/share/emacs/site-lisp/auctex/plain-tex

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils preview-latex tex-site
auto-loads time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 91833 8234)
 (symbols 48 20167 0)
 (miscs 40 103 171)
 (strings 32 15355 5105)
 (string-bytes 1 440851)
 (vectors 16 11880)
 (vector-slots 8 434204 5146)
 (floats 8 164 159)
 (intervals 56 301 0)
 (buffers 976 19))

Message #8 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2;
 binding down mouse event with modifier to mouse-drag-region does not
 work
Date: Fri, 01 Mar 2019 10:00:09 +0200

> From: Adolf Mathias <adolf.mathias <at> gmail.com>
> Date: Tue, 8 Jan 2019 10:51:19 +0100
> 
> >From 'emacs -Q' under X11, Ubuntu Bionic Beaver, enter:
> M-: (define-key global-map '[S-down-mouse-1] 'mouse-drag-region)
> 
> Now attempting to drag a region with held down shift key gives the
> error message:
> 
> <S-drag-mouse-1> is undefined
> 
> Redefining the mouse key without shift modifier, and then dragging,
> works as intended:
> M-: (define-key global-map '[down-mouse-1] 'mouse-drag-region)
> 
> This used to work in Emacs 24 and before.

Sorry for such a long delay in responding to your report.

Can you tell why you want to bind S-down-mouse-1 and not
S-drag-mouse-1 to a drag command?

Message #13 received at 34014-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adolf Mathias <adolf.mathias <at> gmail.com>, 34014-done <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Thu, 13 Aug 2020 05:02:12 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Adolf Mathias <adolf.mathias <at> gmail.com>
>> Date: Tue, 8 Jan 2019 10:51:19 +0100
>>
>> >From 'emacs -Q' under X11, Ubuntu Bionic Beaver, enter:
>> M-: (define-key global-map '[S-down-mouse-1] 'mouse-drag-region)
>>
>> Now attempting to drag a region with held down shift key gives the
>> error message:
>>
>> <S-drag-mouse-1> is undefined
>>
>> Redefining the mouse key without shift modifier, and then dragging,
>> works as intended:
>> M-: (define-key global-map '[down-mouse-1] 'mouse-drag-region)
>>
>> This used to work in Emacs 24 and before.
>
> Sorry for such a long delay in responding to your report.
>
> Can you tell why you want to bind S-down-mouse-1 and not
> S-drag-mouse-1 to a drag command?

More information was requested, but none was given within 1.5 years, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas

Message #16 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Fri, 14 Aug 2020 07:29:39 -0700

reopen 34014
thanks

Hi Adolf,

[Please use "Reply to all" so that the discussion is recorded in the bug
tracker.]

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

> Sorry for the apparent delay. I myself got a bit frustrated with the
> issue and rewrote a simple version  of mouse-drag-region for myself
> which does not deal with double/triple-clicks acting on words and
> lines however. I was not able to disentangle what Emacs does there.
> I somehow was convinced that I had answered back then why I wanted to
> bind mouse-drag-region to a button-down event.
> I did so because the Emacs help on mouse-drag-region told me so, and
> because it used to work that way.

Thanks for replying back.  I am therefore reopening this bug.
With your help, we could try to figure out what is going on here.

Does it work like you expect if you evaluate this in emacs -Q?

  (define-key global-map '[S-down-mouse-1] 'mouse-drag-region)
  (define-key global-map '[S-drag-mouse-1] 'mouse-set-region)

If that does not help, could you please try to describe the use-case in
more detail and explain what it is you're trying to achieve?

Thanks in advance.

Best regards,
Stefan Kangas

Message #21 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Fri, 14 Aug 2020 20:58:41 +0200

Yes, your two expressions works on emacs-27.1 which I just installed
with snap on an Ubuntu 18.04, dragging S-mouse1 sets the region  like
mouse-1.

The thing is, on Emacs24 and before I had the following working code:

==========================
(defun mouse-stay-and-copy (click)
  "leaves cursor at current position, allows to drag a region which is
yanked at cursor position"
  (interactive "e")
  (let ((selected nil)
    (win (selected-window))
        (otherwin nil)
        (otherstart nil)
        (eventstart nil))
    (save-excursion
      (setq eventstart (event-start click))
      (setq otherwin (car eventstart))
      (setq otherstart (window-start otherwin))
      (mouse-drag-track click)
      (if mark-active
      (progn (kill-new (buffer-substring (region-beginning) (region-end)))
         (setq selected 1)
                 )))
    (select-window win)
    (if selected
    (progn
      (if mark-active (delete-region (region-beginning) (region-end)))
      (yank)
      ;;(redraw-display)
          ))
    (set-window-start otherwin otherstart nil)))

 (define-key global-map '[S-down-mouse-1] 'mouse-stay-and-copy)
==========================

On Emacs Post 24, this stopped to work. When I filed the bug report, I
reduced this to a builtin Emacs function.

On Emacs 24, to bind Shift-mouse1, only the following call is required:
(define-key global-map '[S-down-mouse-1] 'mouse-drag-region)

My mouse-stay-and-copy is just a fancy replacement for
mouse-drag-region. Sadly, its API in conjunction with mouse-drag-track
has changed mysteriously with post-24.



On Fri, Aug 14, 2020 at 4:29 PM Stefan Kangas <stefan <at> marxist.se> wrote:
>
> reopen 34014
> thanks
>
> Hi Adolf,
>
> [Please use "Reply to all" so that the discussion is recorded in the bug
> tracker.]
>
> Adolf Mathias <adolf.mathias <at> gmail.com> writes:
>
> > Sorry for the apparent delay. I myself got a bit frustrated with the
> > issue and rewrote a simple version  of mouse-drag-region for myself
> > which does not deal with double/triple-clicks acting on words and
> > lines however. I was not able to disentangle what Emacs does there.
> > I somehow was convinced that I had answered back then why I wanted to
> > bind mouse-drag-region to a button-down event.
> > I did so because the Emacs help on mouse-drag-region told me so, and
> > because it used to work that way.
>
> Thanks for replying back.  I am therefore reopening this bug.
> With your help, we could try to figure out what is going on here.
>
> Does it work like you expect if you evaluate this in emacs -Q?
>
>   (define-key global-map '[S-down-mouse-1] 'mouse-drag-region)
>   (define-key global-map '[S-drag-mouse-1] 'mouse-set-region)
>
> If that does not help, could you please try to describe the use-case in
> more detail and explain what it is you're trying to achieve?
>
> Thanks in advance.
>
> Best regards,
> Stefan Kangas

Message #24 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Fri, 14 Aug 2020 19:20:09 -0700

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

> On Emacs Post 24, this stopped to work.

Could you also explain what exactly your code is supposed to be doing?

And did you try the following?

(define-key global-map '[S-down-mouse-1] 'mouse-stay-and-copy)
(define-key global-map '[S-drag-mouse-1] 'mouse-set-region)

Best regards,
Stefan Kangas

Message #29 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sat, 15 Aug 2020 13:53:47 +0200

Sorry, I always had the impression that the comment of
mouse-stay-ad-copy was explicit enough - also, when I was in
conversation with the previous guy who processed this bug report, I
explained it to him, and most certainly didn't reply to all, and that
person did not mention this to me as you did. Anyway...

The function allows a workflow that I know from the SunOS Textedit
from the late 1980s. Your cursor is somewhere in the text, you drag
out a region in the same window/buffer or another one, and the text
that you selected gets copied to your cursor at mouse button release,
without having to reposition your cursor.

Without it, the normal workflow is: you remember where your cursor is,
select a region and either use middle button to paste at the
remembered position, given that you are dexterous enough to hit the
right spot (which, as you can tell from my experiences with SunOS, is
not so much the case any more), or hit Ctrl-C or Alt-W, then position
the cursor at the remembered position and hit Ctrl-Y or Ctrl-V.

mouse-stay-and-copy accelerates a very frequent operation and saves
the user from having to remember the original inserting position and
being dexterous enough to hit it again,  or having to use the Emacs
mark stack that I personally find rather unintuitive.

Along with mouse-stay-and-copy, I also have mouse-stay-and-kill, which
kills the temporarily dragged out region and moves it to the original
cursor position, and mouse-stay-and-swap, which, given a currently
selected region, allows to drag out that temporary selection whose
content is then swapped with the original selection. That one saves a
lot of work in certain cases, once you are used to it. I used to bind
it to C-M-button1.

On Sat, Aug 15, 2020 at 4:20 AM Stefan Kangas <stefan <at> marxist.se> wrote:
>
> Adolf Mathias <adolf.mathias <at> gmail.com> writes:
>
> > On Emacs Post 24, this stopped to work.
>
> Could you also explain what exactly your code is supposed to be doing?
>
> And did you try the following?
>
> (define-key global-map '[S-down-mouse-1] 'mouse-stay-and-copy)
> (define-key global-map '[S-drag-mouse-1] 'mouse-set-region)
>
> Best regards,
> Stefan Kangas

Message #32 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sat, 15 Aug 2020 14:07:21 +0200

No, this does not work - it kills between the original mouse position
and the position where the S-mouse1 went down.

Funny is, it works on Emacs24 - probably because the mouse-drag-track
in mouse-stay-and-copy  keeps the S-drag-mouse-1 binding from
receiving events.

It seems that mouse-drag-track is broken, what concerns my
expectations to it. And it can be reimplemented, as I mentioned before
that I did - I just did not bother to reimplement the multiple-click
logic that is part of it.

On Sat, Aug 15, 2020 at 4:20 AM Stefan Kangas <stefan <at> marxist.se> wrote:
>
> Adolf Mathias <adolf.mathias <at> gmail.com> writes:
>
> > On Emacs Post 24, this stopped to work.
>
> Could you also explain what exactly your code is supposed to be doing?
>
> And did you try the following?
>
> (define-key global-map '[S-down-mouse-1] 'mouse-stay-and-copy)
> (define-key global-map '[S-drag-mouse-1] 'mouse-set-region)
>
> Best regards,
> Stefan Kangas

Message #35 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sun, 16 Aug 2020 07:34:00 -0700

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

> The function allows a workflow that I know from the SunOS Textedit
> from the late 1980s. Your cursor is somewhere in the text, you drag
> out a region in the same window/buffer or another one, and the text
> that you selected gets copied to your cursor at mouse button release,
> without having to reposition your cursor.

Does the following cover your use case?

  (setq mouse-drag-copy-region t)

Alternatively:

   M-x customize-option RET mouse-drag-copy-region RET

Best regards,
Stefan Kangas

Message #38 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sun, 16 Aug 2020 18:20:07 +0200

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.


On Sun, Aug 16, 2020 at 4:34 PM Stefan Kangas <stefan <at> marxist.se> wrote:
>
> Adolf Mathias <adolf.mathias <at> gmail.com> writes:
>
> > The function allows a workflow that I know from the SunOS Textedit
> > from the late 1980s. Your cursor is somewhere in the text, you drag
> > out a region in the same window/buffer or another one, and the text
> > that you selected gets copied to your cursor at mouse button release,
> > without having to reposition your cursor.
>
> Does the following cover your use case?
>
>   (setq mouse-drag-copy-region t)
>
> Alternatively:
>
>    M-x customize-option RET mouse-drag-copy-region RET
>
> Best regards,
> Stefan Kangas

Message #41 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sun, 16 Aug 2020 10:10:49 -0700

Adolf Mathias <adolf.mathias <at> 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

Message #44 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Sun, 16 Aug 2020 22:54:37 +0200

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 <at> marxist.se> wrote:
>
> Adolf Mathias <adolf.mathias <at> 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

Message #47 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: 34014 <at> debbugs.gnu.org
Date: Sun, 16 Aug 2020 23:00:33 +0200

Well, mouse-drag-track is a local event loop that I start within my
mouse-stay-and-copy and that finishes upon mouse button release. And
with Emacs post 24, it suddenly isn't any more, because Emacs suddenly
starts complaining about S-drag-mouse events not bound to anything. My
desired patch to Emacs would be to let mouse-drag-track really be that
all-absorbing event loop until, within reasonable bounds, the next
button release.

Message #50 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Mon, 17 Aug 2020 14:27:44 +0000

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

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

It's never too late.  Working on adding a feature you yourself want is
actually a great way to start.  :-)

To extend 'mouse-drag-copy-region' to also support working like you
suggest would be a useful contribution, in my opinion.  In addition to
nil and t, perhaps we could add a new symbol (e.g. 'at-point) which
would mean that the text should immediately be yanked at point.

In any case, we could leave this open as a wishlist level request, I
think.

Best regards,
Stefan Kangas

PS. Note that any contribution longer than 15 lines would also require a
    copyright assignment as described here:
        https://www.gnu.org/licenses/why-assign.html

Message #53 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Tue, 18 Aug 2020 13:26:53 +0000

[Resending to include the Emacs bug tracker address.
 Please remember to use "Reply to all".]

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

> OK,  ready to do something for the community.

I'm looking forward to see what you come up with.

> However, I currently do not know what you mean with
> mouse-drag-copy-region.

mouse-drag-copy-region is a variable defined in ‘mouse.el’.  You should
be able to find it using `C-h v mouse-drag-copy-region'.

> Do you mean my mouse-stay-and-copy? Or do you mean mouse-drag-region,
> which is bound to drag-mouse-1?

> And I am still curious why mouse-drag-track has stopped working the
> way I expect it to.

There were many changes in the relevant code between Emacs 23 and 24.
I had a cursory look but could not find any immediately suspect commits.
If you have cloned the Emacs git repository, you could use the following
command, and see if you have better luck than me:

   git log emacs-23.1..emacs-24.1 lisp/mouse.el

Best regards,
Stefan Kangas

Message #62 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Adolf Mathias <adolf.mathias <at> gmail.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Tue, 18 Aug 2020 17:07:53 +0200

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 <at> 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 <at> 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 <at> marxist.se> wrote:
> >
> > Adolf Mathias <adolf.mathias <at> 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

Message #65 received at 34014 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Adolf Mathias <adolf.mathias <at> gmail.com>
Cc: 34014 <at> debbugs.gnu.org
Subject: Re: bug#34014: 25.2; binding down mouse event with modifier to
 mouse-drag-region does not work
Date: Tue, 18 Aug 2020 15:32:19 +0000

Adolf Mathias <adolf.mathias <at> gmail.com> writes:

> 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 <at> gnu.org>
> Date:   Mon Apr 16 20:04:53 2012 -0400
>
> which replaced the (track-mouse...) with (set-transient-map...)

I don't see anything about set-transient-map in commit 41f03f4da7.

Best regards,
Stefan Kangas

Previous Next

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