unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
Cc: 60841@debbugs.gnu.org
Subject: bug#60841: 30.0.50; kill-ring-save pauses despite region being highlighted
Date: Mon, 16 Jan 2023 14:47:35 +0200	[thread overview]
Message-ID: <83zgai4peg.fsf@gnu.org> (raw)
In-Reply-To: <87h6wrs71h.fsf@gmail.com> (message from Kévin Le Gouguec on Mon, 16 Jan 2023 00:38:02 +0100)

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> 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.





  reply	other threads:[~2023-01-16 12:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-15 23:38 bug#60841: 30.0.50; kill-ring-save pauses despite region being highlighted Kévin Le Gouguec
2023-01-16 12:47 ` Eli Zaretskii [this message]
2023-01-16 21:58   ` Kévin Le Gouguec
2023-01-16 22:28   ` Gregory Heytings
2023-01-17  7:53     ` Kévin Le Gouguec
2023-01-17  8:26       ` Gregory Heytings
2023-01-17 22:03         ` Kévin Le Gouguec
2023-01-18 13:12           ` Eli Zaretskii
2023-01-18 22:16             ` Kévin Le Gouguec
2023-01-21  8:08               ` Eli Zaretskii
2023-01-22 22:45                 ` Kévin Le Gouguec
2023-01-23 13:01                   ` Eli Zaretskii
2023-01-23 22:29                     ` Kévin Le Gouguec
2023-01-24 13:23                       ` Eli Zaretskii
2023-01-28 17:45                         ` Kévin Le Gouguec
2023-01-28 18:07                           ` Eli Zaretskii
2023-01-29 14:54                             ` Kévin Le Gouguec
2023-01-29 15:40                               ` Eli Zaretskii
2023-01-29 22:57                                 ` Kévin Le Gouguec
2023-01-30 12:41                                   ` Eli Zaretskii
2023-01-30 22:38                                     ` Kévin Le Gouguec
2023-02-02 10:43                                       ` Eli Zaretskii
2023-02-02 21:15                                         ` Kévin Le Gouguec
2023-01-29 17:55                               ` Juri Linkov
2023-01-29 19:09                                 ` Eli Zaretskii
2023-01-29 19:33                                   ` Eli Zaretskii
2023-01-29 20:32                                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zgai4peg.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=60841@debbugs.gnu.org \
    --cc=kevin.legouguec@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).