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

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Indeed.  I wasn't sure how much brain-racking we would feel like
devoting to this issue, hence the naive patch; thank you for prompting
more discussion.

> 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?

I struggle to find a heuristic that I'd dare call "smart", so here's a
dumb one: if _any_ attribute of the region face differs from that of the
default face, then odds are whoever customized the region face (theme
author or end user) intended for it to "stand out" to some extent?

(defun dumb/stands-out-from-default-p ()
  (seq-some
   (lambda (attribute)
     (unless (memq attribute '(:extend :inherit))
       (let ((default-value (face-attribute 'default attribute nil t))
             (region-value (face-attribute 'region attribute nil t)))
         (and (not (eq region-value 'unspecified))
              (not (equal region-value default-value))))))
   (mapcar 'car (face-all-attributes 'default))))

> 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.

Right, after discovering the feature swap I was surprised to find no way
to enable it regardless of whether the region is highlighted.  Sure,
OT1H I thought Emacs was bugging out on me; OTOH now knowing what's
happening (and in particular, knowing that we're in sit-for so not
frozen), considering that the region is deactivated when M-w ends, I
could imagine some people finding this swap helpful and preferring to
have it on always.


Wrapping up…

(a) Would it make sense to introduce a defcustom
    (copy-region-indication-predicate?) that allows nil, t, or a
    predicate function?  The default value being:

    (and (region-active-p)
         (smart/stands-out-from-default-p))

    (Random considerations:
     * nil would be redundant with copy-region-blink-delay 0 or nil,
       not sure how much we care,
     * we could require this to always be a function instead, since
       'always is a thing)

(b) No flash of genius on how to determine whether the region face
    "stands out", yet.





  reply	other threads:[~2023-01-16 21:58 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
2023-01-16 21:58   ` Kévin Le Gouguec [this message]
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=87lem2w39q.fsf@gmail.com \
    --to=kevin.legouguec@gmail.com \
    --cc=60841@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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).