bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[David Ponce]

Hello,

I noticed that now, when cua-mode is enabled, when I select a region
(with mouse or keyboard), then use mouse-2 click on another point to
insert the selected text, the active region is cut before to insert text
at the mouse-2 click for the first time. As far as I remember this is a
new behavior, and previously the selected region was not cut, but
copied, like when cua-mode is disabled.

The woraround is to first deselect the region before to click mouse-2 to
insert the previously selected text. This way the initially selected 
text is not cut.

Not sure this is expected, so this bug report ;-)

Thanks

In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 
3.24.34, cairo version 1.17.6)
  of 2022-07-13 built on kilauea
Repository revision: c679756a9fb3ebd9a9b5fa9c9c64641fe493e8d8
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (KDE Plasma)

Configured using:
  'configure --prefix=/home/dponce --with-cairo --without-sqlite3
  PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
   value of $LC_TIME: fr_FR.utf8
   value of $LANG: fr_FR.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
   delete-selection-mode: t
   cua-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   show-paren-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
   line-number-mode: t
   indent-tabs-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib cus-start cus-load delsel cua-base rmc iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine 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 composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 48650 11785)
  (symbols 48 6173 0)
  (strings 32 15421 2063)
  (string-bytes 1 472483)
  (vectors 16 9531)
  (vector-slots 8 149129 13107)
  (floats 8 35 33)
  (intervals 56 222 0)
  (buffers 992 10))

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Visuwesh]

[Wednesday July 13, 2022] David Ponce wrote:

> Hello,
>
> I noticed that now, when cua-mode is enabled, when I select a region
> (with mouse or keyboard), then use mouse-2 click on another point to
> insert the selected text, the active region is cut before to insert text
> at the mouse-2 click for the first time. As far as I remember this is a
> new behavior, and previously the selected region was not cut, but
> copied, like when cua-mode is disabled.
>
> The woraround is to first deselect the region before to click mouse-2 to
> insert the previously selected text. This way the initially selected
> text is not cut.
>
> Not sure this is expected, so this bug report ;-)

It is expected.  mouse-2 (and other mouse yank commands) were recently
changed to respect delete-selection-mode (which is enabled by cua-mode)
by yours truly.  :-)

You can disable the new behaviour by saying,

    (put 'mouse-yank-primary 'delete-selection nil)
    (put 'mouse-yank-secondary 'delete-selection nil)
    (put 'mouse-yank-at-click 'delete-selection nil)

But I guess, it sure didn't take long for the complaints to come in...

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Visuwesh <visuweshm@gmail.com> writes:

> It is expected.  mouse-2 (and other mouse yank commands) were recently
> changed to respect delete-selection-mode (which is enabled by cua-mode)
> by yours truly.  :-)

That wasn't really the intention of the change, I think?  It was so that
if you paste text from a different program into a selected area in
Emacs, then that area would be deleted first, or do I misremember?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Visuwesh]

[Wednesday July 13, 2022] Lars Ingebrigtsen wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>> It is expected.  mouse-2 (and other mouse yank commands) were recently
>> changed to respect delete-selection-mode (which is enabled by cua-mode)
>> by yours truly.  :-)
>
> That wasn't really the intention of the change, I think?  It was so that
> if you paste text from a different program into a selected area in
> Emacs, then that area would be deleted first, or do I misremember?

AFAICT, the recipe produces what I had in my mind when I proposed.  The
behaviour might seems slightly odd since mouse-yank-at-point is set to
nil in OP's case.  It shouldn't be hard to take this defcustom into
account tho.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Visuwesh <visuweshm@gmail.com> writes:

> AFAICT, the recipe produces what I had in my mind when I proposed.  The
> behaviour might seems slightly odd since mouse-yank-at-point is set to
> nil in OP's case.  It shouldn't be hard to take this defcustom into
> account tho.

I think the patch has to be reverted, because this isn't what I had in
mind at all.  But we can reintroduce the same effect via, for instance,
a new minor mode that has the same effect (for those that want this).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Visuwesh]

[Wednesday July 13, 2022] Lars Ingebrigtsen wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>> AFAICT, the recipe produces what I had in my mind when I proposed.  The
>> behaviour might seems slightly odd since mouse-yank-at-point is set to
>> nil in OP's case.  It shouldn't be hard to take this defcustom into
>> account tho.
>
> I think the patch has to be reverted, because this isn't what I had in
> mind at all.  But we can reintroduce the same effect via, for instance,
> a new minor mode that has the same effect (for those that want this).

Fine by me.  But I'm not sure how many people want this (I count two so
far), so we can just let the users who desire this behaviour add a few
lines to their init.el.  Or how about the snippet in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56530#26 look to you?

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Visuwesh <visuweshm@gmail.com> writes:

>> I think the patch has to be reverted, because this isn't what I had in
>> mind at all.  But we can reintroduce the same effect via, for instance,
>> a new minor mode that has the same effect (for those that want this).
>
> Fine by me.  But I'm not sure how many people want this (I count two so
> far), so we can just let the users who desire this behaviour add a few
> lines to their init.el.

I've now reverted the commit and reopened that other bug report.

> Or how about the snippet in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56530#26 look to you?

I think having an explicit minor mode for this would be tidier.  It
would be trivial -- it'd just `put' on those symbols.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Stefan Kangas]

Visuwesh <visuweshm@gmail.com> writes:

> AFAICT, the recipe produces what I had in my mind when I proposed.  The
> behaviour might seems slightly odd since mouse-yank-at-point is set to
> nil in OP's case.  It shouldn't be hard to take this defcustom into
> account tho.

I think that neither Emacs nor `cua-mode' should behave differently from
other X programs in this regard, certainly not by default.  Could we
please avoid that?  The entire point of `cua-mode' is to be /more/ like
other software, not less.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Visuwesh]

[Wednesday July 13, 2022] Stefan Kangas wrote:

> Visuwesh <visuweshm@gmail.com> writes:
>
>> AFAICT, the recipe produces what I had in my mind when I proposed.  The
>> behaviour might seems slightly odd since mouse-yank-at-point is set to
>> nil in OP's case.  It shouldn't be hard to take this defcustom into
>> account tho.
>
> I think that neither Emacs nor `cua-mode' should behave differently from
> other X programs in this regard, certainly not by default.  Could we
> please avoid that?  The entire point of `cua-mode' is to be /more/ like
> other software, not less.

Like I said in the original bug report, I have no problems if the change
was reverted.  I would do it myself but I have no push access.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

>> AFAICT, the recipe produces what I had in my mind when I proposed.  The
>> behaviour might seems slightly odd since mouse-yank-at-point is set to
>> nil in OP's case.  It shouldn't be hard to take this defcustom into
>> account tho.
>
> I think that neither Emacs nor `cua-mode' should behave differently from
> other X programs in this regard, certainly not by default.  Could we
> please avoid that?  The entire point of `cua-mode' is to be /more/ like
> other software, not less.

I'd like to know what programs do you mean.  In every program I see
the same behavior:

1. Select a region
2. Choose "Copy" from the context menu
3. Select another region
4. Choose "Paste" on the region from the context menu

It always deletes the region before pasting the text from the clipboard.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

>> That wasn't really the intention of the change, I think?  It was so that
>> if you paste text from a different program into a selected area in
>> Emacs, then that area would be deleted first, or do I misremember?
>
> AFAICT, the recipe produces what I had in my mind when I proposed.  The
> behaviour might seems slightly odd since mouse-yank-at-point is set to
> nil in OP's case.  It shouldn't be hard to take this defcustom into
> account tho.

It should delete the region only when clicking on the selected region.
Maybe it's possible to add a corresponding function for the
'delete-selection' property?

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> It should delete the region only when clicking on the selected region.
> Maybe it's possible to add a corresponding function for the
> 'delete-selection' property?

Shouldn't be too difficult, but it seems like different people have
different expectations of what should happen here, so I think having
separate minor modes (or some user options) is probably the way to go.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

>> It should delete the region only when clicking on the selected region.
>> Maybe it's possible to add a corresponding function for the
>> 'delete-selection' property?
>
> Shouldn't be too difficult, but it seems like different people have
> different expectations of what should happen here, so I think having
> separate minor modes (or some user options) is probably the way to go.

There is already the minor mode: delete-selection-mode
that is configured by symbol properties.
Supporting a descriptive symbol name would allow to easily
configure the desired behavior with just:

  (put 'mouse-yank-at-click 'delete-selection 'yank-on-region)

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> There is already the minor mode: delete-selection-mode
> that is configured by symbol properties.
> Supporting a descriptive symbol name would allow to easily
> configure the desired behavior with just:
>
>   (put 'mouse-yank-at-click 'delete-selection 'yank-on-region)

The problem is that you have to `put' on three symbols, which isn't
optimal.  (My proposed mode does just that.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

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

>> There is already the minor mode: delete-selection-mode
>> that is configured by symbol properties.
>> Supporting a descriptive symbol name would allow to easily
>> configure the desired behavior with just:
>>
>>   (put 'mouse-yank-at-click 'delete-selection 'yank-on-region)
>
> The problem is that you have to `put' on three symbols, which isn't
> optimal.  (My proposed mode does just that.)

The default settings should be suitable for all users,
but modes for groups of settings could be added too.

This patch works well but only like Visuwesh pointed out
when mouse-yank-at-point is set to t.  This is because
mouse-yank-primary has such line:

  (or mouse-yank-at-point (mouse-set-point event))

When delete-selection deletes the region where the mouse is clicked,
mouse-set-point loses track and sets point to a random position,
because the event contains fixed positions, not markers.
I wonder why?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: yank-on-region.patch --]
[-- Type: text/x-diff, Size: 2150 bytes --]

diff --git a/lisp/delsel.el b/lisp/delsel.el
index 5310328e5f..d9e0141d90 100644
--- a/lisp/delsel.el
+++ b/lisp/delsel.el
@@ -39,6 +39,8 @@
 ;;      For commands which do a yank; ensures the region about to be
 ;;      deleted isn't immediately yanked back, which would make the
 ;;      command a no-op.
+;;  `yank-on-region'
+;;      Like `yank' but applied only when clicked on the region.
 ;;  `supersede'
 ;;      Delete the active region and ignore the current command,
 ;;      i.e. the command will just delete the region.  This is for
@@ -176,6 +178,8 @@ delete-selection-helper
      For commands which do a yank; ensures the region about to be
      deleted isn't immediately yanked back, which would make the
      command a no-op.
+ `yank-on-region'
+     Like `yank' but applied only when clicked on the region.
  `supersede'
      Delete the active region and ignore the current command,
      i.e. the command will just delete the region.  This is for
@@ -220,6 +224,11 @@ delete-selection-helper
                ;; If the region was, say, rectangular, make sure we yank
                ;; from the top, to "replace".
                (goto-char pos)))
+            ((eq type 'yank-on-region)
+             (let ((pos (posn-point (event-end last-nonmenu-event))))
+               (when (and (>= pos (region-beginning))
+                          (<= pos (region-end)))
+                 (delete-selection-helper 'yank))))
 	    ((eq type 'supersede)
 	     (let ((empty-region (= (point) (mark))))
 	       (delete-active-region)
@@ -300,6 +309,12 @@ delete-selection-uses-region-p
 (put 'yank-pop 'delete-selection 'yank)
 (put 'yank-from-kill-ring 'delete-selection 'yank)
 (put 'clipboard-yank 'delete-selection 'yank)
+
+(put 'mouse-yank-primary 'delete-selection 'yank-on-region)
+(put 'mouse-yank-secondary 'delete-selection 'yank-on-region)
+(put 'mouse-yank-at-click 'delete-selection 'yank-on-region)
+(put 'menu-bar-select-yank 'delete-selection 'yank-on-region)
+
 (put 'insert-register 'delete-selection t)
 ;; delete-backward-char and delete-forward-char already delete the selection by
 ;; default, but not delete-char.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This patch works well

Looks good to me.

> but only like Visuwesh pointed out
> when mouse-yank-at-point is set to t.  This is because
> mouse-yank-primary has such line:
>
>   (or mouse-yank-at-point (mouse-set-point event))
>
> When delete-selection deletes the region where the mouse is clicked,
> mouse-set-point loses track and sets point to a random position,
> because the event contains fixed positions, not markers.
> I wonder why?

Sounds like a bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

>> but only like Visuwesh pointed out
>> when mouse-yank-at-point is set to t.  This is because
>> mouse-yank-primary has such line:
>>
>>   (or mouse-yank-at-point (mouse-set-point event))
>>
>> When delete-selection deletes the region where the mouse is clicked,
>> mouse-set-point loses track and sets point to a random position,
>> because the event contains fixed positions, not markers.
>> I wonder why?
>
> Sounds like a bug.

All affected mouse commands mouse-yank-from-menu, mouse-yank-at-click,
mouse-yank-primary, mouse-yank-secondary have the same line:

  (or mouse-yank-at-point (mouse-set-point event))

So when the region is deleted by delete-selection-pre-hook
`mouse-set-point' tries to set point using outdated information
of the event's position in the deleted region.

Maybe delete-selection-pre-hook could directly modify the event?
Everything works fine with this:

            ((eq type 'yank-on-region)
             (let ((pos (posn-point (event-end last-nonmenu-event))))
               (when (and (>= pos (region-beginning))
                          (<= pos (region-end)))
                 (delete-selection-helper 'yank)
                 (setf (nth 5 (nth 1 last-nonmenu-event)) (region-beginning)))))

But is this a good idea?

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> All affected mouse commands mouse-yank-from-menu, mouse-yank-at-click,
> mouse-yank-primary, mouse-yank-secondary have the same line:
>
>   (or mouse-yank-at-point (mouse-set-point event))
>
> So when the region is deleted by delete-selection-pre-hook
> `mouse-set-point' tries to set point using outdated information
> of the event's position in the deleted region.
>
> Maybe delete-selection-pre-hook could directly modify the event?
> Everything works fine with this:
>
>             ((eq type 'yank-on-region)
>              (let ((pos (posn-point (event-end last-nonmenu-event))))
>                (when (and (>= pos (region-beginning))
>                           (<= pos (region-end)))
>                  (delete-selection-helper 'yank)
>                  (setf (nth 5 (nth 1 last-nonmenu-event)) (region-beginning)))))
>
> But is this a good idea?

It sounds kinda gross.  Would it be possible to rewrite these commands
to that point is set before the deletion is done, or is that unfeasible?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Juri Linkov]

>> All affected mouse commands mouse-yank-from-menu, mouse-yank-at-click,
>> mouse-yank-primary, mouse-yank-secondary have the same line:
>>
>>   (or mouse-yank-at-point (mouse-set-point event))
>>
>> So when the region is deleted by delete-selection-pre-hook
>> `mouse-set-point' tries to set point using outdated information
>> of the event's position in the deleted region.
>>
>> Maybe delete-selection-pre-hook could directly modify the event?
>> Everything works fine with this:
>>
>>             ((eq type 'yank-on-region)
>>              (let ((pos (posn-point (event-end last-nonmenu-event))))
>>                (when (and (>= pos (region-beginning))
>>                           (<= pos (region-end)))
>>                  (delete-selection-helper 'yank)
>>                  (setf (nth 5 (nth 1 last-nonmenu-event)) (region-beginning)))))
>>
>> But is this a good idea?
>
> It sounds kinda gross.  Would it be possible to rewrite these commands
> to that point is set before the deletion is done, or is that unfeasible?

delete-selection-mode deletes the region in pre-command-hook
before running the command.

Maybe then these commands could have special handling of delete-selection-mode?
They already contain special handling of select-active-regions:

  ;; Without this, confusing things happen upon e.g. inserting into
  ;; the middle of an active region.
  (when select-active-regions
    (let (select-active-regions)
      (deactivate-mark)))

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> delete-selection-mode deletes the region in pre-command-hook
> before running the command.
>
> Maybe then these commands could have special handling of delete-selection-mode?
> They already contain special handling of select-active-regions:
>
>   ;; Without this, confusing things happen upon e.g. inserting into
>   ;; the middle of an active region.
>   (when select-active-regions
>     (let (select-active-regions)
>       (deactivate-mark)))

Yes, I think that sounds like the way to go.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[David Ponce]

On 13/07/2022 11:50, Visuwesh wrote:
> [Wednesday July 13, 2022] David Ponce wrote:
> 
>> Hello,
>>
>> I noticed that now, when cua-mode is enabled, when I select a region
>> (with mouse or keyboard), then use mouse-2 click on another point to
>> insert the selected text, the active region is cut before to insert text
>> at the mouse-2 click for the first time. As far as I remember this is a
>> new behavior, and previously the selected region was not cut, but
>> copied, like when cua-mode is disabled.
>>
>> The woraround is to first deselect the region before to click mouse-2 to
>> insert the previously selected text. This way the initially selected
>> text is not cut.
>>
>> Not sure this is expected, so this bug report ;-)
> 
> It is expected.  mouse-2 (and other mouse yank commands) were recently
> changed to respect delete-selection-mode (which is enabled by cua-mode)
> by yours truly.  :-)
> 
> You can disable the new behaviour by saying,
> 
>      (put 'mouse-yank-primary 'delete-selection nil)
>      (put 'mouse-yank-secondary 'delete-selection nil)
>      (put 'mouse-yank-at-click 'delete-selection nil)
> 
> But I guess, it sure didn't take long for the complaints to come in
Maybe the behavior could be disabled for cua-mode to be consistent with 
CUA expected behavior? After all, cua-mode is more than just 
delete-selection-mode ;-)

Thanks
[resent, forgot to CC the bug list]

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Visuwesh]

[Wednesday July 13, 2022] David Ponce wrote:

> On 13/07/2022 11:50, Visuwesh wrote:
>> You can disable the new behaviour by saying,
>>      (put 'mouse-yank-primary 'delete-selection nil)
>>      (put 'mouse-yank-secondary 'delete-selection nil)
>>      (put 'mouse-yank-at-click 'delete-selection nil)
>> But I guess, it sure didn't take long for the complaints to come in
> Maybe the behavior could be disabled for cua-mode to be consistent
> with CUA expected behavior? After all, cua-mode is more than just
> delete-selection-mode ;-)
>
> Thanks
> [resent, forgot to CC the bug list]

Thankfully delete-selection-mode is sufficiently flexible to allow this.
We just need to replace the (put 'mouse-yank-primary 'delete-selection t)
in delsel.el with the following,

    (put 'mouse-yank-primary 'delete-selection
        (lambda ()
          (if (or cua-mode (null mouse-yank-at-point))
               nil
             'yank)))

[ Disclaimer: I didn't test it.  ]

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Visuwesh <visuweshm@gmail.com> writes:

> It is expected.  mouse-2 (and other mouse yank commands) were recently
> changed to respect delete-selection-mode (which is enabled by cua-mode)
> by yours truly.  :-)

This is very much wrong: programs should never set the clipboard to the
contents of the primary selection upon a middle-click paste.  That makes
inserting the clipboard impossible later on.

bug#56530: 29.0.50; mouse-2 cut selected text when cua-mode is enabled

[Stefan Kangas]

David Ponce <da_vid@orange.fr> writes:

> I noticed that now, when cua-mode is enabled, when I select a region
> (with mouse or keyboard), then use mouse-2 click on another point to
> insert the selected text, the active region is cut before to insert text
> at the mouse-2 click for the first time. As far as I remember this is a
> new behavior, and previously the selected region was not cut, but
> copied, like when cua-mode is disabled.
>
> The woraround is to first deselect the region before to click mouse-2 to
> insert the previously selected text. This way the initially selected
> text is not cut.

I can reproduce this on current master, but not on Emacs 27.

I think it's a bug.