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: gregory@heytings.org, 60841@debbugs.gnu.org
Subject: bug#60841: 30.0.50; kill-ring-save pauses despite region being highlighted
Date: Mon, 23 Jan 2023 15:01:56 +0200	[thread overview]
Message-ID: <833581jtff.fsf@gnu.org> (raw)
In-Reply-To: <87fsc2qjcs.fsf@gmail.com> (message from Kévin Le Gouguec on Sun, 22 Jan 2023 23:45:23 +0100)

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: gregory@heytings.org,  60841@debbugs.gnu.org
> Date: Sun, 22 Jan 2023 23:45:23 +0100
> 
> > The default face is always extended, so it should be treated as
> > implicitly having the :extend attribute set.
> >
> > I think face-differs-from-default-p should be fixed to either ignore
> > the :extend attribute like it ignores :inherit (since it could be
> > argued that :extend doesn't really control how the face affects
> > characters on display), or it should treat the default face as having
> > the :extend attribute with the value t.
> 
> I have been slowly converging toward "ignore :extend" being TRT.

Fine by me.

> * that seq-difference call makes me inexplicably nervous; I thought I
>   vaguely remembered debates on whether preloaded libraries {c,sh}ould
>   use seq.el functions, but then I see that "emacs-lisp/seq" is already
>   in preloaded-file-list, and e.g. rmc.el calls some of its functions.
>   Am I misremembering?

seq.el is indeed preloaded, so that ship has sailed.  But you still
need to make sure seq is loaded _before_ any preloaded file which uses
it, and in this case faces is loaded before seq, so you cannot use
seq-difference.

And, btw, I cannot say I understand why using seq-difference here is
justified.  Why not just call delq twice and be done?

> >> (Hm, and against my better judgement I went ahead and compared
> >> gui_supports_face_attributes_p vs tty_supports_face_attributes_p, and I
> >> see that they handle :extend differently and *mashes C-c C-c with
> >> forehead before fingers can type another wall of text*)
> >
> > TTY frames always extend the color, that's the reason for the
> > difference.
> 
> (Not sure I get your meaning here; on the Linux TTY I have on hand,
> (set-face-extend 'region nil) does disable color extension)

I'm sorry, you will have to look up the discussion that led to the
development of the :extend attribute; I cannot afford searching for
it.  The differences between TTY and GUI frames were one of the main
reasons why we introduced this attribute.  Maybe what I remember
happens only on some terminals.  Or maybe I'm misremembering and it
was because of underline and not the color.  But there is definitely a
difference.

> +(defun region-highlighted-p ()
> +  "Say whether the region is visibly highlighted.

Please drop the "Say" part, it's not our style.

And I'd use some other word instead of "highlighted", because that
could be misinterpreted (the region is supposed to be highlighted).
Something like "stands-out" perhaps?





  reply	other threads:[~2023-01-23 13:01 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
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 [this message]
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=833581jtff.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=60841@debbugs.gnu.org \
    --cc=gregory@heytings.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).