From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Newsgroups: gmane.emacs.bugs Subject: bug#60841: 30.0.50; kill-ring-save pauses despite region being highlighted Date: Mon, 23 Jan 2023 23:29:00 +0100 Message-ID: <87lelsga1f.fsf@gmail.com> References: <87h6wrs71h.fsf@gmail.com> <83zgai4peg.fsf@gnu.org> <5583fd58387746ce7ddc@heytings.org> <87cz7dbns0.fsf@gmail.com> <4c2c6cf44ad37e405b06@heytings.org> <878ri0g6ob.fsf@gmail.com> <83pmbc0yxo.fsf@gnu.org> <87y1pzo5dp.fsf@gmail.com> <834jskmhs8.fsf@gnu.org> <87fsc2qjcs.fsf@gmail.com> <833581jtff.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21958"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: gregory@heytings.org, 60841@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 23 23:30:25 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 1pK5Ka-0005Vt-Co for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 23 Jan 2023 23:30:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pK5KJ-0003Lt-EV; Mon, 23 Jan 2023 17:30:09 -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 1pK5KF-0003La-6b for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 17:30:03 -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 1pK5KE-00039U-Nm for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 17:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pK5KE-0003Q2-8d for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 17:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2023 22:30: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.167451295113051 (code B ref 60841); Mon, 23 Jan 2023 22:30:02 +0000 Original-Received: (at 60841) by debbugs.gnu.org; 23 Jan 2023 22:29:11 +0000 Original-Received: from localhost ([127.0.0.1]:55509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pK5JO-0003OQ-J1 for submit@debbugs.gnu.org; Mon, 23 Jan 2023 17:29:10 -0500 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:46738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pK5JM-0003OA-Et for 60841@debbugs.gnu.org; Mon, 23 Jan 2023 17:29:09 -0500 Original-Received: by mail-wr1-f51.google.com with SMTP id e3so12184672wru.13 for <60841@debbugs.gnu.org>; Mon, 23 Jan 2023 14:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1bCYGberoghkt3IpHR2u0FrB9pwa7XUIDCxDcBGSvEs=; b=cvecLSkfC8flwr+3bK/kKR6FYR6i5rtCmFnN1GKGSy/SgJPImvkyCKk8LG8lbqrUeI Ya38hlC/9NO/ZaXSM/TKufRb7wIJRufyVog9kbvQbMqxlyb4Lf7yXx9TPth8RXmK0MmT SajjnYgRabPg9FhH1GaCwsrO0fVfvv1wvOWaAKLd60qQRDWlDiGVx9/BbDAS0rKEVDQm k+yd+gPEP5Zc0BPSUB/7EiECq7NVsqOYGJVbG92X27ZRATg+LW7LngycnJwWGpMkmHZ3 ytgWtyoF2PfLoqYcIaxxJ+bKha3GaD/5pG/jUryXAG9VRqAC+7OftEKMIfciq//idYyZ TZ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1bCYGberoghkt3IpHR2u0FrB9pwa7XUIDCxDcBGSvEs=; b=QtJpRaIHQgJt/xMMCzidK7S+Xq60WNCyaXKyOnoTxsLeX0Fm+eMmDhrbK4YpO83FZM 3+rEuMljcMbiOGL4Y5TsidfATnejA3pbMYgT7lhByJJ9EIQUyzhGfpOot6PhdxeGI/ob Gt7awXLsRPNdqLMAGzuDSlRbIHU4cCS4WBLcbpsc5L+zIbs4G7S0biWlenXkufWTnsal NIhKftSJp7zoGq7PCAQwkF7HsddptNd9I8AA4QMjB2G5McOAcO8StprE5Lb4FZGB6k2Z dwiIy/niObgsJ9rV6Xmx8ak0jAoCXg28qc4PU/281gUy3BaPXDREGofCMnG9hV+XhtAI m/eA== X-Gm-Message-State: AFqh2krcSkQpyJNc1fD+L02CJ3MSgqQ68sPF6CstmTIVZNegshsnC/pF ds19VJM/2blxkUio4pLgRSqlVN/o4Hk= X-Google-Smtp-Source: AMrXdXt6NcjeJiXcNNl/D59yfJAG7X5XALufpU59JzQ19saE4SIbtY/Ec9T9UGrSw6yNOo5EjTnqCw== X-Received: by 2002:adf:dcd2:0:b0:2bb:ebc4:2f5c with SMTP id x18-20020adfdcd2000000b002bbebc42f5cmr32034081wrm.43.1674512942143; Mon, 23 Jan 2023 14:29:02 -0800 (PST) Original-Received: from amdahl30 ([2a01:e0a:253:fe0:2ef0:5dff:fed2:7b49]) by smtp.gmail.com with ESMTPSA id v7-20020a5d6107000000b002bdc914a139sm437788wrt.108.2023.01.23.14.29.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jan 2023 14:29:01 -0800 (PST) In-Reply-To: <833581jtff.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 23 Jan 2023 15:01:56 +0200") 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:254031 Archived-At: Eli Zaretskii writes: >> * 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. (Thanks for spelling this out. Do we have any documentation that calls out the precautions one must take when writing Elisp that will be preloaded, or any tooling that can detect whether some of those precautions were forgotten? FWIW I saw no compiler warnings nor runtime errors with that patch) > And, btw, I cannot say I understand why using seq-difference here is > justified. Why not just call delq twice and be done? That would work, of course; will go with that for the next revision. (No justification beyond lack of practice at reading or writing "preloaded Elisp", so my brain takes a couple more cycles to translate (delq 'a (delq 'b x)) into "x \ {a,b}") >> >> (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. >>=20 >> (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. (Did I mention I'm grateful for the time you and Gregory did afford for this obscure issue, considering how busy this rc phase is?) > 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. ACK, will look into this. >> +(defun region-highlighted-p () >> + "Say whether the region is visibly highlighted. > > Please drop the "Say" part, it's not our style. ACK. I see a few matches for "Return whether=E2=80=A6" in-tree; would=E2= =80=A6 Return whether the region stands out visually. =E2=80=A6 be OK, or should I just go for=E2=80=A6 Return non-nil if the region stands out visually. ? (Asking because I have a (tiny, subduable) preference for the former; predicate docstrings that call out nil/t/non-nil force me to pause and figure out whether I need to negate the rest of the sentence, whereas "whether" generally precedes a description of the "true" case. "(elisp) Documentation Tips" recommends "Return t if", but merely as a way to "avoid starting the sentence with =E2=80=9Ct=E2=80=9D", not because = we have a preference for literally starting with "Return t if") > 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? Agreed. stands-out works for me (other candidates that come to mind: noticeable, conspicuous).