From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse Date: Wed, 19 Sep 2018 11:24:50 -0700 (PDT) Message-ID: <01b0f0c4-e3b8-440f-a739-5995ca4ff615@default> References: <<>> <<<83tvmlew2a.fsf@gnu.org>>> <<932a1915-c043-4708-9f16-dc0ee8fafdb3@default>> <<83pnx9een5.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1537381452 11848 195.159.176.226 (19 Sep 2018 18:24:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2018 18:24:12 +0000 (UTC) Cc: 32747@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 19 20:24:08 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2h8x-0002wz-Lh for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2018 20:24:07 +0200 Original-Received: from localhost ([::1]:46717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2hB4-0005vK-BR for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2018 14:26:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2hAx-0005vA-KU for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2018 14:26:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2hAo-00029D-NP for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2018 14:26:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41707) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g2hAn-00027R-PS for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2018 14:26:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g2hAn-0003VE-O5 for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2018 14:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2018 18:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32747 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32747-submit@debbugs.gnu.org id=B32747.153738150213367 (code B ref 32747); Wed, 19 Sep 2018 18:26:01 +0000 Original-Received: (at 32747) by debbugs.gnu.org; 19 Sep 2018 18:25:02 +0000 Original-Received: from localhost ([127.0.0.1]:45965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2h9p-0003TN-MZ for submit@debbugs.gnu.org; Wed, 19 Sep 2018 14:25:02 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:49476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2h9m-0003Ss-TM for 32747@debbugs.gnu.org; Wed, 19 Sep 2018 14:25:00 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8JIO24e017687; Wed, 19 Sep 2018 18:24:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=3+oAlPtliF0hzOsRSIK4uufURyIvRrnxfOtMEuck9Yk=; b=hh6T4sjLYJvxnIumsvqK9bQu6vIeZ5QLgctM7QCN/mn7qY99wUWOT11nkUn9DoQaH07H C/86EbNr0TZBm+6mvg2/bEioVZxRA7+liC/0pNg603uu3O5yZNJBEWLcHPEGUMOtqlVb W+kCD8EqKxt4FElYDAY5edKYxf30MjH4t/e0hcbIdUBaPrAbF4FpTzcrlgXvnz2rAWKo GWwaetvJE1cYHJMzWJNP0OSSISTAy3f0e2TVwyDJ/a0wXcGqJD/8lsDCMcngHtrxP7iW a5XRqpMvmru8TyFvqKxJ3qz8qCC7UKDhyaygmpqJSmYk8W3U/ZPy/A00iQZEorj1Bl0u 8Q== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2mgsgtvtb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Sep 2018 18:24:52 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w8JIOpIm012820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Sep 2018 18:24:52 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w8JIOpDw000548; Wed, 19 Sep 2018 18:24:51 GMT In-Reply-To: <<83pnx9een5.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9021 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809190178 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:150457 Archived-At: > > Anyay, replaying the recipe now (again, from -Q), I see the bad > > behavior in _all_ Emacs releases (including back to Emacs 20, > > when there was no variable `mouse-drag-copy-region'). >=20 > Makes sense, because those versions worked as if > mouse-drag-copy-region was t. Emacs 22.1 added that variable, and you > should be able to see the problem go away starting from that version, > when this variable is nil. No. As I said, I checked Emacs 22.3.1 - to be exact: GNU Emacs 22.3.1 (i386-mingw-nt6.2.9200) of 2008-09-06 on SOFT-MJASON And the problem exists regardless of the value of `mouse-drag-copy-region'. Setting the variable to nil has no effect in this regard - still the same p= roblem. > > In Emacs 23.4, changing `mouse-drag-copy-region' to nil does _not_ > > fix the behavior, for me. Are you sure that it does, for you? >=20 > Yes. I just rechecked again, to be sure. I don't understand why it > doesn't work for you, maybe it's something specific to your system, or > maybe that Emacs binary is somehow different from mine (unlikely). Or > maybe you made some mistake in reproducing the behavior in that > version. I've checked it multiple times now, each time from `emacs -Q'. This is my Emacs 23.4 version: GNU Emacs 23.4.1 (i386-mingw-nt6.2.9200) of 2012-02-04 on MARVIN And I see the same thing in subsequent releases, as I said. I'm on Windows 10. Nothing special about my Windows, AFAIK. > > In Emacs 24.5 and later the bad behavior exists only when the > > variable is non-nil. >=20 > When that variable is non-nil, what you see is expected behavior, see > below. >=20 > > So the bug does not seem to be a regression, and it is longstanding. > > Perhaps no one ever tried to use `C-M-w M-w' with a mouse > > selection when testing? >=20 > Indeed, with that variable non-nil, users are not expected to copy and > paste using the keyboard, they are expected to do that with the mouse. > And they certainly aren't expected to mix both methods in the same > sequence of actions on the same text. I don't agree. Nothing in the description of `mouse-drag-copy-region' suggests that with a non-nil value users are not expected to also copy and paste using the keyboard. That would make no sense. There is no reason that someone should not be able to use `C-M-w' to affect copies/kills made with the mouse. And there is nothing in the doc to suggest otherwise. > > Do you agree that this is a bug? >=20 > No, I think it's expected. When that variable is non-nil, making the > second selection automatically copies the selected text into the > kill-ring, so your C-M-w affects the next M-w, which copies the same > text. =20 I understand that that's what happens. But it's not what _should_ happen, IMO. `C-M-w' should make the following kill (or copy as kill) append to the previous kill-ring entry, in general. But in the case of the automatic copy to the kill-ring just by selecting with the mouse, that automatic copy should be replaced by `C-M-w' when it is followed by another kill command. I realize that that behavior was not implemented. But it's the only behavior that makes sense, to allow `C-M-w' to work with mouse selections. So I stand by my report, but you can call it an enhancement request if you prefer. And until the requested enhancement is made there is a doc problem for `C-M-w', as it does not call out the fact that it doesn't append text selected with the mouse. AFAIK, there is no way to use `C-M-w' to cause a mouse selection to be appended to what was at the head of the kill-ring before that selection was made. > The text of the first selection should be available with M-y, > as it is one slot down in the kill-ring (and should also be there > twice, for the same reason). There's no way, AFAIK, to get the mouse selection appended to that first selection, as the top kill-ring entry. You cannot use M-y anywhere in a sequence of actions with `C-M-w' to append a mouse selection to that previous kill-ring entry. > > To me, this is a bug. The behavior contradicts what the doc says for > > `C-M-w', and the behavior is useless (why would anyone want > > duplication of the mouse selection - appending it to itself instead > > of the previous kill?) >=20 > You create the duplication by using M-w, because with that variable > non-nil, there's no need for M-w, as selected text automatically gets > placed in the kill-ring as soon as it is selected.=20 Yes, I know. I think you're not getting the point. There is no way to tell Emacs to append the current mouse selection to the head of the kill-ring as it was before the mouse selection, replacing that head with the concatenation. Emacs provides `C-M-w' for that, but it cannot (so far) be used to append a mouse selection. The automatic copy-to-kill that happens with mouse selection is a good thing. But it should not happen if the selection immediately follows `C-M-w'.=20 Not sure that's the fix, but it seems like it might be. The intended effect is clear enough, as described above: `C-M-w' should be able to have the effect that a subsequent mouse selection can be appended to what was at the head of the ring before that mouse selection. Probably the fix needs to be made to `mouse-save-then-kill', not to `append-next-kill': Don't copy selection as kill if previous command is `append-next-kill'. But it's not enough to test `last-command' for that, because `append-next-kill' sets `this-command' to `kill-region'. Maybe checking whether `real-last-command' is `append-last-kill' is sufficient. > This mode is for people who select and copy/paste with the mouse, > not with the keyboard. I don't agree. And I don't agree that there are Emacs users who select only with the mouse or only with the keyboard. Or even if there are such people, I see no evidence that this variable (or "mode") is only for such people. But forget about this variable/mode. The enhancement request is to be able to use `C-M-w' to have Emacs append the mouse selection to the last kill (the one prior to the implicit/automatic kill from making the mouse selection). That's all. > What documentation does this contradict?=20 `C-M-w', but contradict is not the right word here. Yes, technically it does do what it says. But it does not do what one expects. It's not about whether it technically appends the `M-w' copy (after `C-M-w') to the kill-ring head, which is the same text. It's about there being no way to use `C-M-w' to let you=20 append text selected with the mouse. Please tell me how, using the mouse, you would select the first word of this paragraph, and select the 5th word, and be able to yank their concatenation. That's what `C-M-w' is for: letting you copy/kill bits of text to the kill-ring, not as separate entries but by concatenating them together as the head entry of the ring. > Perhaps we should clarify > that, but in general you are doing something unexpected: mixing the > mouse-based selection and copy/paste paradigm with the keyboard-based > one. They are supposed to be separate, and the defaults since Emacs > 24 make sure they are. I don't think (1) mouse-based selection and copying to the kill-ring and (2) keyboard-based selection and copying to the kill-ring are unmixed. You can mix them freely, in any order, with no problem. Emacs has no policy of limiting use of the mouse to people who only use the mouse, and similarly for the keyboard. The only thing that does not work, AFAIK, is what I've described here. And it's not even about mixing mouse and keyboard. Tell me how, using _only_ the mouse, to select bits on noncontiguous text and get their concatenation at the head of the kill-ring.