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#59805: 28.2; erc-track: handle faces modified with erc-button-add-face Date: Wed, 07 Dec 2022 06:28:43 -0800 Message-ID: <87pmcv47ac.fsf__48625.5755111173$1670423360$gmane$org@neverwas.me> References: <87h6ycprpt.fsf@cern.ch> <87bkoglilv.fsf@neverwas.me> <87359sh53z.fsf@cern.ch> <87tu28fjdz.fsf@cern.ch> 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="6589"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 59805@debbugs.gnu.org, emacs-erc@gnu.org, git@david.leatherman.fm To: Nacho Barrientos Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 07 15:29:11 2022 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 1p2vQ7-0001Up-MI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Dec 2022 15:29:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2vQ0-0004Hn-T0; Wed, 07 Dec 2022 09:29:04 -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 1p2vPz-0004Gp-A6 for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 09:29: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 1p2vPy-0005o9-OW for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 09:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p2vPy-0001RE-K5 for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 09:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Dec 2022 14:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59805 X-GNU-PR-Package: emacs Original-Received: via spool by 59805-submit@debbugs.gnu.org id=B59805.16704233385521 (code B ref 59805); Wed, 07 Dec 2022 14:29:02 +0000 Original-Received: (at 59805) by debbugs.gnu.org; 7 Dec 2022 14:28:58 +0000 Original-Received: from localhost ([127.0.0.1]:50505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2vPt-0001Qz-PW for submit@debbugs.gnu.org; Wed, 07 Dec 2022 09:28:58 -0500 Original-Received: from mail-108-mta246.mxroute.com ([136.175.108.246]:43229) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2vPq-0001Qt-Mi for 59805@debbugs.gnu.org; Wed, 07 Dec 2022 09:28:55 -0500 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta246.mxroute.com (ZoneMTA) with ESMTPSA id 184ecfd31140001d7e.003 for <59805@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 07 Dec 2022 14:28:46 +0000 X-Zone-Loop: bba7a6f739371e7203af82f6498a77d0201ca81a8f5a 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-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: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=R98fC8CXi3sTFE5StDnpzDLFg58eLMN9Wls+5mavfXc=; b=C/8127s9+x9FksPQPynvMJBpAm zzuc3pBvluU9rFWc7Ddya0q27IEX3JMWf+dIPqTsyE+YdfNY9IctCwOppExFJilBeGaGiZAuGkCUx BxRgK2JSVQmDGBQzI2cXP6pxDLjADtz6UxU8Cf2LmZ6uXF98dWz6heIAhTUGS9HaE8lxfwv14Ep3N Fjp3ipm8pX19FNzirsFO2QTPQlVBjTksFgqTiwtn9NiipVUTtGelSQJmUe7aH9jrJo8LrMHl1kq/n axgnF0uY8mG7h8e10LSKQ51nTpWhI7bb5hXM2iTCGcD9MmxeE8Nfewz3kcbLqoc3N0r6mPuCYBLVC pEt4Idlw==; In-Reply-To: <87tu28fjdz.fsf@cern.ch> (Nacho Barrientos's message of "Tue, 06 Dec 2022 19:56:06 +0100") 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:250193 Archived-At: Nacho Barrientos writes: > Hi J.P., Hi Nacho, >> Looks like the default value of `erc-track-faces-priority-list' contains >> some composite faces, such as >> >> (erc-nick-default-face erc-current-nick-face) >> >> So whatever happens, I think we'll have to preserve compatibility for >> people already used to searching for such composites. > > I was totally unaware that "face composites" were a thing, so > perhaps my proposal to flatten the return value of `erc-faces-in' does > not make sense anymore. FWIW, "composite" was just some term I conjured up to refer to what's described in the third `face' bullet point of "(elisp) Special Properties": A list of faces. Each list element should be either a face name or an anonymous face. This specifies a face which is an aggregate of the attributes of each of the listed faces. Faces occurring earlier in the list have higher priority. While perhaps less common than lone face names, such values do appear in the wild, for example, when `whitespace-mode' is active. > For 2) I don't have an elegant/generic solution to propose, but adding > > (erc-hl-nicks-nick-nacho-face erc-current-nick-face) > > to `erc-track-faces-priority-list' can definitely work for me. My > nickname is stable across networks, however I think that the rather > valid use case of being notified no matter what your nick name is cannot > be honoured elegantly when using erc-hl-nicks. >From what I can gather, you still believe this despite the more recent findings in your followup just below. > Hi again, > > [...] > > Actually there's something else that can be done from the erc-hl-nicks > side, which is: > > (setq erc-hl-nicks-skip-nicks '("nacho")) Good find! > Which comes again with the problematic of having to hardcode known nicks > but it does the job. If that variable is set as indicated above, > erc-hl-nicks will never create the composite face on the mention and > hence: > > =CE=BB> (erc-faces-in (buffer-substring (point) (+ 1 (point)))) > (erc-current-nick-face) > > (in the example above, `point' is on a mention to the current nick) > > Making erc-track's matching work. The current nickname is coloured > anyway by ERC so if erc-hl-nicks does not act on it should be okay. Re the "hardcode problem": I'm not sure it's incumbent upon ERC to offer a solution uniquely tailored to updating `erc-hl-nicks-skip-nicks' specifically (not that you were suggesting such a thing). However, I do think the current offering of `erc-nick-changed-functions' has proven insufficient for servicing a variety of legitimate needs. It only runs under really specific circumstances, such as when a server-mandated nick change occurs or a confirmation arrives following a NickServ IDENTIFY (or similar action). However, it does *not* run on confirmation of a client-initiated NICK command, whether manually issued by a user or executed as library code. Unfortunately, for compatibility reasons, we can't just repurpose `erc-nick-changed-functions' willy-nilly. Thus, I think introducing a *new* abnormal hook to be run by `erc-set-current-nick' might be justified, likely defined as compatible with functions taking a new nick and giving nothing in return. Users and downstream packages could then do whatever needs doing in reaction to nick changes, for example: (add-hook 'erc-set-current-nick-functions (lambda (n) (customize-set-variable 'erc-hl-nicks-skip-nicks (cl-pushnew n erc-hl-nicks-skip-nicks :test #'equal)))) > This approach is good enough for me so feel free to close the bug if you > don't want to go down this rabbit hole further :) Regardless of this bug's original title, the mission of improving the user experience remains paramount, wherever that may lead. If you're up for it, I for one would welcome a patch adding a hook like the one described above (whenever time allows). Otherwise, we could always just kick the can down the road and rename this bug to something like "ERC needs a smarter way to run user code on nick changes" in hopes some enterprising future person will find it. Either way, I appreciate your willingness to contribute to ERC. J.P.