From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ignacio Casso Newsgroups: gmane.emacs.bugs Subject: bug#53894: 27.2; Clipboard copy -> C-y -> M-y -> Same clipboard copy does not push to kill ring Date: Mon, 28 Feb 2022 13:12:44 +0100 Message-ID: References: <838rujutsj.fsf@gnu.org> <87a6ezfcnc.fsf@gnus.org> <83zgmztabd.fsf@gnu.org> <8735kr9kmp.fsf@gnus.org> <83pmnuudo6.fsf@gnu.org> <87ee4ayl3n.fsf@yahoo.com> <83k0e2ucq7.fsf@gnu.org> <877da2yjze.fsf@yahoo.com> <87iltm7upm.fsf@gnus.org> <87leyiw6uu.fsf@yahoo.com> <87wni1tzzl.fsf@yahoo.com> <87pmnttw78.fsf@yahoo.com> <87leyhtv9q.fsf@yahoo.com> <87wni0str6.fsf@yahoo.com> <87h78j6bz0.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="668"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 29.0.50 Cc: Lars Ingebrigtsen , 53894@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Feb 28 14:37:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nOgDH-000ATm-E0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Feb 2022 14:37:19 +0100 Original-Received: from localhost ([::1]:60430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nOgDG-0005iW-2l for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 28 Feb 2022 08:37:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33616) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nOg6I-0007mo-MC for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:30:10 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38399) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nOg6E-000394-Ky for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:30:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nOg6E-00080a-Aw for bug-gnu-emacs@gnu.org; Mon, 28 Feb 2022 08:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ignacio Casso Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Feb 2022 13:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53894 X-GNU-PR-Package: emacs Original-Received: via spool by 53894-submit@debbugs.gnu.org id=B53894.164605495530700 (code B ref 53894); Mon, 28 Feb 2022 13:30:02 +0000 Original-Received: (at 53894) by debbugs.gnu.org; 28 Feb 2022 13:29:15 +0000 Original-Received: from localhost ([127.0.0.1]:60529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOg5R-0007z5-Ot for submit@debbugs.gnu.org; Mon, 28 Feb 2022 08:29:14 -0500 Original-Received: from mail-oln040092073101.outbound.protection.outlook.com ([40.92.73.101]:40362 helo=EUR04-HE1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nOg5O-0007ys-J6 for 53894@debbugs.gnu.org; Mon, 28 Feb 2022 08:29:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O/lWGK08Ct6n+/3+yDMtzmv8iycXTkHvRoICz1H7F0mAdPTra5V8jCd2ghcSUnCPWt6Sr/nVC66s+2hVuGd1lCybxYz+i3u6vBsSN+sFyhGUIiTcoyz4LYzSYHIWIj4fZXS0oI2Q++UlKAs4C64+TjFWbOS4bZyvNtkO/TcczRvrDweKkt3uGjDEy4HPm5VZ2dWVAWokULkqLc7+pBcPSBFByZxdU4bxLRYFDg+5sIqWVjCH9ZdYP5ld3bkvpmIIEucM5q24dqL5Yh3d7v5oL4q7uX5O81jYPflkxDfYzbvPqSkvILNf0Xg3BxkHmo72m3AtEJaU2R0JVjVM88ZihA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C250AirIsOPSTC0OOpwkQLKMbbkw+o3Ie25XSKF5xao=; b=DhBsvEYoFTdeCGDi4YlmkgphWHYhyEix6Ew87y4HIElRNrQPBXg/uGv9Pjcxfxyty+57waKDtZyer8iXJW2E1lcqa69c0UXAb9lXKOoBTBf0wsRFQrFM2MACGYQarHIF2n9diVTV/N8rxJhOQNikbha7EZhkIEXdUwgT79Y8F68jBo7+LhqtIJP/8Rur4ObyXGosdIXaItlvoUUY/bJZFbXL19ostjrzuB8w2iEikobkXI8TO8jNeZfT0v3MkiB/Xm193JAx5u0zdLj9XEnGKmBMLj3gIm10o9Mtjua1lJeGK7ZPPpKJCAOw4ZCgmjra7+JVLdMeNYrQfrBNE9DIrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C250AirIsOPSTC0OOpwkQLKMbbkw+o3Ie25XSKF5xao=; b=MVHiif2z3LgbNT4fUicb7n8lyAoH396hEVADtEfCZO1MERoAs8MbbFN59YXNE8oj/7FTpX7NQwTPkCbGMMS4Jf8qm2hc9ElLJY+vK4qODt54PR6ShaTU1fDpJZUDfRVC6hVbTVNiKJ9InWK6V19ojBUfxKKDZpbpIygz/4VK82I7U4nT3sXNYhtsLZs7mst9dtanA19gBFHJHybdfXxpK+F9u7t+87+cTXkSsL0RkeXpo+GpvM3T2Jd29jue7P1cbvmKWueKRs7yFT1njoa9M2B0hu/mAblpI2DNUhJYEcF7fzaZ/o1KltMWhQ5l4RNalXMJgJtNe6KpMYtC9y6SrQ== Original-Received: from PAXPR06MB7760.eurprd06.prod.outlook.com (2603:10a6:102:155::8) by DBAPR06MB6758.eurprd06.prod.outlook.com (2603:10a6:10:186::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Mon, 28 Feb 2022 13:29:04 +0000 Original-Received: from PAXPR06MB7760.eurprd06.prod.outlook.com ([fe80::89d5:1159:122b:2b2f]) by PAXPR06MB7760.eurprd06.prod.outlook.com ([fe80::89d5:1159:122b:2b2f%6]) with mapi id 15.20.5017.026; Mon, 28 Feb 2022 13:29:03 +0000 In-reply-to: <87h78j6bz0.fsf@yahoo.com> X-TMN: [8wpJQqaN0BRuH/FpCKLGHAa9jIudX88S] X-ClientProxiedBy: MR2P264CA0181.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501::20) To PAXPR06MB7760.eurprd06.prod.outlook.com (2603:10a6:102:155::8) X-Microsoft-Original-Message-ID: <87v8wz6rxi.fsf@hotmail.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 75e19be0-71c3-4bb5-0b5f-08d9fabe4937 X-MS-TrafficTypeDiagnostic: DBAPR06MB6758:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: E7Grfr/zDVd3Dk8libiSuB6OlGfwMuHtggAneT3i7jTelTBCgpB217oLRHprXX193/rMzxeq6CcnHzzJAYnLFHAWL9ZuVCKG35mSFvqg5NC71X/6+roy35OhVx23DS80VKgfaxFnQ+y+aOojjDLlPPEdfGL/oCWJvK0a2N2fiZtFaylyWHbis3wkZDKWdGVYQ8eeWfG9RnBBqCA6OJIu5j/B5H8m+mPCj9rTbRcVs/We64UEDUApxdUA02H4UJ4Gpubft37bSCRvNBJeV1gMxLIfLar4ygLGtZaY6V+5e3rCofMPRVT+HMaKbTXy7vuy/X2ZkMQIlKtBsU4kBaMlBen6WejQT4OBdOcw46HpRxGEFKVxY05qf9panM5FRTEK9A/1x6cRCk/eRGZhLtQCIJmQ+HKde70el3JA/yujkLf7b09DSYdNWGW+F4XE8w50etrk+SeuvPv0fWCZ6rXb7XYDvU0fYbQVkhcfzR1BTBAbTLbs1MrrApKmkE3DeT50/LQpqcuzpAoLy7G/XVdc4jlVg0AGffrpUwbvWT9KCTdOZ9rX62jnLw6/x8Lzv068GUD9v3KWKM3jGcZpEcA0gA== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4jedbfOjIx/f+XJvfHPf7MZctoeTww9WEvaRl81T276vlfeXnpblVVVQlFayV9jHzqmkCjst+jd+CFm/IHI1VTqyDlie3pcRqm1quVKllKnWi61XY0LVrwf16Voe/fZCNPZNrnNRTzv+eskqxgtxu5A88bJTBgvLpicKWYdN0ybc4tSbF/llx4e6DmOP83o0dz7PcA47Lopdkol7wjgzKgkWXboxYKZ05dZzl/jHtlZWHOKfiwsCatGZ70miesC/y/0BDEMQPfUkwmwFONGu3Ke0ijXORHdBrnU0Dsv3ViZlw0CSaQkwjFd9g+/kmNVX+dywwTo1qK395ZjXcIZ5tWTj/d4Z/JPfh9KuF4c9Zq7xVhNSZxRHXckGFjmAur/edD4sA7NHqIRQsNjal9I3tb60Qxc7iykwcIMBG0bwyICAcBRh+jErMO9wKSvWgkoJk+V7LOVPgFrb9Z+vBDAb0xORWTRV/WJt7nNdIZaIYBX6HnCSs3uVsQjfOJ2lZPWltz0TUFoU2RAi/geH2z9bwmp42ZkN6rC90YpkFwNWpsbn/P83WoLSLtwjok11dhfv1+gPczRsFRUmO9TQ4thXECcSRAKmcrxGMsRo06mLuD+BXd66hIh6+y6J6oYlzz71R6YDaSifqSbuF5BSiE27TW4dJdBgRSU7MR5esaYvCYP6foN0w0mtF18pfJf048lTT3W6lMvrfIJiyqDHSZ+TQhmKWe42K+WEU43KG1rNNkLqABVHHoZTGAvpho 2SV4aIKpq9PSLRAjvAqog09X6OG4MCK+n8EWPnI1yiJA8lNNEHCGuZ7nN1HP+MA2UAARBpDGVamhZpfCrX042wW8egh0L+t6Mj X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-6e454.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 75e19be0-71c3-4bb5-0b5f-08d9fabe4937 X-MS-Exchange-CrossTenant-AuthSource: PAXPR06MB7760.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2022 13:29:03.8877 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR06MB6758 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:227812 Archived-At: --=-=-= Content-Type: text/plain >> I volunteer to do both if you agree that it would be an improvement. > > I do agree, any patches would be greatly welcome. Thanks in advance. I have installed the development version of Emacs and made a first patch attempt, preserving the structure of the program as much as possible. I have not tested thoroughly, but it works for all the cases I have tried. I have attached it to this mail, and comment each change below. Let me know what you think. > lisp/menu-bar.el | 4 +-- > lisp/obsolete/mouse-sel.el | 2 +- > lisp/select.el | 70 +++++++++++++++++++++++--------------- > lisp/term/pc-win.el | 2 +- > 5 files changed, 47 insertions(+), 33 deletions(-) > > diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el > index ab64928fe7..01683f5c9f 100644 > --- a/lisp/menu-bar.el > +++ b/lisp/menu-bar.el > @@ -606,8 +606,8 @@ clipboard-yank > "Insert the clipboard contents, or the last stretch of killed text." > (interactive "*") > (let ((select-enable-clipboard t) > - ;; Ensure that we defeat the DWIM login in `gui-selection-value'. > - (gui--last-selected-text-clipboard nil)) > + ;; Ensure that we defeat the DWIM logic in `gui-selection-value'. > + (gui--last-clipboard-selection-fingerprint nil)) > (yank))) > > (defun clipboard-kill-ring-save (beg end &optional region) - DWIM login -> DWIM logic (typo) - replaced gui--last-selected-text-clipboard variable with the new one I have introduced (explained below) - I have tested that clipboard-yank works for the following cases: - (setq select-enable-clipboard nil) -> copy in another program -> clipboard-yank another program. - copy in another program -> C-y -> M-y -> clipboard-yank > diff --git a/lisp/obsolete/mouse-sel.el b/lisp/obsolete/mouse-sel.el > index a9d6bfee60..fc91cc9fc1 100644 > --- a/lisp/obsolete/mouse-sel.el > +++ b/lisp/obsolete/mouse-sel.el > @@ -304,7 +304,7 @@ mouse-sel-get-selection-function > (if (eq selection 'PRIMARY) > (or (gui-selection-value) > (bound-and-true-p x-last-selected-text-primary) > - gui--last-selected-text-primary) > + gui--last-selected-text-primary) ;; this variable no longer exists. Does code in lisp/obsolete/ need to be mantained? > (gui-get-selection selection))) > "Function to call to get the selection. > Called with one argument: Here I have not replaced the variable, since I have assumed that code under the obsolete/ directory does not need to be maintained, and C-h f tells me that function is not loaded by default. However there is a warning when compiling. Should I fix it? > diff --git a/lisp/select.el b/lisp/select.el > index 42b50c44e6..55c409d347 100644 > --- a/lisp/select.el > +++ b/lisp/select.el > @@ -25,9 +25,10 @@ > ;; Based partially on earlier release by Lucid. > > ;; The functionality here is divided in two parts: > -;; - Low-level: gui-get-selection, gui-set-selection, gui-selection-owner-p, > -;; gui-selection-exists-p are the backend-dependent functions meant to access > -;; various kinds of selections (CLIPBOARD, PRIMARY, SECONDARY). > +;; - Low-level: gui-backend-get-selection, gui-backend-set-selection, > +;; gui-backend-selection-owner-p, gui-backend-selection-exists-p are > +;; the backend-dependent functions meant to access various kinds of > +;; selections (CLIPBOARD, PRIMARY, SECONDARY). > ;; - Higher-level: gui-select-text and gui-selection-value go together to > ;; access the general notion of "GUI selection" for interoperation with other > ;; applications. This can use either the clipboard or the primary selection, - gui-selection-owner-p -> gui-backend-selection-owner-p (the former does not exist) - gui-selection-exists-p -> gui-backend-selection-exists-p (the former does not exist) - gui-get-selection -> gui-backend-get-selection (the former does exist, but the later is lower lever, and I assumed that if the previous needed to be updated this one probably too) - gui-set-selection -> gui-backend-set-selection (same as above) > @@ -108,16 +109,24 @@ select-enable-primary > :group 'killing > :version "25.1") > > -;; We keep track of the last text selected here, so we can check the > -;; current selection against it, and avoid passing back our own text > -;; from gui-selection-value. We track both > +;; We keep track of the last selection here, so we can check the > +;; current selection against it, and avoid passing back with > +;; gui-selection-value the same text we previously killed or > +;; yanked. We track both > ;; separately in case another X application only sets one of them > ;; we aren't fooled by the PRIMARY or CLIPBOARD selection staying the same. > +;; > +;; TODO: add selection owner to fingerprint, since timestamp is not > +;; always relieable? Probably not worth it, since right now we can't > +;; get the owner with the low-level functions out of the box, and text > +;; plus timestamp is probably a strong enough fingerprint already. > +(defvar gui--last-clipboard-selection-fingerprint nil > + "The fingerprint of the CLIPBOARD selection last seen, which is a > +list of value and timestamp.") > +(defvar gui--last-primary-selection-fingerprint nil > + "The fingerprint of the PRIMARY selection last seen, which is a > +list of value and timestamp.") > > -(defvar gui--last-selected-text-clipboard nil > - "The value of the CLIPBOARD selection last seen.") > -(defvar gui--last-selected-text-primary nil > - "The value of the PRIMARY selection last seen.") > > (defun gui-select-text (text) > "Select TEXT, a string, according to the window system. - Using new variables gui--last-clipboard-selection-fingerprint and gui--last-primary-selection-fingerprint instead of gui--last-selected-text-clipboard and gui--last-selected-text-primary. They have the same purpose but hold the text and the timestamp instead of just the text, and I have updated the code everywhere they were referenced to use the text-timestamp pair instead of just the text . Better ideas for the names are welcome. - Updated previous comment - Just threw the idea that a better fingerprint would include the owner of the selection, if timestamps are sometimes not updated precisely when the owner changes, as Po Lu said. > @@ -127,14 +136,16 @@ gui-select-text > MS-Windows does not have a \"primary\" selection." > (when select-enable-primary > (gui-set-selection 'PRIMARY text) > - (setq gui--last-selected-text-primary text)) > + (setq gui--last-primary-selection-fingerprint > + (list text (gui-get-selection 'PRIMARY 'TIMESTAMP)))) > (when select-enable-clipboard > ;; When cutting, the selection is cleared and PRIMARY > ;; set to the empty string. Prevent that, PRIMARY > ;; should not be reset by cut (Bug#16382). > (setq saved-region-selection text) > (gui-set-selection 'CLIPBOARD text) > - (setq gui--last-selected-text-clipboard text))) > + (setq gui--last-clipboard-selection-fingerprint > + (list text (gui-get-selection 'CLIPBOARD 'TIMESTAMP))))) > (define-obsolete-function-alias 'x-select-text 'gui-select-text "25.1") > > (defcustom x-select-request-type nil Saving the text-timestamp pair instead of just text. > @@ -175,6 +186,7 @@ gui--selection-value-internal > ;; some other window systems. > (memq window-system '(x haiku)) > (eq type 'CLIPBOARD) > + ;; Should we unify this with the DWIM logic? > (gui-backend-selection-owner-p type)) > (let ((request-type (if (memq window-system '(x pgtk haiku)) > (or x-select-request-type I consider that check to be conceptually part of the same DWIM logic, and feel that maybe both checks should go together in the code. However I decided to preserve the code structure for now, since I wanted to make as little changes as possible, having the ownership check there can save unnecessary computations, and the check is mostly redundant now otherwise. > @@ -194,33 +206,34 @@ gui--selection-value-internal > (defun gui-selection-value () > (let ((clip-text > (when select-enable-clipboard > - (let ((text (gui--selection-value-internal 'CLIPBOARD))) > + (let ((text (gui--selection-value-internal 'CLIPBOARD)) > + (timestamp (gui-get-selection 'CLIPBOARD 'TIMESTAMP))) > (when (string= text "") > (setq text nil)) > - ;; When `select-enable-clipboard' is non-nil, > - ;; killing/copying text (with, say, `C-w') will push the > - ;; text to the clipboard (and store it in > - ;; `gui--last-selected-text-clipboard'). We check > - ;; whether the text on the clipboard is identical to this > - ;; text, and if so, we report that the clipboard is > - ;; empty. See (bug#27442) for further discussion about > - ;; this DWIM action, and possible ways to make this check > - ;; less fragile, if so desired. > + ;; Check the CLIPBOARD selection for 'newness', i.e., > + ;; whether it is different from the last time we did a > + ;; yank operation or whether it was set by Emacs itself > + ;; with a kill operation, since in both cases the text > + ;; will already be in the kill ring. See (bug#27442) and > + ;; (bug#53894) for further discussion about this DWIM > + ;; action, and possible ways to make this check less > + ;; fragile, if so desired. > (prog1 > - (unless (equal text gui--last-selected-text-clipboard) > + (unless (equal (list text timestamp) gui--last-clipboard-selection-fingerprint) > text) > - (setq gui--last-selected-text-clipboard text))))) > + (setq gui--last-clipboard-selection-fingerprint (list text timestamp)))))) > (primary-text > (when select-enable-primary > - (let ((text (gui--selection-value-internal 'PRIMARY))) > + (let ((text (gui--selection-value-internal 'PRIMARY)) > + (timestamp (gui-get-selection 'PRIMARY 'TIMESTAMP))) > (if (string= text "") (setq text nil)) > ;; Check the PRIMARY selection for 'newness', is it different > ;; from what we remembered them to be last time we did a > ;; cut/paste operation. > (prog1 > - (unless (equal text gui--last-selected-text-primary) > + (unless (equal (list text timestamp) gui--last-primary-selection-fingerprint) > text) > - (setq gui--last-selected-text-primary text)))))) > + (setq gui--last-primary-selection-fingerprint (list text timestamp))))))) > > ;; As we have done one selection, clear this now. > (setq next-selection-coding-system nil) - Using the timestamp-text pair instead of just text - Updated comments - I have tested the following cases: - Copy in another program -> C-y - Copy in other program -> C-y -> C-y -> M-y (the copied text is not duplicated in the kill ring, i.e., gui-selection-value returns nil for the second C-y) - C-k -> C-y -> M-y (the killed text is not duplicated in the kill ring, i.e., gui-selection-value returns nil) - Copy something in other program -> C-y -> M-y -> Copy the same thing in other program -> C-y (works as expected, i.e., the bug I reported is fixed) > @@ -239,7 +252,8 @@ gui-selection-value > ;; timestamps there is no way to know what the 'correct' value to > ;; return is. The nice thing to do would be to tell the user we > ;; saw multiple possible selections and ask the user which was the > - ;; one they wanted. > + ;; one they wanted. EDIT: We do have timestamps now, so we can > + ;; return the newer. > (or clip-text primary-text) > )) > An unrelated issue which could be solved with timestamps, but the comment must be old and says we don't have them. Just updated the comment saying we do have them now. > diff --git a/lisp/term/pc-win.el b/lisp/term/pc-win.el > index 327d51f275..2ae3cbd8b2 100644 > --- a/lisp/term/pc-win.el > +++ b/lisp/term/pc-win.el > @@ -248,7 +248,7 @@ w16-selection-owner-p > ;; Windows clipboard. > (cond > ((not text) t) > - ((equal text gui--last-selected-text-clipboard) text) > + ((equal text (car gui--last-clipbaord-selection-fingerprint)) t) > (t nil))))) > - Replaced the check - Returned t instead of text - Have not tested since I don't use Windows, but it's semantically equivalent as before. --=-=-= Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename=0001-fixed-bug.patch Content-Transfer-Encoding: quoted-printable Content-Description: Patch for bug#53894 >From a81da62327c58c8351c366e8530bf6250a4ffaa2 Mon Sep 17 00:00:00 2001 From: Ignacio Date: Mon, 28 Feb 2022 12:13:52 +0100 Subject: [PATCH] fixed bug --- etc/DEVEL.HUMOR | 2 +- lisp/menu-bar.el | 4 +-- lisp/obsolete/mouse-sel.el | 2 +- lisp/select.el | 70 +++++++++++++++++++++++--------------- lisp/term/pc-win.el | 2 +- 5 files changed, 47 insertions(+), 33 deletions(-) diff --git a/etc/DEVEL.HUMOR b/etc/DEVEL.HUMOR index bd51845cb1..e93631c331 100644 --- a/etc/DEVEL.HUMOR +++ b/etc/DEVEL.HUMOR @@ -203,4 +203,4 @@ it's still working the same way, and then whether it's = still relevant due to changes elsewhere, and then finally whether it can be improved without breaking odd edge cases on obscure systems you don't have access to. =F0=9F=99=83" - -- Ignacio Casso and Lars Ingebrigtsen + -- Ignacio C. and Lars Ingebrigtsen diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el index ab64928fe7..01683f5c9f 100644 --- a/lisp/menu-bar.el +++ b/lisp/menu-bar.el @@ -606,8 +606,8 @@ clipboard-yank "Insert the clipboard contents, or the last stretch of killed text." (interactive "*") (let ((select-enable-clipboard t) - ;; Ensure that we defeat the DWIM login in `gui-selection-value'. - (gui--last-selected-text-clipboard nil)) + ;; Ensure that we defeat the DWIM logic in `gui-selection-value'. + (gui--last-clipboard-selection-fingerprint nil)) (yank))) =20 (defun clipboard-kill-ring-save (beg end &optional region) diff --git a/lisp/obsolete/mouse-sel.el b/lisp/obsolete/mouse-sel.el index a9d6bfee60..fc91cc9fc1 100644 --- a/lisp/obsolete/mouse-sel.el +++ b/lisp/obsolete/mouse-sel.el @@ -304,7 +304,7 @@ mouse-sel-get-selection-function (if (eq selection 'PRIMARY) (or (gui-selection-value) (bound-and-true-p x-last-selected-text-primary) - gui--last-selected-text-primary) + gui--last-selected-text-primary) ;; this variable no longer ex= ists. Does code in lisp/obsolete/ need to be mantained? (gui-get-selection selection))) "Function to call to get the selection. Called with one argument: diff --git a/lisp/select.el b/lisp/select.el index 42b50c44e6..55c409d347 100644 --- a/lisp/select.el +++ b/lisp/select.el @@ -25,9 +25,10 @@ ;; Based partially on earlier release by Lucid. =20 ;; The functionality here is divided in two parts: -;; - Low-level: gui-get-selection, gui-set-selection, gui-selection-owner-= p, -;; gui-selection-exists-p are the backend-dependent functions meant to a= ccess -;; various kinds of selections (CLIPBOARD, PRIMARY, SECONDARY). +;; - Low-level: gui-backend-get-selection, gui-backend-set-selection, +;; gui-backend-selection-owner-p, gui-backend-selection-exists-p are +;; the backend-dependent functions meant to access various kinds of +;; selections (CLIPBOARD, PRIMARY, SECONDARY). ;; - Higher-level: gui-select-text and gui-selection-value go together to ;; access the general notion of "GUI selection" for interoperation with = other ;; applications. This can use either the clipboard or the primary selec= tion, @@ -108,16 +109,24 @@ select-enable-primary :group 'killing :version "25.1") =20 -;; We keep track of the last text selected here, so we can check the -;; current selection against it, and avoid passing back our own text -;; from gui-selection-value. We track both +;; We keep track of the last selection here, so we can check the +;; current selection against it, and avoid passing back with +;; gui-selection-value the same text we previously killed or +;; yanked. We track both ;; separately in case another X application only sets one of them ;; we aren't fooled by the PRIMARY or CLIPBOARD selection staying the same= . +;; +;; TODO: add selection owner to fingerprint, since timestamp is not +;; always relieable? Probably not worth it, since right now we can't +;; get the owner with the low-level functions out of the box, and text +;; plus timestamp is probably a strong enough fingerprint already. +(defvar gui--last-clipboard-selection-fingerprint nil + "The fingerprint of the CLIPBOARD selection last seen, which is a +list of value and timestamp.") +(defvar gui--last-primary-selection-fingerprint nil + "The fingerprint of the PRIMARY selection last seen, which is a +list of value and timestamp.") =20 -(defvar gui--last-selected-text-clipboard nil - "The value of the CLIPBOARD selection last seen.") -(defvar gui--last-selected-text-primary nil - "The value of the PRIMARY selection last seen.") =20 (defun gui-select-text (text) "Select TEXT, a string, according to the window system. @@ -127,14 +136,16 @@ gui-select-text MS-Windows does not have a \"primary\" selection." (when select-enable-primary (gui-set-selection 'PRIMARY text) - (setq gui--last-selected-text-primary text)) + (setq gui--last-primary-selection-fingerprint + (list text (gui-get-selection 'PRIMARY 'TIMESTAMP)))) (when select-enable-clipboard ;; When cutting, the selection is cleared and PRIMARY ;; set to the empty string. Prevent that, PRIMARY ;; should not be reset by cut (Bug#16382). (setq saved-region-selection text) (gui-set-selection 'CLIPBOARD text) - (setq gui--last-selected-text-clipboard text))) + (setq gui--last-clipboard-selection-fingerprint + (list text (gui-get-selection 'CLIPBOARD 'TIMESTAMP))))) (define-obsolete-function-alias 'x-select-text 'gui-select-text "25.1") =20 (defcustom x-select-request-type nil @@ -175,6 +186,7 @@ gui--selection-value-internal ;; some other window systems. (memq window-system '(x haiku)) (eq type 'CLIPBOARD) + ;; Should we unify this with the DWIM logic? (gui-backend-selection-owner-p type)) (let ((request-type (if (memq window-system '(x pgtk haiku)) (or x-select-request-type @@ -194,33 +206,34 @@ gui--selection-value-internal (defun gui-selection-value () (let ((clip-text (when select-enable-clipboard - (let ((text (gui--selection-value-internal 'CLIPBOARD))) + (let ((text (gui--selection-value-internal 'CLIPBOARD)) + (timestamp (gui-get-selection 'CLIPBOARD 'TIMESTAMP))) (when (string=3D text "") (setq text nil)) - ;; When `select-enable-clipboard' is non-nil, - ;; killing/copying text (with, say, `C-w') will push the - ;; text to the clipboard (and store it in - ;; `gui--last-selected-text-clipboard'). We check - ;; whether the text on the clipboard is identical to this - ;; text, and if so, we report that the clipboard is - ;; empty. See (bug#27442) for further discussion about - ;; this DWIM action, and possible ways to make this check - ;; less fragile, if so desired. + ;; Check the CLIPBOARD selection for 'newness', i.e., + ;; whether it is different from the last time we did a + ;; yank operation or whether it was set by Emacs itself + ;; with a kill operation, since in both cases the text + ;; will already be in the kill ring. See (bug#27442) and + ;; (bug#53894) for further discussion about this DWIM + ;; action, and possible ways to make this check less + ;; fragile, if so desired. (prog1 - (unless (equal text gui--last-selected-text-clipboard) + (unless (equal (list text timestamp) gui--last-clipboard= -selection-fingerprint) text) - (setq gui--last-selected-text-clipboard text))))) + (setq gui--last-clipboard-selection-fingerprint (list text = timestamp)))))) (primary-text (when select-enable-primary - (let ((text (gui--selection-value-internal 'PRIMARY))) + (let ((text (gui--selection-value-internal 'PRIMARY)) + (timestamp (gui-get-selection 'PRIMARY 'TIMESTAMP))) (if (string=3D text "") (setq text nil)) ;; Check the PRIMARY selection for 'newness', is it different ;; from what we remembered them to be last time we did a ;; cut/paste operation. (prog1 - (unless (equal text gui--last-selected-text-primary) + (unless (equal (list text timestamp) gui--last-primary-s= election-fingerprint) text) - (setq gui--last-selected-text-primary text)))))) + (setq gui--last-primary-selection-fingerprint (list text ti= mestamp))))))) =20 ;; As we have done one selection, clear this now. (setq next-selection-coding-system nil) @@ -239,7 +252,8 @@ gui-selection-value ;; timestamps there is no way to know what the 'correct' value to ;; return is. The nice thing to do would be to tell the user we ;; saw multiple possible selections and ask the user which was the - ;; one they wanted. + ;; one they wanted. EDIT: We do have timestamps now, so we can + ;; return the newer. (or clip-text primary-text) )) =20 diff --git a/lisp/term/pc-win.el b/lisp/term/pc-win.el index 327d51f275..2ae3cbd8b2 100644 --- a/lisp/term/pc-win.el +++ b/lisp/term/pc-win.el @@ -248,7 +248,7 @@ w16-selection-owner-p ;; Windows clipboard. (cond ((not text) t) - ((equal text gui--last-selected-text-clipboard) text) + ((equal text (car gui--last-clipbaord-selection-fingerprint)) t) (t nil))))) =20 ;; gui-set-selection is used in gui-set-selection. --=20 2.25.1 --=-=-=--