From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#27442: Un-obsolete x-clipboard-yank, or provide analogous functional Date: Mon, 05 Jul 2021 22:11:22 +0200 Message-ID: <87tul8v7v9.fsf@gnus.org> References: <83r2ydupg7.fsf@gnu.org> <9b98217a-be79-56ed-16a9-0c15622111c5@yandex.ru> <877di4yhk8.fsf@gnus.org> <87eeccwzjx.fsf@gnus.org> <83a6n0hf9x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30250"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: monnier@iro.umontreal.ca, 27442@debbugs.gnu.org, Hi-Angel@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 05 22:12:19 2021 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 1m0Ux0-0007dG-EF for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 22:12:18 +0200 Original-Received: from localhost ([::1]:43702 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m0Uwz-0007ka-Ed for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 05 Jul 2021 16:12:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37468) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m0Uwk-0007kS-Po for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:12:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35188) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m0Uwk-0003Rk-II for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m0Uwk-0007Px-FB for bug-gnu-emacs@gnu.org; Mon, 05 Jul 2021 16:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jul 2021 20:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27442 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch moreinfo Original-Received: via spool by 27442-submit@debbugs.gnu.org id=B27442.162551589528481 (code B ref 27442); Mon, 05 Jul 2021 20:12:02 +0000 Original-Received: (at 27442) by debbugs.gnu.org; 5 Jul 2021 20:11:35 +0000 Original-Received: from localhost ([127.0.0.1]:46734 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0UwJ-0007PI-Hs for submit@debbugs.gnu.org; Mon, 05 Jul 2021 16:11:35 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:60804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0UwH-0007P3-8K for 27442@debbugs.gnu.org; Mon, 05 Jul 2021 16:11:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ypaoTP4ROtvHDdHH3qtbIMUPZ/NsW/sgBTRHUhVavYY=; b=M8Hd32tOs9y6dRui9n8hLxMK4/ vPIy1SGpKBa6O3C5kfgbxnXsEaFpdVpzfewc0v7tEQTVP/Yuumh0ZjRpPkjuS/nxeLY0a45PBceBl 7FH0kPoc8niq2VQPck8l2ef4cpHStmjHGFKaVh1e9dYPxXstHGHMrGQZaIpaQQWDWMX8=; Original-Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0Uw6-0000AU-Qt; Mon, 05 Jul 2021 22:11:25 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUcFxNSSz64nYPB sST///8xAqQpAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UHBRMuOUXBkL4AAAGCSURBVDjLpZPhdcMg DIRRs4AECwQmAGv/3XonsI3T/ukryQsOH3dCEk4pmaXcVJomVVNNXDFNYq1aa5YxxZD4gnMrRGIJ HxM+WwnhNUS5kwK3+CfYjicsCL2ACR4SUwEb5Qm4KFXs5cW5600tTmUVTrkhsg/uM81SJ4BLIxjd IhmNmBozEpJ89DyzvAYBSnD0dgOZE62OB4AX08gMNDqKcQJdPxqgzuCbDMHNvcdxbT/AB0iyASV4 aViF8wMUAhuX09dpVWjlRztBbvkCKOVxdhVgKVDeYs526wUSAU7kY3y1rHWGb1XTOq47FOE9QZLi OgEUGPUEqQxFGguwVbxDBLAqAZyKG9gChTEmUAIhcF3BARgj8bpuwFZs1CdXVkgXGFQQqM3DabnB KgrTGaX7THAgyJuZl7C6Mw8w25jfD8A2zMbsiuHjtaLbh5WV44zO4BtgA+qnwgZQt3VRNjDixsUt 4gvFx6zzXikXYAhVvFkL/Hv87iL6Awjbl+IS/81rG9/fa1A/hs4P0gAAACV0RVh0ZGF0ZTpjcmVh dGUAMjAyMS0wNy0wNVQxOTo0Njo1NyswMDowMAHJjN4AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEt MDctMDVUMTk6NDY6NTcrMDA6MDBwlDRiAAAAAElFTkSuQmCC X-Now-Playing: Mark Beyer's _Radiator Music_: "Radiator Music 15" In-Reply-To: <83a6n0hf9x.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Jul 2021 19:55:06 +0300") 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:209489 Archived-At: Eli Zaretskii writes: > Please also try with save-interprogram-paste-before-kill non-nil. As far as I can tell, that's not really affected by the code in gui-selection-value, or vice versa. But... Hm... poking at this a bit more: When select-enable-clipboard is non-nil (the default), (kill-new "foo") (gui--selection-value-internal 'CLIPBOARD) => "foo" gui--last-selected-text-clipboard => "foo" Because we're copying over the string to the clipboard. So when we're then yanking back, we're really trying to determine whether we ourselves was responsible for putting the data on the clipboard, and if that's the case, we want to ignore the data? Because: (kill-new "foo") (gui-selection-value) => nil Could we use a different way to identify this situation that's less fragile? Hm... I don't really see any with our current low-level functions. I think x-get-selection-internal could have returned more metadata -- the timestamp, for instance, which would have allowed us to see whether we ourselves really pushed the data to the clipboard. My analysis here may be wrong, but if this is the reason the code in that function is the way it is, I think the right fix here is the trivial patch I proposed, along with more comments in `gui-selection-value' that explains what the point of the duplicate-ignoring code is. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no