GNU bug report logs - #73580
29.4; ERC 5.6.1-git: erc-nicks does not respect pal and fool faces

Previous Next

Full log

Message #14 received at 73580 <at> debbugs.gnu.org (full text, mbox):

From: Trevor Arjeski <tmarjeski <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: 73580 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#73580: 29.4; ERC 5.6.1-git: erc-nicks does not respect pal
 and fool faces
Date: Wed, 02 Oct 2024 10:40:25 +0300

"J.P." <jp <at> neverwas.me> writes:

Agreed that it's not good to couple nicks and match.

> Thanks for the bug report. The good news is I can definitely reproduce
> this. :)
>
> But whether it's a bug and how to go about addressing it is a bit more
> involved, I'm afraid. As luck would have it, this issue or something
> similar actually comes up every now and again but not so much in the
> context of `nicks' (or `erc-highlight-nicks' before it).
>
> Anyway, as you may have noticed, the `nicks' module formally depends on
> the `button' module and a new (5.6+) `button'-provided interface:
> `erc-button--modify-nick-function'. IMO, this coupling is an acceptable
> trade-off because `nicks' can piggyback on the token scanning that
> `button' provides. The `button' module itself runs its code at depth 30
> on `erc-insert-modify-hook', which is earlier than the `match' module's
> 50. This means it applies its faces _before_ `match' ever touches
> them.

I see now. I did notice the depths being different but couldn't really
grok what was going on at the moment and went for more of a "hack it
till it works" approach.

> What probably threw you off in perhaps thinking `match' had a say before
> `nicks' was the presence of useless faces from `match' in the default
> value of the option `erc-nicks-skip-faces'. That's indeed my bad: they
> shouldn't be there at all (and a patch to fix this would be most
> welcome). To that end, I'd much prefer we kept `nicks' and `match' as
> loosely coupled as possible for the sake of long-term maintainability,
> although I'm sure your current proposal is quite effective from a purely
> pragmatic POV.

I did notice this and tinkered with it, but didn't really find anything
significant when removing the pal and fool faces from it.

Thanks for the detailed explanation. I did go through with the
"traditional" approach of adding 'nick-or-keyword, but sadly gave up.

Honestly, the more I looked at ERC, the more I realized that I don't
want pals to be highlighted at all. This makes my first patch irrelevant
since the whole idea is to use one single face color every time a nick
appears (similar to weechat's nick highlighting). The same goes for a
fool, who may appear dimmed, but when someone else mentions the fool you
will see their nick as the color that erc-nicks assigns.

> If you're saying `nicks' _should_ highlight your own
> speaker tags (or should optionally do so), please explain.

This is again about consistency with seeing your own nick within
brackets (<your_nick>) and in messages that other people send (when
erc-current-nick-highlight-type is 'nick-or-keyword).

Not sure what to do! I think we can just close this bug for now.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.