From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60841: 30.0.50; kill-ring-save pauses despite region being highlighted Date: Mon, 16 Jan 2023 14:47:35 +0200 Message-ID: <83zgai4peg.fsf@gnu.org> References: <87h6wrs71h.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12125"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60841@debbugs.gnu.org To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 16 13:48:18 2023 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 1pHOuQ-00030l-BE for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Jan 2023 13:48:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHOuE-0002vX-39; Mon, 16 Jan 2023 07:48:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHOuA-0002to-IC for bug-gnu-emacs@gnu.org; Mon, 16 Jan 2023 07:48:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHOuA-00074i-9G for bug-gnu-emacs@gnu.org; Mon, 16 Jan 2023 07:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pHOuA-00014C-4J for bug-gnu-emacs@gnu.org; Mon, 16 Jan 2023 07:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jan 2023 12:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60841 X-GNU-PR-Package: emacs Original-Received: via spool by 60841-submit@debbugs.gnu.org id=B60841.16738732553928 (code B ref 60841); Mon, 16 Jan 2023 12:48:02 +0000 Original-Received: (at 60841) by debbugs.gnu.org; 16 Jan 2023 12:47:35 +0000 Original-Received: from localhost ([127.0.0.1]:60768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHOti-00011H-Rn for submit@debbugs.gnu.org; Mon, 16 Jan 2023 07:47:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHOth-000110-5R for 60841@debbugs.gnu.org; Mon, 16 Jan 2023 07:47:33 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHOtb-0006xt-VN; Mon, 16 Jan 2023 07:47:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=NHbW22di+jC6FLH2ZUFsu/4KTZA4ShNQaTuaoZ4Pwao=; b=ZrR28tsxdIAknClLkceO xqbrphtP5Jv8mbDkO6XkbSI0MyPFiyDMnJL1E+A9RDNAChR3hNhYM9dIILLIFcb5eHeN9AxgeRqvn uyWKqThAFzyQ8txd1gTQ9ymyO7USdTyiKsYqnRO9Iqgjc5mGDlxa/hmdKidC+2W3UKVNMWrVTy2aQ 4FEwuaeZl5uMHn81KCP69zhv0jEP84+oSStg9Bub9lwLsdzOg+fN53X0GAbWgXlCN/BMGMB59kK19 VmjM4kC2/+roa4RavX2h5ls+XYfTb2yj0pZ2n356QUbpeC2Dn3XYwj8AbQWyGGtAW5k8LFW9NHyZW WupXWRSVbgl/Og==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHOtb-0003Q3-Ep; Mon, 16 Jan 2023 07:47:27 -0500 In-Reply-To: <87h6wrs71h.fsf@gmail.com> (message from =?UTF-8?Q?K=C3=A9vin?= Le Gouguec on Mon, 16 Jan 2023 00:38:02 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253486 Archived-At: > From: Kévin Le Gouguec > Date: Mon, 16 Jan 2023 00:38:02 +0100 > > The docstring says that this is done "if there is currently no active > region highlighting"; in practice, this translates to: > > ;; Swap point-and-mark quickly so as to show the region that > ;; was selected. Don't do it if the region is highlighted. > (when (and (numberp copy-region-blink-delay) > (> copy-region-blink-delay 0) > (or (not (region-active-p)) ; (a) > (not (face-background 'region nil t)))) ; (b) > > IOW "active region highlighting" means "(a) an active region, and (b) > any background for the region face". face-background, however, is not > enough to asses (b); consider, from emacs -Q: > > M-: (custom-set-faces '(region ((t (:foreground "blue" :inverse-video t))))) > C-x h > M-w > > In this situation, the region face has a clearly visible background, yet > indicate-copied-region still behaves as if the region is not > "highlighted", and triggers the (harmless and entirely interruptible) > point-and-mark swap followed by a pause. Yes, the existing conditions are a bit naïve. > The attached patch handles this foreground + inverse-video switcheroo. > Not sure how many themes actually do that in the wild, so I'd understand > if there wasn't much enthusiasm for applying. That face-background > check has been with us since 2004; haven't found any hint in the BTS > that anyone else has been bothered by this false negative. IMNSHO, this just makes another mini-step (albeit in the right direction), instead of going all the way. There are other face attributes that can make the region stand out on display: what about underline or italics, for example? And vice versa: the face could have a background that is identical or almost identical to the default face. We could keep adding conditions for more and more face attributes, one by one. But it would be better to have there a test which would tell us whether the region face is "visually different" from the default face. Can we do something like that? Alternatively, we could add a user option to make the swap unconditional, because maybe some users would prefer that to splitting hair in this case. Then we could stop worrying about all those fine differences. Thanks.