GNU bug report logs -
#13884
24.3.50; `mouse-secondary-save-then-kill' should not affect the kill ring (+ regression)
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Tue, 5 Mar 2013 23:21:03 UTC
Severity: normal
Tags: notabug
Found in version 24.3.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13884 in the body.
You can then email your comments to 13884 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13884
; Package
emacs
.
(Tue, 05 Mar 2013 23:21:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 05 Mar 2013 23:21:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Prior to Emacs 24, if you clicked `M-mouse-3' without first clicking
`M-mouse-1' you got a "Wrong buffer" error msg informing you that the
secondary selection was not in this buffer. That was consistent and
reasonable behavior.
Starting with Emacs 24, if you do that Emacs moves the secondary
selection to the current buffer, from point to the clicked position.
1. It could be argued that this is a regression, especially as:
a. This user-visible behavior change is not noted in the NEWS, AFAICT.
b. Point has nothing to do with the secondary selection, whereas it is
always at one end of the region.
c. Now the user is no longer informed that s?he is in the wrong buffer.
I.e., s?he is not told that there is no secondary selection in the
current buffer. If s?he has already defined the secondary selection
in a different buffer, and, e.g., s?he thinks s?he is in that buffer,
s?he will lose that selection and instead re-create the secondary
selection in the current buffer.
This change in behavior is arguably a bad thing, not a good thing.
2. Be that as it may, if this behavior is to remain, there is
nevertheless the following bug, the main purpose of this report: In this
case (no start of secondary selection in current buffer, so using point
as the start position), the code mistakenly does this, in addition to
doing what it needs to do to establish the secondary selection:
(kill-ring-save (point) click-pt)
That code is a vestige, presumably. In any case, it has no business
being there. Setting the secondary selection should not in any way
affect the `kill-ring'. The secondary selection is entirely separate
from the region and the kill ring. This sexp should be removed.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-02-25 on ODIEONE
Bzr revision: 111879 yamaoka <at> jpl.org-20130225224731-cv9gznq5nqf3ei7g
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#13884
; Package
emacs
.
(Sun, 06 Dec 2020 19:05:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 13884 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> Prior to Emacs 24, if you clicked `M-mouse-3' without first clicking
> `M-mouse-1' you got a "Wrong buffer" error msg informing you that the
> secondary selection was not in this buffer. That was consistent and
> reasonable behavior.
>
> Starting with Emacs 24, if you do that Emacs moves the secondary
> selection to the current buffer, from point to the clicked position.
>
> 1. It could be argued that this is a regression, especially as:
(I think it's too late to change how this works at this point.)
> 2. Be that as it may, if this behavior is to remain, there is
> nevertheless the following bug, the main purpose of this report: In this
> case (no start of secondary selection in current buffer, so using point
> as the start position), the code mistakenly does this, in addition to
> doing what it needs to do to establish the secondary selection:
>
> (kill-ring-save (point) click-pt)
>
> That code is a vestige, presumably. In any case, it has no business
> being there. Setting the secondary selection should not in any way
> affect the `kill-ring'. The secondary selection is entirely separate
> from the region and the kill ring. This sexp should be removed.
The doc string says:
----
Set the secondary selection and save it to the kill ring.
----
So this is presumably intended behaviour. Closing.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 06 Dec 2020 19:05:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
13884 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 06 Dec 2020 19:05:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 04 Jan 2021 12:24:14 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 170 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.