From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#64301: 30.0.50; ERC 5.6: Make speaker labels easier to work with Date: Thu, 13 Jul 2023 19:20:08 -0700 Message-ID: <87zg3zqlnr.fsf__11442.5332447112$1689301302$gmane$org@neverwas.me> References: <87bkh21gfa.fsf@neverwas.me> <87sf9y32q9.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29264"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org To: 64301-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 04:21:34 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 1qK8R3-0007LT-M0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 04:21:33 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qK8Qe-00053R-Eq; Thu, 13 Jul 2023 22:21:08 -0400 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 1qK8QY-00052m-Qd for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 22:21:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qK8QY-000635-I9 for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 22:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qK8QX-00010B-Vc for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 22:21:01 -0400 Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 02:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 64301 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Mail-Followup-To: 64301@debbugs.gnu.org, jp@neverwas.me, jp@neverwas.me Original-Received: via spool by 64301-done@debbugs.gnu.org id=D64301.16893012293787 (code D ref 64301); Fri, 14 Jul 2023 02:21:01 +0000 Original-Received: (at 64301-done) by debbugs.gnu.org; 14 Jul 2023 02:20:29 +0000 Original-Received: from localhost ([127.0.0.1]:41104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK8Py-0000yw-5r for submit@debbugs.gnu.org; Thu, 13 Jul 2023 22:20:29 -0400 Original-Received: from mail-108-mta90.mxroute.com ([136.175.108.90]:40485) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK8Pq-0000yg-CF for 64301-done@debbugs.gnu.org; Thu, 13 Jul 2023 22:20:24 -0400 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta90.mxroute.com (ZoneMTA) with ESMTPSA id 1895232dd030004cef.001 for <64301-done@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 14 Jul 2023 02:20:12 +0000 X-Zone-Loop: 45b20eb0f10adff5cd2ec7ebafe3173779ba7e2b0a38 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+CM9wrRzJKZUYzUQu2a0mQNb9lnLAj0ptxc1mVjEQHo=; b=Nd57EozeKucFPexOkNpuz1Xzw/ +XxWjSgrqn1XcwQnV8cOHt3Zif04lMlcGZAxzzhqzQhfpAy8vRWCm+FoQBoRjYvF1WTfQgjQLoj32 rjmT/geG5FWVk5xh8qOiteXHH5eLrXzGqpEhfjHt3h7s/R41NJ3ppfLUCcbdZTVIh+sSMmiYLDWSg nDUw2Ucf+eTXTy3sdVXHiEmbRJJukgUlkFZ/fiw4SpaFmQlmWXLsb8XFXTAM7jFY9PNJfmU8l5b+S 2Et9iLjNMKYONs0fvKPsP2GZD/MKkmIJZGAqI+j+JFNPp3S+sFWo9OYVDli/oJDFijEW3ncFF6EZe R0nCWqHw==; In-Reply-To: <87sf9y32q9.fsf@neverwas.me> (J. P.'s message of "Sat, 08 Jul 2023 07:19:26 -0700") X-Authenticated-Id: masked@neverwas.me 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:265061 Archived-At: "J.P." writes: > v2. [...] Combine faces in `erc-display-message' when called with a > list `type' arg. > [...] > > This iteration includes a number of changes, the most important being > one that looks severe but is largely mechanical. It concerns a bug > that's been around forever and, as such, is now part of the foundation. > Basically, the `type' parameter of the function `erc-display-message' > determines a special handler that applies styling to a message. When the > parameter is a list, the function calls each handler in turn, left to > right, which clobbers existing faces instead of combines them. The net > effect (in most cases) is identical to calling the function with the > last member alone. Despite this, it would seem ending up with multiple, > "layered" faces was the authors' original intent based on the ubiquity > of call sites featuring the list variant. > > Authoritative intent aside, in the intervening decades, other code was > written that expects the current clobbering behavior. An example of this > exists in the default value of `erc-track-faces-priority-list', which > contains `erc-error-face' alone rather than paired with > `erc-notice-face'. There may indeed be others that will go undetected > should we make this "fix," which I'm still in favor of despite the > attendant risk. Actually, I decided against doing this after all [1]. There was simply no telling what kind of damage might result from these changes rippling through two decades of third-party code. > Though improved call-site readability is one upside, I'm more > interested in the UX possibilities such layering opens up. Subtle > benefits can already be seen after applying these changes, for > example, in text inserted for outgoing /me commands, which now sport a > combination of `erc-input-face' and `erc-action-face'. > > In a bid to mitigate potential breakage, at least internally, I've gone > ahead and mass-replaced all instances of > (erc-display-message parsed '(notice error) ...) > with > (erc-display-message parsed 'error ...) > which amounts to 38 incisions in total. Once again, if we leave things > as is, users who've customized `erc-track-faces-priority-list' won't > ever see error-colored text in their mode line, which is a deal breaker. Instead of all that, I've implemented an uglier and less transparent (but also non-disruptive) way for `erc-display-message' to perform such layering. Basically, callers can request the effect by specifying a slight variant of its list `type' parameter, namely, one headed by the symbol t, e.g, (erc-display-message parsed '(t notice error) ...) Without the t, this function acts as it always has. With it, the function composes faces atop one another, left to right. Existing call sites obviously won't benefit, but at least they'll be shielded from harm. Hope that's an agreeable compromise. Thanks and closing. [1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d45770e8